Incorrect channel order for WS2814A RGBW strip.

[zowper]

What happened?

I am using a WS2814A RGBW strip. The datasheet for this strip is here: https://drive.google.com/file/d/1IRLl1YkhRFBB01Im5psSYpEsqsy-9JIV/view

I can successfully get all four channels to light up independently, but they're always in the wrong order (with the white channel at the end: xxxW instead of Wxxx).

This issue has been confirmed by Aircoookie on the Discord server:
https://discord.com/channels/473448917040758787/757254961640898622/961198105573867550

Aircoookie — 04/06/2022
"No solution exists yet, making an issue is a good idea and I will get to it soon :)"

To Reproduce Bug

When it's set to SK6812 RGBW, the Red is White, the Green is Red, the Blue is Green, and the White is Blue (WRGB).

I've tried setting the RGB to no power and the white to full power on the color selector (which lights up as blue in my case). Then I went to the options and cycled through each color order dropdown (GRB, RGB, etc.) They are all blue.

Expected Behavior

I was expecting the white channel to control the white LED, but it cannot.

Install Method

Binary from WLED.me

What version of WLED?

0.12.0

Which microcontroller/board are you seeing the problem on?

ESP32

Relevant log/trace output

No response

Anything else?

The discussion about this issue begins here:
https://discord.com/channels/473448917040758787/757254961640898622/960751408431378442

A simple fix would be to add an extra option to the dropdown to select between WRGB and RGBW. :)

Code of Conduct

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

[zowper]

I have updated from 0.12.0 to 0.13.1

I set the RGB to 0% brightness and the white channel to 100% brightness. The strip appeared as 100% blue.

I then cycled through all six options in "LED Preferences > Color Order".

They all showed 100% blue (with RGB at 0% and White at 100%).

[zowper]

I was able to get it working by editing a few lines of code in version 0.13.1. Please note that this is a hack and will make other LED strips malfunction!

In the file "bus_wrapper.h", I changed two blocks of code to the following:

Lines 420-423:
uint8_t g = c >> 16;
uint8_t b = c >> 8;
uint8_t w = c >> 0;
uint8_t r = c >> 24;

Lines 633-638:
case 0: return ((col.G << 24) | (col.R << 8) | (col.B << 16) | (col.W)); //0 = GRB, default
case 1: return ((col.R << 24) | (col.G << 8) | (col.B << 16) | (col.W)); //1 = RGB, common for WS2811
case 2: return ((col.B << 24) | (col.R << 8) | (col.G << 16) | (col.W)); //2 = BRG
case 3: return ((col.R << 24) | (col.B << 8) | (col.G << 16) | (col.W)); //3 = RBG
case 4: return ((col.B << 24) | (col.G << 8) | (col.R << 16) | (col.W)); //4 = BGR
case 5: return ((col.G << 24) | (col.B << 8) | (col.R << 16) | (col.W)); //5 = GBR

Then in "LED Preferences" I set the strip type to "SK6812 RGBW" and the color order to "RGB".

Now, in the app when I adjust the white channel I get white. When I set the strip to Red, Green, or Blue, I get the correct color. :)

[blazoncek]

Will be available shortly...

[Changchung]

Will be available shortly...

This is nice... I need it so bad... Thanks

[blazoncek]

Fixed in #2737

[Oldnumber9]

Hello, looking for a little help here.

I do not see the "Swap" option in my WLED interface.

I've udpated to 0.13.3 and am using a QuinLED digi quad with WS2814.

My hardware setup is shown in the screenshot below using SK6812 RGBW.

I have the same wled interface with no "swap" option in both Android and iOS.

I need to swap the white and green channels.

Any help appreciated.

[blazoncek]

Wait for 0.14.

[Oldnumber9]

Thank you blazoncek, I will wait for 0.14

[Losses]

@Oldnumber9
Install firmware from here:
https://github.com/srg74/WLED-wemos-shield/tree/master/resources/experimental/Firmware

and config your stipe like this:

I've successfully made one, hope this would help you!

[Oldnumber9]

@Oldnumber9 Install firmware from here: https://github.com/srg74/WLED-wemos-shield/tree/master/resources/experimental/Firmware

and config your stipe like this:

I've successfully made one, hope this would help you!

Thank you Losses, very much appreciated!

I returned the offending WS2814 strip and replaced it with an SK8612, and am now running happily in production.

I appreciate the pointer, and will try your build next time I am flashing.

Thanks again.

[hyd808]

@Losses
I am having issues saving the swap value. After changing and clicking save, it does not save. It is the only LED setting that will not save.
Any ideas?

Hardware: QuinLED ESP32 board. (ESP32-WROOM-32E)
Firmware: https://github.com/srg74/WLED-wemos-shield/blob/master/resources/experimental/Firmware/WLED_0.14.0-b0_ESP32.bin

[blazoncek]

@hyd808 have you updated to latest build of 0.14?

[hyd808]

I believe so:

[blazoncek]

I cannot reproduce. In all cases W swapping is saved successfully.

[speurhond]

@Losses I am having issues saving the swap value. After changing and clicking save, it does not save. It is the only LED setting that will not save. Any ideas?

Hardware: QuinLED ESP32 board. (ESP32-WROOM-32E) Firmware: https://github.com/srg74/WLED-wemos-shield/blob/master/resources/experimental/Firmware/WLED_0.14.0-b0_ESP32.bin

I have the same problem

[blazoncek]

I have the same problem

Erase flash and flash again using one of the supported methods.

[Losses]

@blazoncek Confirmed that the latest build has this issue

[Robertfj]

@Losses Is it possible for you to build one for ESP02 aswell?

[blazoncek]

One thing of note: If saving LED config is unsuccessful it (usually) means that LED initialisation using new settings failed.
In such case it would be necessary to use debug build and monitor serial output.

[Robertfj]

It saved successfully for me when using "WLED_0.14.0-b0_ESP8266.bin" on "NodeMCU V3 Lua CH340G ESP8266"

[jianming0]

@Losses I am having issues saving the swap value. After changing and clicking save, it does not save. It is the only LED setting that will not save. Any ideas?

Hardware: QuinLED ESP32 board. (ESP32-WROOM-32E) Firmware: https://github.com/srg74/WLED-wemos-shield/blob/master/resources/experimental/Firmware/WLED_0.14.0-b0_ESP32.bin

I too am getting the same issue where the swap values are not saving. Am using an ESP32 on this hardware controller: https://www.athom.tech/blank-1/wled-esp32-music-addressable-led-strip-controller

on the latest firmware: WLED beta release 0.14.0-b1

[blazoncek]

Read my post above.
If LED config is not saving, something bad happened during re-initialisation of LED buses. To diagnose that you need debug build and monitor serial output.

[Losses]

@blazoncek I noticed that the build on Oct 22 works, but users reported the config won't save after Oct 30, maybe some changes break this feature during these days, hope this could provide some cue about the bug.

[Losses]

Read my post above. If LED config is not saving, something bad happened during re-initialisation of LED buses. To diagnose that you need debug build and monitor serial output.

Is there a debug build for users to provide debug information?

[blazoncek]

Channel swapping was introduced in 0.14 on August 18th (on April 30th in my fork) and there were no changes to that code since.

[Losses]

Channel swapping was introduced in 0.14 on August 18th (on April 30th in my fork) and there were no changes to that code since.

That's weird, I'll try to use a debug build and see what will happen.

[jianming0]

I managed to get the channel swap working by a weird workaround, it takes a few tries for it to work but here it is:

I deleted the LED outputs in the LED preferences and setup the LED strips again this time with a different GPIO number, then changing back to the correct GPIO number.

I have 2 sets of output from my hardware (GPIO 17 for 200 to 300 and GPIO 18 for 0 to 200), so I'd sometimes key in for GPIO 17 first then re-edit them to put GPIO 18 first then GPIO17.

Sometimes it takes a few tries of deleting and changing the order of what is being added first or just adding one by one, for it to work correctly.

[blazoncek]

That would suggest where to look for problems: GPIO not being released and re-allocated properly. That would also explain why LEDs still work after a failed save.