I’ve got several pixelblazes integrated into room lighting with relatively hard to access LED strips, some of which now have single pixel failures. The failures are a bit odd (to me) in that they corrupt downstream data if the LED is being driven but pass it through just fine if the LED is off. In my patterns, to avoid having to strip out all the hardware, I’m now doing something like ‘if index==broken_led_index { hsv(0,0,0); return’ }', but it’s a bit of a pain to have to do this for all patterns.
It’d be great if the mapper, or some other configuration part of the system, had the ability to mark an LED as dead in this way (and then just not call the render function for it), because I’ve now seen this on strips from two different vendors in two different installations.
In general I’d love a way to set per-LED properties as a general thing, but this simple version would make my life much easier when dealing with these failures. I’m expecting to have more of them as well over time - ideally it wouldn’t happen or I’d change the hardware, but it’s not easy to do that and I can live with one or two LEDs in my cabinets being off much more than I can live with the epilepsy inducing strobing that happens when the failed LED is being driven normally!
They’re WS2812 strips, they’ve been running fine for a while but in both installations there’s now this problem, adding the ‘don’t light up this LED’ code to the patterns fixes the glitching (which is extremely unpleasant strobing of random data) at the cost of a missing LED, which isn’t critical in this context. Both cases have around 250-300 LEDs, there’s plenty of power etc, when they’re working they look great.
They’re used as cabinet lighting so yes, that’s quite possible. At least some of the programs run portions of the strips at full white and they get left on. Could be heat issues maybe? Either way, zeroing the problem LEDs does act as a decent fix for the immediate symptom, although it’d be nice to have a way to fix whatever’s causing them to fail!
Ok that makes sense. I suspect that in an effort to juice their data sheet stats, they spec these LEDs as “100% brightness is something that’s possible… but we won’t at all guarantee how long they will last at that power output”. Still, thank you for the suggestion, and I’m glad you found a decent workaround with the code to turn off specific LEDs.
When we can get around to figuring out a common-to-all-patterns code module, that will make it a lot easier to fix without copy-pasta.
Is there an existing thread for this because I was about to start one? I’d love to have the ability to set a prologue, for want of a better name, that’s effectively pre-pended to all pattern code so I can do some setup that’s inherent to the installation rather than having to copy it per-pattern. I guess the ‘fix broken LED’ is a specific case of this, but I have others (mostly setting up a mapping of LED index → shelf in my drinks cabinet…)
I’d love to have the ability to set a prologue, for want of a better name, that’s effectively pre-pended to all pattern code so I can do some setup that’s inherent to the installation rather than having to copy it per-pattern. I guess the ‘fix broken LED’ is a specific case of this, but I have others (mostly setting up a mapping of LED index → shelf in my drinks cabinet…)