[nathandlawrence]

Rebased onto claude-refactor as asked in #45. Five commits, each with its own tests. Each one passes pytest and ruff on its own, so you can take any of them separately:

1. Fireworks ID per deviceType: 0x3A stays the default. 0x03 is used on deviceType 75, where 0x3A does nothing, also with 0xDA. See Light show (preset effect) IDs verified on hardware: Fireworks is 0x03, not 0x3A; plus status codes for reporting the active effect #46.

2. Add deviceTypes 127 and 171 (the Dynamic Effects eave lights and the Matter revision of the Full Color A19). Details in Device not working / Unknown device / Incorrect device / Have better info available / Better white temp handling #12.

3. parse_entity_state: don't raise for a device without metadata. On an HA birth, the re-announce stopped at the first unknown deviceType, so every device after it kept an unknown state. See MQTT receiver dies on HA birth re-announce when a device type has no metadata ('NoneType' object has no attribute 'capabilities') #45. As @crdson93 found below, the same guard also fixes the 0x73 mesh-info path, where an unknown type dropped the whole mesh packet and stopped status from the known devices in it.

4. Run modes: music shows, the user's custom show slots, stop_show, and the running show published as the entity's effect (read from status byte 6). The new cync_lan/effects.py holds pure functions and uses the same per-deviceType light-show IDs. set_lightshow uses it, and docs/protocol.md gets a run-mode section with confidence tags. See Light show (preset effect) IDs verified on hardware: Fireworks is 0x03, not 0x3A; plus status codes for reporting the active effect #46 and Feature: music shows (preset + custom) via run mode - same 0xE2 / 0x0E command as set_lightshow #47.

5. Test for the mesh-info path (the chain _process_73_mesh_info uses): an unknown type's status followed by a known device's status, and both must publish. It fails without commit 3 and passes with it.

Testing

• uv run pytest -q: 266 passed (198 before + 68 new). uv run ruff check src tests is clean. Both were checked at every commit.
• Type 171 also confirmed on @crdson93's two bulbs (Matter Full Color A19, RGB + tunable white).
• Hardware: every effect value was measured one command at a time on a deviceType 75 (24' Cafe Lights, fw 1.0.516). For each one, the command was sent, the status read back, and the Cync app's highlighted tile and the string itself checked. That was done through the Cync cloud relay with the same packet, and since 2026-10-25 also through a local cync-lan build (the python branch plus these changes) on that string. The 0x3A + 0xDA Fireworks packet was re-tested locally on 2026-10-26.
• Not tested: run modes on other device types (which is why music shows and custom slots are only offered to dynamic devices), the metadata guard through a real HA restart, and this exact branch on hardware.

Notes

• Updated after Light show (preset effect) IDs verified on hardware: Fireworks is 0x03, not 0x3A; plus status codes for reporting the active effect #46: commit 1 now picks the Fireworks ID by deviceType instead of replacing 0x3A. The branch was rebuilt so every commit still works on its own.
• The factory light shows keep their existing last payload byte (FACTORY_EFFECTS_BYTES[...][1]). The new effects send a random byte, like homebridge-cync-app. Any byte worked for every show tested.
• Effect names follow the existing snake_case keys, for example music_supernova and custom_music_4 (the app's 4th custom music slot, index 13).

🤖 Generated with Claude Code

[crdson93]

Hardware confirmation for deviceType 171, and one extra data point on the metadata guard.

Type 171 is the Matter revision of the Full Color A19. I have two of them. In cync_mesh.yaml they export as type: 171 (fw 1.0.222), and Matter reports the product name as "Cync Full Color A19". They are Direct Connect (Wi-Fi + BT) bulbs with Matter support, RGB plus tunable white, so color=True, tunable_white=True matches what the bulbs are. (I haven't run this branch yet. In the meantime I've hand-edited those two entries to type: 153, and on/off control works with that mapping.)

The unknown-type crash isn't limited to the HA-birth re-announce. On a build of claude-refactor (0.0.8b1.dev1, plus the stale-vote/mesh-refresh PRs I sent in #41 to #44), adding two type-171 bulbs to a 19-device mesh made every mesh-info packet fail, not just the birth path:

session.py parse_raw_data -> parse_packet
handlers.py _dispatch_device_request -> _handle_73_mesh_control -> _process_73_mesh_info
device.py handle_entity_update
mqtt_client.py parse_entity_state:
  if hasattr(node.metadata.capabilities, "motion") ...
AttributeError: 'NoneType' object has no attribute 'capabilities'

Each failing packet was dropped (dropping packet that failed to parse, logged for several different devices), so status updates from the existing devices stopped getting through, and no entities were created for the new bulbs. Changing the two entries to type: 153 and restarting cleared it immediately. So the node.metadata is not None guard in commit 3 also fixes this path, which seems worth a line in the PR description, and possibly a test that goes through _process_73_mesh_info rather than only the birth re-announce.

Happy to test this branch against my live mesh (21 devices, mix of BT-relayed and Wi-Fi bridges, both type-171 bulbs included) and report back, if that's useful. I'd run it merged with my fork's mesh-refresh commits.

[nathandlawrence]

Thanks, this is really useful, both the type 171 confirmation from your own bulbs and the mesh-info trace.

I've added a test for that path: a status for a type the table doesn't know goes through CyncDevice.handle_entity_update -> parse_entity_state (the same chain as _process_73_mesh_info), followed by a status for a known device, and both have to publish. It fails without the guard in commit 3 and passes with it. That's the new 5th commit. I've also added a line to the PR description that the guard fixes the mesh-info path, not only the HA-birth re-announce.

And yes, please test it on your mesh, merged with your mesh-refresh commits. 21 devices with a mix of BT-relayed and Wi-Fi bridges is a much wider check than my setup. I'd especially like to hear whether the type-171 bulbs come up as lights with color and white once you switch them back from 153.