Note: If this PR goes through smoothly I'll adapt the documentation next to ensure it is also documented on https://kno.wled.ge/interfaces/udp-realtime

@Christanoid thanks for your contribution.

As a general matter (applies to all PRs), please don't force-push while you have a PR open for our repo. We regularly lose review comments and have other weird behaviour due to force-pushers. You can simply add (push) commit to your branch, they will be added to the PR and visible to us. Thanks.

Christanoid force-pushed the main branch from b722f7a to 8ee2c44  16 hours ago

I have read the rule on force pushing, sorry for going agianst it, I decided that since the PR was only a few minutes old and it was 1 AM (did not think about timezones, that one's on me), nobody will have seen it yet. Reason for the force push was a bit of local git chaos on my end forcing me to pull from the repo again before committing since my local checked out WLED folder was a bit older, so this PR's history was multiple commits, one of which was unnecessary. I therefore thought I might aswell clean the commit history. Won't do again in the future, once the PR is accepted it will likely get squashed anyways I assume.

Is any further action from me required for the request to be merged? Since it has been stale with awaiting testing for a while now.

Sorry for the delay with testing

To help with this could you just add some brief testing notes that explain setup needed, the behaviour of the bug Vs behaviour after the fix?

No Problem.
To test this you only need an ESP32 with an RGBW stripe and a client to use the UDP Stream to live stream data. Previously simply nothing would happen, since the If condition changed in the PR would just filter out the mode for DNRGBW, however now if you set the protocol byte to 5 it will correctly let you send a stream of RGBW colors.

I have been using it on my ambilight with a custom build for weeks now, seems to work fine for me. Only calculation still to be made is for the documentation, how many LED's can be controlled in one packet maximum. I calculated it in the past but have forgotten, would do so again once documentation needs changing. I do not see any possibility for a crash due to a packet being too big, since the handling of oversized packets should be identical to the one in the other udp streaming modes.

I have been running this firmware on all my devices for months now. Any update on the review? Would appreciate going back to nightly / alpha again.

Sorry for the delay