[Willshaper]

The problem

With two Logitech receivers of the same product id plugged in, a device shows two icons while it charges on its cable: the charging one from the cable, and a greyed "last known value, device asleep" copy from the receiver that stays for five minutes.

Seen with a G502 X PLUS and a G915, which both use a 046D:C547 receiver. Since e9369da, two receivers of the same kind make the device key carry the receiver's instance (logitech:<instance>:<unit id>). The cable has no receiver, so the same mouse on the cable keeps the plain logitech:<unit id>. Because the keys differ, the "charging wins" merge in poll() never treats them as one device.

The fix

The unit id (feature 0x0003) is the device's own serial. It is the same on any receiver and on the cable, and differs between two devices of the same model, so it is now the key on its own. Only the fallback key of a device that reports no unit id (receiver product id + slot) still gains the instance, since two receivers of the same kind have the same slot numbers.

Users with a single receiver keep the keys they have now. Users with two receivers of the same kind go back to the plain unit-id keys they had before 1.11.0, so a rename, hide, icon or alert level set since then on such a device has to be set again (noted in the CHANGELOG).

Tests

• test_two_identical_receivers_get_two_icons put the same unit id on both receivers, which no two real devices share. It now uses two different unit ids and expects both plain keys.
• New test_two_identical_receivers_without_unit_ids_get_two_icons: devices without a unit id still get distinct, instance-prefixed slot keys.
• New test_mouse_on_its_cable_keeps_one_icon: two receivers of the same kind, then the mouse moves from its receiver to the cable. Expects one icon, online and charging. It fails on main ('logitech:7&aaaa&0:C15E09CD' != 'logitech:C15E09CD').

python -m unittest discover -s tests: 603 tests, OK.

Checklist (CONTRIBUTING)

• Issue: none open for this.
• Protocol source: no new commands. Only the icon key changes. The unit id comes from the existing 0x0003 read.
• Real hardware: yes, a G502 X PLUS (receiver 046D:C547, cable 046D:C095) next to a G915 on a second C547 receiver. Before this change, the diagnostics showed the mouse as logitech:<instance>:<unit id> on the receiver and logitech:<unit id> on the cable. With it, the cable poll gives the same plain key and there is only one G502 entry.
• Other open PRs on the same files: Logitech: read HID++ 1.0 devices through the old battery registers (#159), unit tests #180 (HID++ 1.0 devices) and Add French, Chinese and Japanese localization with Windows language detection #188 (localization) also change providers/logitech.py / tests/test_logitech.py. Logitech: read HID++ 1.0 devices through the old battery registers (#159), unit tests #180's new register-battery path builds its own slot key with the instance prefix, which matches what this PR keeps for devices without a unit id.

[ahmedkhursheed23]

Thank you, @Willshaper. Reviewed: no blocking issues. A missing or all-zero unit id still falls back to the slot key with the receiver instance, so it does not merge two devices. Mutations that put the prefix back fail test_mouse_on_its_cable_keeps_one_icon and test_two_identical_receivers_get_two_icons. Tests 603/603 pass on the PR head, and 800/800 after a trial merge with main.

Notes:

• The PR conflicts with main only in CHANGELOG.md.
• The key now relies on the unit id being unique per device. The old comment said the opposite, and the PR changes test_two_identical_receivers_get_two_icons to give the second mouse a different unit id. Please add a source for this in the comment (for example, Solaar uses the HID++ 0x0003 unit id as the device serial), so a later reader does not change it back.
• Users who renamed or hid a device while two receivers were present lose that setting once. The CHANGELOG already says so.