Bridge ↔ firmware state divergence after bridge restart #21

(observed 2026-04-29; refreshed 2026-06-03 for post-#36 architecture)

The perception store is in-memory, so restarting the service that holds it while the device is in any non-idle state (sleep, talk, story_time, security, dance) drops the last-known state and the store re-initialises with default idle.

The firmware doesn't proactively re-emit state_changed on reconnect because nothing has changed on its side — so the dashboard, perception consumers, and any state-gated logic disagree with reality until the next firmware-side transition.

Concrete repro (original, ZeroClaw-era)

2026-04-29 21:41: firmware in sleep (state arc blue), bridge restarted to deploy dotty-stackchan ae54e93, post-restart /ui/state returned idle while LED still blue.

Worse, firmware's privacy gate was still pinning cam+mic off — user-visible symptom is "Dotty is broken", identical to the earlier privacy-sleep-stuck issue.

⚠️ Architecture update (post-#36 cutover, 2026-05-19)

This issue predates the ZeroClaw cutover. The bug survived the cutover, but the moving parts moved:

• The in-memory store moved. It was bridge.py's module-level _perception_* globals; it now lives in dotty-behaviour/perception/state.py (PerceptionState.state — a per-device dict; current_state defaults to "idle", see state.py:217).
• The trigger changed. It's no longer systemctl restart zeroclaw-bridge (retired). The equivalent loss now happens on dotty-behaviour container restart, and equally on xiaozhi-server restart / network drop / firmware reboot (all already flagged below).
• The pipe already exists. Firmware's Phase-4 StateManager emits state_changed; the xiaozhi relay forwards it (custom-providers/xiaozhi-patches/textMessageHandlerRegistry.py:109); dotty-behaviour mutates current_state from it (state.py:185-188). So a firmware-side re-emit flows through the existing path with zero new server-side plumbing.

Two viable fix paths

• (a) Server-side reconcile. On dotty-behaviour startup, query firmware for current state and seed the perception store. The original MCP self.get_device_status hook lived on the retired ZeroClaw path, so (a) would need re-designing against the current stack (e.g. an admin pull through xiaozhi active_connections). Confined to dotty-stackchan.
• (b) Firmware-side re-emit on (re)connect (recommended). On audio-channel open, re-fire state_changed with current state so every stateful consumer that lost track gets a fresh edge. More robust — also covers xiaozhi-server restart / network drop / firmware reboot. ~10 LOC firmware.

Recommend (b): single source of truth is the firmware, the cost is trivial, and post-#36 it needs no server-side changes — StateManager::emitStateChanged() and the relay→dotty-behaviour path already exist.

Migrated from local tasks.md on 2026-05-16.