Server migration complete, Welcome to version 2.1.1



Welcome, Guest.
Please login or register.
Forgot your password?

+-Site Stats

Total Members: 16460
Latest: tripleblack
New This Month: 10
New This Week: 1
New Today: 0
Total Posts: 132598
Total Topics: 16443
Most Online Today: 221
Most Online Ever: 7634
(January 21, 2020, 02:14:03 AM)
Users Online
Members: 1
Guests: 177
Total: 178

Plugin/Filter for Govee RGB + W lights

Started by EricD, July 21, 2023, 04:09:26 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.


I'm playing around with a set of which match up as far as wiring goes to what is described in

So it is a WS2811 controller but arranged with two chips per bulb with the first chip connected to a GBR LED and the second connected a soft-white LED. This works out to 6 bytes per bulb with:
Byte 1: Green (00-FF)
Byte 2: Blue   (00-FF)
Byte 3: Red    (00-FF)
Bytes 4-6: White (000000-FFFFFF)

For the White LED it appears to use the entire available 24bit range for dimming where 000001 is the lowest brightness and FFFFFF is highest.

Are there any potential nice ways to model a string like this in Falcon Player? Perhaps a "Three to Six" output processor :D

*edit: fixing byte counts, was a long day at work


First so as to not confuse others, I think your math is off. 3 bytes per ws2811 is 6 bytes total.

Model them in xLights and then upload to FPP and you would get the basics. The white will likely be a problem. I don't think there is 24 bit dimmer available.

However, I doubt that the whole range is used for dimming. That would result in 16,000,000 levels of dimming and a standard ws2811 chip just couldn't do that. It is possible that they are adding the 3 outputs together to drive the white leds which would be similar to using the entire range but would be very different from driving 16,000,000 levels of dimming. Basically, you would be driving 3 channels with 256 levels of dimming.

In the reddit, someone remarked that the white is not dimmable and I didn't see anyone dispute that although it makes sense that the white would be dimmable since it appears to be driven by a ws2811.


Man I really messed up my byte counts, you're right it is 3 bytes per ws2811 so 6 bytes per bulb for these lights.

I think they do have the white LED wired into all 3 outputs, it will turn on when any of the 3 bytes are set but it isn't quite uniform. 050000 is brighter than 000005, FFFFFF is very slightly brighter than FFFF00. I'll have to see if I can find a serial debugger to see what the Govee controller sends when dimming the white LEDs.

I'm able to test the lights by setting them up as a RGB string on FPP and then using a Custom Chase Pattern in the testing UI. I've verified the color ordering and ability to dim RGB and White using the byte layout from my original post.

I took some time to read through the ThreeToFourOutputProcessor and I'll try copying it to make a ThreeToSix version and see if that will do what I want. I was poking around in xLights and I don't see a way to tell it that White is 24 bits or even to just skip 2 bytes after a RGBW 4-byte pixel.


I was able to model these in xLights using Substrings:


When implementing an OutputProcessor, is the channelData passed into ProcessData in the order specified on the string config or is it always in RGB/RGBW order?


Quote from: EricD on July 26, 2023, 02:39:47 PMWhen implementing an OutputProcessor, is the channelData passed into ProcessData in the order specified on the string config or is it always in RGB/RGBW order?
It would be the raw data from the fseq file.    Thus, it would depend on how things are configured in xLights. 
Daniel Kulp -


Great, I haven't tested a ton yet but this seems to do what I want for these lights:

It is a "four to six" processor that takes a RGBW input and turns it into RGBWWW (or WRGB > WWWRGB). Using that I can model the Govee string as RGBW pixels in xLights and just have FPP expand each pixel from 4 bytes to 6 bytes.


Well it sort of works, I have to also go into the Channel Outputs config and fudge the number of pixels so that the End Channel number lines up with the 4 to 6 byte expansion. Is there any way to do that automatically?


@dkulp can you verify that even if the OutputProcessor expands the channel range via GetRequiredChannelRanges only the channels up to whatever the max indicated on the Channel Outputs tab are sent?

For example if I have a 30 node RGBW string from Channel 1 to 119, setup the 4 to 6 output which calculates a 179 channel buffer but only channels 1 to 119 are actually sent on the output. I'd have to change the node count on the output to match the channel count that the OutputProcessor generates?


Correct.   The only channels that are sent are what is configured on the various output pages.   
Daniel Kulp -


Any other thoughts on how to get FPP to do the channel expansion automatically? I can tweak the output channels manually but then that is maintenance overhead when uploading from xLights.

For now I think I'll just resort to submodels in xLights to deal with the RGBWWW node pattern.

Support FPP

+- Recent Topics

Did the the latest upgrade tonight and it failed. by MikeKrebs
June 10, 2024, 09:19:42 PM

No Audio by Steve
June 07, 2024, 02:10:47 PM

Video IP Capture -> sound by MikeKrebs
June 06, 2024, 09:00:17 PM

Control Channel Output by zj023
June 03, 2024, 06:23:35 AM

Compatibility question by John_82
June 02, 2024, 04:23:25 PM

Virtual Display not working? by colonelcline
June 01, 2024, 04:55:41 PM

Help for my LED Pit board project by Octonath
May 31, 2024, 06:15:17 PM

Help, can't get PCA9685 working with xLights and FPP by dkulp
May 30, 2024, 08:54:53 AM

HELP Did something dumb - turned on Tethering by The Engineer
May 27, 2024, 06:39:38 PM

First Time User - Can't open GUI only Terminal by k6ccc
May 27, 2024, 09:51:34 AM

Powered by EzPortal
Powered by SMFPacks Menu Editor Mod