v16.0 - sync across multiple controllers / segments losing colour

[Garold86]

What happened?

When two or more WLED instances are synced over the network and a segment uses the Solid effect, changing the primary colour on the sender does not update the color on the receiving instances. The receivers stay on their old colour. Effects, palette, speed and intensity all sync correctly — only colour fails to sync. It's most obvious with Solid because the colour is the whole output. I have more than one segment configured, and the segments other than the main segment never get the new colour.

To Reproduce Bug

1. Set up two WLED instances on the same network with Sync send/receive enabled (same sync group), "Segment options" sync left OFF (default).
2. On both, create 2+ segments and select them all, set effect to Solid.
3. On the sender, change the primary color.
4. The sender updates all segments; the receiver's non-main segments keep the old colour.

Expected Behavior

The new colour should persist across all segments, in the same way effect / intensity etc. do.

Install Method

Binary from WLED.me

What version of WLED?

WLED 16.0.0

Which microcontroller/board are you seeing the problem on?

ESP32 with ethernet

Relevant log/trace output

Anything else?

Not hardware-specific — it's in the UDP sync receive path in wled00/udp.cpp. The incoming color is only applied to the main segment, while the per-segment sync loop applies effect/palette but not color. I have a fix and will open a PR.

Code of Conduct

• I agree to follow this project's Code of Conduct

[blazoncek]

While I agree that behaviour is inconsistent (i.e. if you have more than one segment on slave/receiver devices but only one segment on master/sender) the solution proposed in #5706 is not the best place or way to do it IMO.

The problem is that UDP sync/notifications (which evolved from a non segmented version) lacks a setting like IR remotes have (irApplyToAllSelected) that would deal with situations where slaves/receivers have more segments than master.

A workaround for such scenario is to define as many segments on master/sender as there are segments on the slave/receiver that has the most and use "Sync segment options". You can use phantom outputs (or LEDs) for such purpose.

Note to maintainers: What I would do (and probably will in my fork) is to introduce receiveApplyToAllSelected global flag and use it to apply effect, color and palette to main segment only or all selected segments when receiving UDP notifications from older senders or if user chooses to apply these. The individual segment sync (receiveSegmentOptions) will overwrite any of these for segments that exist on sender and receivers.

Reasoning: Some users may have WLED devices (i.e. ESP01) as old as 0.11 keeping them in sync with newer devices. To keep behaviour predictable even across different versions this new flag will allow user to chose behaviour best suited for their use-case.

I will link commit with my approach to this issue.

[Garold86]

Thanks — that makes sense, and the backwards-compatability angle with old single-segment senders is a fair point I hadn't considered. A configurable flag is a better home for this than my unconditional change.

One thing worth noting for the default: in that same receive loop, effect/speed/intensity and palette already apply to all selected segments — color is the only property limited to the main segment. And irApplyToAllSelected already defaults to true. So for consistency, a receiveApplyToAllSelected flag defaulting to true would line color up with what effect/palette already do, with main-segment-only as the opt-in for predictable syncing with very old devices.

Happy to close my PR (#5706 ) in favour of this.

[blazoncek]

would line color up with what effect/palette already do

I would prefer the opposite. I think the current implementation for effects & palettes (even though it is mine) is incorrect.

BTW I will not provide a PR upstream but you are free to cherry pick or mangle otherwise.