Fix operator tracks collapsing onto op-Unknown-BasicID_0 (v2.3.2)

[ampledata]

Supersedes #10, which was branched off a stale local main (missing #9) and so showed as CONFLICTING — and GitHub runs no CI at all on a conflicting PR. This is the same work rebased onto current main; during the rebase git correctly dropped my two already-upstream commits.

---

Measured on a live box (aryaos-4f11, DroneScout DS110), 30 s of CoT on the Mesh SA group, attributed by source IP:

from 192.168.0.13 (DroneScout, MAVLink serial):
  op-Unknown-BasicID_0          x62   <-- every operator on ONE track
  RID.1787F04BM24010011195.uas  x54   correct
  op-1787F04BM24010011195       x54   correct
from 192.168.0.44 (Wi-Fi RID, SAME drone):
  op-4A:BE:41:9D:E3:34          x14   correct — MAC fallback working

The aircraft UID resolved; the operator UID did not. Every operator seen by that receiver merged into one track.

Cause

The MAVLink path called rid_normalize.odid_parsed_to_rid_dict directly and attached no data metadata at all — unlike the wireless path, which builds it via bytes_to_rid_dict → uas_meta_defaults. With neither a MAC nor a sensor_id, a pack carrying only System/OperatorID and no BasicID had no transmitter identity to key on, so _rid_identity fell through every rung — including #9's new FEED- rung — to Unknown-BasicID_0.

MAVLink OpenDroneID carries a 20-byte id_or_mac naming the transmitter, which the code ignored. It's the only per-aircraft grouping key a serial feed offers — there's no radio MAC in the metadata. Measured on the DS110: populated on 58 of 58 packs, db:13:81:94:13:55 + 14 zero bytes, one distinct value for one drone.

Changes

• Attach metadata on both MAVLink paths, carrying id_or_mac as the advertiser MAC and the configured SENSOR_ID.
• Only accept a MAC-shaped id_or_mac (6 significant bytes then padding). The field may instead hold an opaque ID string, and calling that a MAC would put a wrong-looking value in the CoT UID — those feeds keep the previous behaviour until there's hardware to test against.
• _rid_identity: look for sensor_id at both levels. The MAC was already checked at both because "MQTT and serial feeds put it at the top level" — the same is true of sensor_id, so Give MAC-less feeds a distinct UID instead of a shared placeholder #9's rung silently never fired for exactly the feeds it was written for.

Second bug the missing metadata caused, also fixed: CoT was attributed to the default dronecot_<hostname> instead of the configured SENSOR_ID, so on a box with two receivers you couldn't tell which one saw a contact.

_adsb_vehicle_to_rid_dict stays a static pure function with metadata injected by the caller, so its existing unit tests keep working untouched.

Tests

13 new tests using the real captured id_or_mac, including that two transmitters don't collapse (the DS110 reports many aircraft over one port).

Verified they catch the bug — reverting the metadata attachment fails exactly the three identity tests:

AssertionError: 'Unknown-BasicID_0' == 'Unknown-BasicID_0'
FAILED PackIdentityTestCase::test_pack_without_basicid_gets_a_distinct_uid
FAILED PackIdentityTestCase::test_pack_with_basicid_prefers_the_real_serial
FAILED PackIdentityTestCase::test_two_transmitters_do_not_collapse

Full suite on the rebased tree: 85 passed, 1 skipped.

Worth saying plainly

This is the same class of bug as the aggregator work in 2.3.0 and #9. Both were verified on the UAS path and not the operator path, so it shipped half-fixed twice.

🤖 Generated with Claude Code

https://claude.ai/code/session_0197da7dhvcPoHxYKamrYqyM