Yes, that is almost certainly a bad pixel. It can happen if the green and blue elements become damaged or disconnected. With strips there are a number of factors that can cause it, often damage to the clear lens area.
If it is super distracting, you could add a bit of code to keep it black. Something like
export function render(index) {
if (index == 123) {
//"bad" pixel
rgb(0,0,0)
return;
}
// rest of pattern render code...
}
I think my WS2811’s are 7 years old now, and being one and half month outside each year is taking its toll.
And I just remembered that I replaced quite some pixels last year, because they were faulty as well. Luckily it’s just one this season, and it’s in a corner, so not affecting the patterns much.
This is so that the normal pattern code beneath it (see “// rest of pattern render code...”_ doesn’t also execute and overwrite the rgb(0,0,0).
Alternately you can put the if (index == 123 at the bottom of render() { and skip the return statement. It will overrule previous calls to rgb() and hsv(). This is a little less efficient though. If I’m disabling larger portions of my pixels than just a few, I at least like reclaiming the compute cycles.
A minor advantage of the return version is that the main portion of the render code isn’t indented and contained within another set of braces. I generally try to avoid code blocks that span longer than a screen worth, because you can lose the context of what you’re nested in.