HyperHDR VS NeoPixelBus

You can DIY your own with a IC-based RGB/RGBW strip and a rPi or x86 PC + ESP microcontroller using software like Hyperion or HyperHDR, combined with WLED.

This page https://github.com/awawa-dev/HyperHDR/wiki/Level-Shifter shows that a level shifter (3v3 to 5v) is needed for your lights.

If you're interested in a raspberry pi option using an hdmi splitter https://www.hyperhdr.eu

I spent a lot of time looking into this. Didn't want to lose HRD to implement Hyperion. I found the HyperHDR fork. Which will convert HRD signal to SDR and works really well out of the box. only thing I had to update was to turn the brightness down in the capture settings. Found a HDMI splitter on Amazon that handles CEC pass through. I lost Dolby Vision, because I couldn't find a splitter that will downgrade dolby vision to 1080p for the capture card. But I had to be honest with myself, I can't tell the difference between Dolby Vision and HDR 10+. Now I have an ambient light solution that allows me to keep HDR without dropping big bucks on something like HD Fury. Very Happy, works with HA still too.

This library (and some others) supports them: https://github.com/Makuna/NeoPixelBus

FastLED doesn't natively support RGBW addressable strips as of version 3.5.0 (October 2022). The alternate library NeoPixelBus does support RGBW strips, but handles animation in a completely different way than FastLED does.This snippet is an example of a way to shuttle data from FastLED RGB to NeoPixelBus RGBW, for folks (like me!) who prefer creating animations with FastLED.The additional library NPBColorLib is needed because NeoPixelBus doesn't (currently) use the white channel when converting RGB to RGBW -- see https://github.com/Makuna/NeoPixelBus/issues/323Tested with:FastLED, version 3.5.0 from https://github.com/FastLED/FastLEDNeoPixelBus, version 2.7.0 from https://github.com/Makuna/NeoPixelBusNPBColorLib, updated 2020-05-29 from https://github.com/jackjansen/NPBColorLib

I know it sounds insane, but it was an example script and I had issues with other example scripts too. Here's the example: https://github.com/Makuna/NeoPixelBus/blob/master/examples/NeoPixelBrightness/NeoPixelBrightness.ino

Do you mean https://github.com/Makuna/NeoPixelBus ?

One of the issues I ran into with LED chains (not the same kind of setup as this) was that some of the data pins on ESP8266 support hardware PWM and some don't. The LED library I used automatically did software PWM / bit-banging on the later pins. This bogged down the processor enough to make the wifi & IR-reception flakey when the number of LEDs was too high. https://github.com/Makuna/NeoPixelBus/wiki/ESP8266-NeoMethods has a bit on that - essentially only GPIO 1,2,3 support non-bit-banging. Depending on the board, you'll have different GPIO pins in different places, and some perhaps not available at all. I don't know how this LED panel is controlled, my guess is that some of the control pins need to be at high resolution, and that using hardware for that as much as possible will reduce the overhead needed, making it all run smoother.

That said, if you need RGBW support right now you could look at NeoPixelBus. It has very few of the capabilities of FastLED though...

Have you also tried Makuna's Neopixelbus for pushing out the RGBW pixels? Same thing with slower framerate?

Double-check that the outputs you chose will work for WLED (all of them will need "bit-banging" to generate the signal, which takes a bit of processing power - GPIO1,2,3 would be able to generate the signal directly). If you have a dev-board, this should be easy to check.