Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR primarily focuses on extending current implementation of e1.31 led device to not only support RGB data but also RGBW and hence partially covers #446 feature request for network based led device. Having RGBW implementation for e1.31 will allow in the future to extend wled led device to use not only DDP and RAW but also e1.31 and hence provide native RGBW support. During implementation I've also encountered a problem that some e1.31 (e.g. RGB WLED) doesn't use 512 DMX channels but less (510 = 170 leds*3channels) and hence current e1.31 led device implementation doesn't work correctly with WLED for >170 leds. To address this I've replaced the hardcoded value with a configurable option (see webui changes before/after).I've tested code with my WLED setup using both RGB (white_off) and RGBW (cold/neutral white).
I've started working on this with intension of vibe coding but in the end gave up and put a couple of manual commits. So some of the code has been AI generated, but was reviewed by me.
What kind of change does this PR introduce? (check at least one)
If changing the UI of web configuration, please provide the before/after screenshot:


before
after
Does this PR introduce a breaking change? (check one)
If yes, please describe the impact and migration path for existing setups:
The PR fulfills these requirements:
Fixes: #xxx[,#xxx]
, where "xxx" is the issue number)If adding a new feature, the PR's description includes:
PLEASE DON'T FORGET TO ADD YOUR CHANGES TO CHANGELOG.MD
To avoid wasting your time, it's best to open a feature request issue first and wait for approval before working on it.
Other information: