DRGB realtime: sync.recv causes strobe, API can't persist fix, master state blocks output

[harreh3iesh]

WLED version: 0.15.4 (ESP32)
Hardware: WS2811 300-LED strip, BRG color order
Protocol: DRGB on UDP 21324

Three related bugs in the DRGB realtime path

1. sync.recv overrides realtime DRGB causing visible strobe

With sync.recv enabled (default), DRGB realtime data strobes. The strip alternates between DRGB frames and sync-received state every frame. No other WLED devices on the network — the controller appears to be receiving its own sync broadcasts or processing stale sync state.

Disabling sync.recv via /settings/sync web UI eliminates the strobe immediately.

Expected: Realtime mode (live=True) should suppress sync processing, or at minimum DRGB frames should take priority over sync-received state.

2. /json/state and /json/cfg API cannot persist sync.recv

• POST /json/state {"udpn":{"recv":false}} → returns success:true but udpn.recv unchanged on next read
• POST /json/cfg {"if":{"sync":{"recv":{"bri":false,"col":false,"fx":false}}}} → returns success:true but config unchanged
• Only the web UI at /settings/sync + reboot persists

Expected: API should persist sync.recv changes, or return an error if the endpoint doesn't support this field.

3. Master on/bri state can block realtime output

When WLED has on:false or bri:0 from a previous session, entering realtime mode via DRGB does not override the master state. live:True reports active, packets arrive (confirmed via tcpdump), but output is dark because master brightness multiplies the realtime data by zero.

Expected: Entering realtime mode should either force on:true, bri:255 or bypass the master brightness multiplier for realtime data.

Suggested patches

Bug 1 fix (sync suppression during realtime)

In wled00/udp.cpp, handleNotifications():

// Skip sync processing when in realtime mode
if (realtimeMode != REALTIME_MODE_INACTIVE) return;

Or more granularly, guard the state-application block:

if (realtimeMode == REALTIME_MODE_INACTIVE) {
  // apply received bri/col/fx from sync
}

Bug 3 fix (master state bypass for realtime)

In wled00/udp.cpp, realtimeLock() or wherever realtime mode activates:

if (!bri) bri = 255;  // ensure master brightness doesn't zero-out realtime
briT = bri;

Bug 2 fix (API persistence)

In wled00/json.cpp, deserializeState() — the udpn.recv field may not be wired to the config persistence path. The runtime state changes but serializeConfig() / flash write never fires for this field.

Steps to reproduce

1. Fresh WLED 0.15.4, default settings
2. Send DRGB UDP stream at 5+ FPS to port 21324
3. Observe strobe (Bug 1)
4. Try to disable via API (Bug 2 — fails silently)
5. Disable via web UI, reboot
6. Set master off or bri=0, then start DRGB stream
7. Strip stays dark despite live=True (Bug 3)

Workarounds (all required for reliable DRGB)

1. Disable sync.recv via web UI manually
2. POST {on:true, bri:255} before starting DRGB stream
3. Set fallback effect to solid black

Happy to submit a PR for any of these if maintainers confirm the approach.

[DedeHai]

by DRGB you mean DDP? what is the source?
number two is not a bug, sending live data to a device that is off is dropped. this is intentional.
I think you can not post to cfg as well. not sure about the post to state, according to API docs that should be possible so needs investigation.

[softhack007]

Expected: Entering realtime mode should either force on:true, bri:255 or bypass the master brightness multiplier for realtime data.

I think this is not a bug, but intended behaviour. Off means off. If you want to override brightness, there is the option "Force max brightness" in sync settings.

[softhack007]

Bug 1 fix (sync suppression during realtime)

In wled00/udp.cpp, handleNotifications():

// Skip sync processing when in realtime mode
if (realtimeMode != REALTIME_MODE_INACTIVE) return;

Not sure this is a bug - if you don't want wled sync, why enable it in the first place? The normal way would be to remove the device from the sync group, by removing the checkmark in the "receive" row.

The flickering (conflict between wled sync and realtime leds) would need deeper investigation to find the root cause.

Any way the proposed fix is incomplete. We always use the pattern if (realtimeMode && !realtimeOverride && !useMainSegmentOnly).

[softhack007]

WLED version: 0.15.4 (ESP32)

@harreh3iesh please check if the problems you describe are still present in the nightly WLED build (main branch) = version 17.0.0-dev.

[DedeHai]

about the API calls:
the API returns success if the command is parsed successfully, not if it is processed so. both your examples are not valid: one writes a read only variable, the other tries to set config parameters that can not be set that way (for whatever reason those flags can only be turned on but not off).
the API is a patchwork IMHO and in desperate need of an overhaul.