wilbowes/EchoMuse

I'd like to add support for the Echo Show 8 (1st gen) running LineageOS as a second device alongside the Echo Dot 2nd Gen, and wanted to share the intended shape early to get your feedback before writing much code. Approach. The controller is model-agnostic (capability-negotiated), so this is almost entirely a second set of device bindings. The plan is to reuse the whole board-agnostic core (wake word, beamformer, AEC, networking, server) and write fresh hardware bindings for the Show behind a new crown build tag, mirroring the existing server tag — one binary per board, no runtime hardware detection. Key decisions so far: One binary per board, selected by build tag (not runtime detection). The Show owns the audio hardware exclusively for now, exactly like the Dot; sharing with other Android apps via the Android audio stack is deferred. A decorative model label ("Echo Show 8") in the handshake — display only, nothing branches on it; behaviour stays capability-driven. No LED ring o

What happened A provisioned device stopped reconnecting to WiFi after a reboot and would not recover without manual intervention. The other two devices in the fleet were unaffected. The device was scanning correctly and seeing the AP's BSSID in results, but never attempting association. Root cause (confirmed via logcat) WifiStateMachine showed numNoInternetAccessReports: 103 for the configured network against only 19 successful associations: D/WifiStateMachine: numAssociation 19 D/WifiStateMachine: numNoInternetAccessReports 103 Android 5.1's WifiAutoJoinController uses this counter to block auto-join on networks it considers unreliable. On a local-only network (no WAN, only a LAN controller), Android's captive portal detection marks every successful connection as "no internet access," incrementing this counter on every boot until auto-join is permanently suppressed. The device was scanning and the AP was visible, but WifiStateMachine never issued an association attempt. wpa_cli list_

There is no brightness setting today. The only LED config keys are ledScene, ledListenColor and ledThinkColor — checked, not assumed. So this is new work rather than plumbing something existing through to HA. That matters for ordering: brightness has to exist as a controllable value before anything — Home Assistant, an automation, or the ambient light sensor (#295) — can drive it. The user-facing problem A twelve-LED ring at full output is a lamp. In a dark bedroom at 3am it is the brightest thing in the room, and the only way to stop it today is to pick a scene that happens to be dimmer. Scope ledBrightness as a device config key, in the ring section, scoped per device like the rest of that section. Someone will want the bedroom dim and the kitchen bright, and the fleet/device split already handles that. Applied at render, not per scene. It scales whatever the priority system is currently drawing, so it works for the listening ring, the volume arc, the mute indicator and the pl

The dashboard is verified by someone opening it and clicking around. That catches a lot, and it has already missed things that a machine would not have. Three increments, each useful on its own. Deliberately not a "UAT project" — the full click-every-control suite comes last, if the cheap ones earn their keep. The enabling change already landed PR #287 added a CI job that boots the controller in the built image and waits for Controller ready. Everything below hangs off that: a browser test needs a running controller, and now CI has one. A fake device is a script rather than hardware — the WebSocket protocol is ours. 1. Console-error check (cheapest, do first) Boot the controller, drive a headless browser through every tab, fail on any browser console error. Would have caught `${color}88` immediately. That worked while every colour was a literal, and the moment call sites became var(--lcd-green) it produced var(--lcd-green)88 — invalid CSS that drops the whole declaration. The LCD

handle_control is 704 lines — the largest function in the project, and the one PR #280 re-indented wholesale to wrap in a try/except. That guard was the right fix for the symptom (one bad message took down the device's voice satellite, BLE proxy and data plane together). It does not address why an 834-line re-indent was needed to add it: eleven message types share one function and one scope. What to do Extract a handler per message type, leave a dispatch table. Roughly: CONTROL_HANDLERS = { "button": handle_button_event, "ambient_light": handle_ambient_light, "mute_state": handle_mute_state, "volume_state": handle_volume_state, "stats": handle_stats, "wifi_result": handle_wifi_result, "playback_stats": handle_playback_stats, ... } Two things this buys beyond readability: Each handler becomes testable on its own. The suite cannot import em_controller, so today none of these are covered by anything. A handler taking (device, m