Add support for the AudioReactive usermod (state + control)

[mcaulifn]

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 (readFromJsonState looks at enabled, not on):

  { "AudioReactive": { "enabled": true } }

  posted to /json/state (HTTP or WebSocket).

Proposed library changes

Following the existing Nightlight/UDPSync patterns:

• A new AudioReactive model with an on: bool field, and a new State.audio_reactive: AudioReactive | None field (alias AudioReactive), defaulting to None so consumers can detect whether the usermod is available.
• A new WLED.audio_reactive(*, on: bool) method that posts {"AudioReactive": {"enabled": on}} to /json/state, mirroring WLED.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.

[mik-laj]

I'm happy to submit a PR if you're open to this.

We're open to external contributions. If you have a ready code, feel free to open it and I'll review it.