WLED
WLED copied to clipboard
Aircoookie
Support for Fw1906
Add support for RgbwwColor and GRBCW strips that use FW1906 chips.
This change requires: https://github.com/Aircoookie/WLED/pull/3293 and https://github.com/Makuna/NeoPixelBus/commit/978b62f84137266bc2a47ea49759c1b15e2c8f5c The fix in NeoPixelBus is not in any release yet, and I don't know the way to force platformio to fetch specific commit, so I temporary changed lib_deps to my branch, if someone wants to test. This needs to be changed before merging.
You can use something similar to:
https://github.com/makuna/neopixelbus#978b62f
in lib_deps to force specific commit to be used for a library.
Unfortunately I do not like using unreleased libraries so we'll probably wait until new version of NPB is released as I mentioned elsewhere that last NPB update caused us hedaches we are still recovering from.
I was trying this # notation but it seems not working in lib_deps. Its understandable that this change needs to wait for new release of NeoPixelBus. I push this for review, and for other people to test.
It does whe properly formatted. I'm away from computer so can't provide exact format ATM.
Instead of adding a 5th value in
setPixelColor()please extendPolyBusclass to use pre-set CCT (perhaps as additional variable). Then extendBusManagerto set this value from CCT methods it provides.
I've done it in a little different way. Instead of adding new static variables I call a static function from class Bus in PolyBus.
I hate the idea of mixing Bus into PolyBus so I removed the dependency. I am not satisfied with the solution as it breaks regular behaviour of setPixelColor but I have yet to come up with something better. 😄
There is also an issue you did not address and that is reverse CCT for retrieving pixel information from getPixelColor(). Current implementation is lacking and needs to be addressed.
I assumed that it is not an issue, no reverse CCT is used for other pixel formats in digital and PWM buses.
I assumed that it is not an issue, no reverse CCT is used for other pixel formats in digital and PWM buses.
Other CCT enabled bus (BusPwm) only ever deals with 1 pixel so quite less important (as no 1 pixel effects rely on previous pixel value) than BusDigital. But of course it is a flaw and you can address it if you wish at the same time.
@Robert-github-com I have re-checked original source regarding CCT handling (BusPwm) and came to conclusion that best approach would be to move your calculateCCT() out of Bus class as it has nothing to do with buses as such and place it into colors.cpp as a standalone function.
Then it would be Ok for me to be included in PolyBus as you originally intended.
Nevertheless, PolyBus currently has no concept of CCT and API only allows for uint32_t for color object so there is still something missing for linking bus CCT value and PolyBus way of rendering it in the "correct" way. (Don't forget BusPwm handles CCT internally ATM.)
@Aircoookie and @softhack007 what would be your idea for adding CCT handling to PolyBus? Do we keep it external in a similar way as I updated it or do we extend PolyBus API to include either CCT info or WW & CW color bytes? Or something completely different?
@blazoncek this is something I already thought a lot about when originally adding CCT support. Right now, there is just one CCT value per segment, so individual-pixel CCT control is not possible on the segment level. Also, there is no way to e.g. use a warm CT as primary and a cold as secondary color. This, as well as per-pixel CCT control is possible right now, but only with "CCT from RGB" mode, which was made with CCT-only devices in mind. For addressable RGBCCT like the FW1906, having CCT as part of the segment color objects becomes something we should seriously consider looking into.
I'd say adding support for CCT to PolyBus specifically should be as simple as adding another uint16_t (or uint32_t for performance?) parameter to PolyBus::setPixelColor(). I would pass the WW and CW bytes and do the conversion from CCT on the BusDigital level, though it shouldn't technically matter where it's done.
This will already give us per-segment CCT functionality, and we can look into adding true addressable CCT down the line. One option might be a custom color object used throughout all layers from Segment to BusDigital, or even use uint64_t down to PolyBus level. I'd assume this to have quite the performance impact though, so it'd be something we just have to test.
Also thought about cramming everything into the uint32_t and dealing with just 4 bits for white brightness and color temperature each, but excluded that possibility as it would be a terrible user experience, especially during transitions.
I'm trying to compile this right now and give it a try as I have a similar light strip! Wish me luck!
Unfortunately the chips in my strips appear to be something other than the FW1906, despite having a similar LED configuration. The chips themselves are entirely unlabled.
Sorry Robert, I wish I could have helped test this:
Hi folks, I've squashed all the cleanup to create a minimal set of patches, and rebased on top of the current main. @Robert-github-com , you can grab it here: https://github.com/deece/WLED/tree/fw1906
Hi folks, I've squashed all the cleanup to create a minimal set of patches, and rebased on top of the current main. @Robert-github-com , you can grab it here: https://github.com/deece/WLED/tree/fw1906
Great! Seems to work fine.
It worked for me. One small problem is that I can't seem to be able to change it to a mode where only the white LEDs are used with a blend of cold and warm color temperatures.
As shown in the screenshot, when I change the first slider to the left (turning off the color LED altogether), the second slide automatically slides to the rightmost (cold white), If I drag the second slider (white point) anywhere towards the left, the first slide immediately goes to 100%, and the color LEDs turn on (lower CRI) and make the color of objects in the room look weird.
Thanks!
It appears that because I implemented enabled Calculate CCT from RGB WLED can integrate with home assistant. Not sure if this is the expected behavior 🤔
@deece Hey man I compiled your FW1906 fork and uploaded to my ESP32. I cant see the option for FW1906 in the LED config.
It appears that because I implemented enabled Calculate CCT from RGB WLED can integrate with home assistant. Not sure if this is the expected behavior 🤔
That is a HA issue. It will not allow WLED with CCT.
cant see the option for FW1906 in the LED config.
If you modify UI files in wled00/data, make sure to run npm install; npm run build in the console, and then rebuild the firmware. If you skip the "npm" step, modified UI files will not make it into the firmware.
https://kno.wled.ge/advanced/custom-features/#changing-web-ui
cant see the option for FW1906 in the LED config.
If you modify UI files in wled00/data, make sure to run
npm install; npm run buildin the console, and then rebuild the firmware. If you skip the "npm" step, modified UI files will not make it into the firmware.https://kno.wled.ge/advanced/custom-features/#changing-web-ui
Hey man thanks for the reply. Im not much of a coder but can manage to compile wled in vscode. I am not quite sure on how i do this at all. Any extra help would be muchly appreciated. Thanks
@oakey81 first you need to install NodeJS 11.0+ globally. Then run npm install; npm run build in the VSCode console panel.
https://kno.wled.ge/advanced/custom-features/#changing-web-ui
@oakey81 first you need to install NodeJS 11.0+ globally. Then run
npm install; npm run buildin the VSCode console panel.https://kno.wled.ge/advanced/custom-features/#changing-web-ui
Thanks mate yeah it was the 'npm i' that i missed. sorted now and my setup works perfectly with all colours the right way round. I think some of the strips are not FW1906 IC and thats why the colour orders arent matching up. I actually ordered 200 x FW1906 ICs and have designed my own 5ch driver and RGBCW/WW downlight.
https://github.com/Aircoookie/WLED/assets/83114787/8db4026a-518c-4437-965c-3849a4e7cec5
@oakey81 please update and rebase for 0_15 branch if you think it is viable solution worth to be included and make a PR.
@blazoncek I am not sure what you mean by rebase as i am not a coder. My mate is very good at it and he saw what i was missing within about 30 sec. I just downloaded the FW1906 code off github and done the npm install and compiled to upload on my ESP32. And as i had designed my own 5ch driver board I followed the manufacturers data sheet and it runs perfectly. I do believe some of the RGBCCT strips might not be FW1906 ICs on them. But to answer your question. Yes I believe this is a viable PR for the next update. And also I see that the WS2805 RGBCCT IC has been released as a true 5ch chip not like the FW1906 6ch chip. So that could be another to add later aswell.
I believe this was intended for @Robert-github-com . I already rebased and squashed down to a minimal set (see my earlier comments), so hopefully they're isn't much to change from there.
@blazoncek I am not sure what you mean by rebase as i am not a coder. My mate is very good at it and he saw what i was missing within about 30 sec. I just downloaded the FW1906 code off github and done the npm install and compiled to upload on my ESP32. And as i had designed my own 5ch driver board I followed the manufacturers data sheet and it runs perfectly. I do believe some of the RGBCCT strips might not be FW1906 ICs on them. But to answer your question. Yes I believe this is a viable PR for the next update. And also I see that the WS2805 RGBCCT IC has been released as a true 5ch chip not like the FW1906 6ch chip. So that could be another to add later aswell.
@deece Sorry I was just answering @blazoncek. As this is what he asked me. But as far as i can tell as a user of this it seems to work well with my hardware. Cheers for what u had done.
Unless someone makes a PR for 0_15 branch we're not going anywhere with this (until 0_15 is merged to main which may be months away). I have more than enough other work and this is low priority for me.
As you can see from comments above the PR may require change in the very core of how WLED handles color and CCT so it will not be lightly taken.
Hi guys, I'm seeing more and more of those chips out there, any news on official support? Thank you
