-
-
Notifications
You must be signed in to change notification settings - Fork 40
Add support for the AudioReactive usermod (state + control) #2084
Description
Proposal
I'd like to add support for reading and controlling the AudioReactive usermod, so that the Home Assistant WLED integration can expose a switch for it. This was requested in home-assistant/discussions#1150: users want to enable sound reactive effects from automations, and to be able to see and disable the microphone for privacy when it isn't needed.
WLED JSON API behavior
The AudioReactive usermod has been part of WLED core since 0.14, and uses the standard usermod state hooks (audio_reactive.cpp):
-
Reading: when the usermod is compiled in, the state object contains its current state:
{ "AudioReactive": { "on": true } }When the usermod is not present, the key is absent ΓÇö which doubles as the availability check.
-
Writing: the usermod reads a different key than it reports (
readFromJsonStatelooks atenabled, noton):{ "AudioReactive": { "enabled": true } }posted to
/json/state(HTTP or WebSocket).
Proposed library changes
Following the existing Nightlight/UDPSync patterns:
- A new
AudioReactivemodel with anon: boolfield, and a newState.audio_reactive: AudioReactive | Nonefield (aliasAudioReactive), defaulting toNoneso consumers can detect whether the usermod is available. - A new
WLED.audio_reactive(*, on: bool)method that posts{"AudioReactive": {"enabled": on}}to/json/state, mirroringWLED.nightlight()/WLED.sync(). - Tests for model deserialization (usermod absent/present) and the request payload, plus updated device snapshots.
I have a working implementation (library change plus the Home Assistant switch entity built on top of it) and I'm happy to submit a PR if you're open to this. Opening this issue first per the contributing guidelines.