Diagnostics - piggei/wled-usermod-buzzer GitHub Wiki

The usermod exposes diagnostics through WLED JSON and through its direct status endpoint.

/json/info

The WLED info response includes usermod entries for:

  • version and build;
  • disabled / GPIO not configured / synchronization unavailable / GPIO unavailable / not ready / muted by night mode / idle / playing state;
  • Night Mode interval and whether it is disabled, active, muted, or waiting for valid WLED time;
  • current sound while playing;
  • timing source;
  • last scheduler lateness;
  • maximum scheduler lateness.

On ESP32 the preferred timing source is:

esp_timer 2ms

If the engine mutex cannot be created, playback is disabled (synchronization unavailable). If the mutex is valid but the periodic timer cannot run, timing falls back to the WLED loop while retaining mutex protection.

/json/state

The buzzer state object includes:

ready
backend
muted
nightMode
nightFrom
nightTo
playing
sound
loop
repeatRemaining
note
notes
frequency
source

These fields are captured from one mutex-protected engine snapshot, avoiding mixed values from different playback instants.

/buzzer

A plain GET with no command parameters returns a compact usermod-specific status object with version/build, playback state, Night Mode configuration and current muted state.

Timing interpretation

late and max measure how late the playback engine serviced a scheduled transition. A small non-zero value is normal because servicing is periodic rather than continuous. Large or growing values can indicate scheduler load or contention worth investigating.

When the optional audio profile is compiled and selected, backend is audio. During playback, source is sample for an embedded PCM-backed sound or tone for synthesized playback. /json/info also reports the active audio profile and current source, or not ready.

For Audio (I2S), the current build also reports whether the backend is standalone or shared-I2S, the TX role (I2S1 master or I2S1 slave), stream rate/bit width, and the shared-clock tap only when it is actually active. The inherited dev-b014 runtime reports DMA 8x256, DMA coverage, write/error/short-write counters, maxWrite, maxGap, late, core0/core1 run counts, and stackMin. A maxGap above the reported DMA coverage is direct evidence that the producer was not serviced before buffered TX audio could drain.