Repository navigation
Troubleshooting
Check:
- the usermod is enabled;
- the GPIO is configured;
-
/json/infodoes not report GPIO unavailable; - another WLED function has not claimed the same pin;
- for passive mode, an LEDC resource is available;
- the selected trigger level matches the hardware interface.
Use:
curl "http://<WLED-IP>/buzzer"and inspect ready and playing.
Quote the URL:
curl "http://<WLED-IP>/buzzer?play=alarm&repeat=3"Without quotes, Bash interprets & as a background operator and sends only the part before it.
This is expected. Active buzzers generate their own fixed pitch. They reproduce the on/off rhythm of built-in sounds only.
Use a passive buzzer when note pitch is required.
The configured PWM volume can be identical while acoustic loudness differs. Piezo elements have frequency-dependent efficiency and can become much louder close to resonance.
This does not necessarily indicate that the sound definitions use different volume levels.
Save the Usermods configuration first. Hardware changes are applied from the saved configuration; the page explicitly warns to save before testing hardware changes.
The requested pin could not be allocated through WLED PinManager. Choose a free pin and save again.
Check Buzzer timing in /json/info. The preferred source is esp_timer 2ms; the info entry also shows last and maximum scheduler lateness. If the state reports synchronization unavailable, mutex allocation failed and playback is intentionally disabled.
Check Night Mode. When the current WLED local time is inside the configured quiet interval, the service remains ready but playback requests are intentionally muted. /buzzer, /json/state, and /json/info expose this condition.
The current backend defers the first ES8311/I2S bring-up until the WLED usermod setup phase has completed, then applies the saved codec volume from the active audio task after I2S clocks are running. The PA pin and codec level are also reasserted on the first playback request. Playback should therefore work after a cold boot without moving the Volume slider.
Do not treat a test as valid unless /json/info confirms the Buzzer is actually configured as Audio (I2S) and the Buzzer state is ready/idle. An earlier dev-b010 experiment was mistakenly observed while the Buzzer was not in the Audio path.
On Waveshare, AudioReactive coexistence must use shared-I2S with the GPIO-matrix clock tap. Expected diagnostics include:
TX I2S1 slave
rate 22050 Hz
clock tap GPIO-matrix
RX I2S0 untouched
If Buzzer audio reports not ready, inspect the following error: entry. shared clock/DMA priming timeout means I2S1 did not see usable shared clocks and should be investigated before attempting playback.
The Buzzer must never reconfigure GPIO43/GPIO38 as its own slave clock pads while AudioReactive/I2S0 is driving them.
The qualified clock-routing implementation enables BCLK/LRCK input sensing without removing the I2S0 master output routes and verifies physical LRCK activity before starting I2S1 slave TX. See Shared I2S + AudioReactive.
This is intentionally a Buzzer-side change only. AudioReactive/I2S0 remains the owner of RX and of the physical MCLK/BCLK/LRCK outputs.
This symptom was resolved by the qualified 8x256 TX buffering change and the same runtime is retained in v0.2.0. Confirm /json/info still reports DMA 8x256, then inspect maxWrite, maxGap, late, err, and short. On the qualified hardware run err, short, and late remained zero and maxGap was about 13 ms against about 92.9 ms of DMA coverage. If stutter returns, treat it as a regression before changing priority or affinity.
WLED Buzzer Usermod · Documentation v0.2.0 · https://github.com/piggei/wled-usermod-buzzer