Error: Indexing outside of tuple - Doesn't work with RGBW?

[pauljones0]

I have a RGBW light and keep on getting an error that it is trying to index outside of the allowed tuple (ie. it's looking for the W component of the RGBW part of the light).

I was wondering if the community has a policy on how they want to handle the W component? I was thinking of rewriting this code to add a check for whether a RGBW light was being used and compensating for it by either:

1. Ignoring the W component (ie. W is always off)
2. Using the W component selectively to augment the color whenever a white/less saturated hue is desired

There may be other ways to handle the W component. I'm open to ideas or thoughts.

[Anders-Holst]

This is a bug. I intended the code to work for both RGB and RGBW, but have admittedly only had the chance to test it myself on plain RGB. The policy I implemented (or meant to have implemented) is currently to just ignore the white pixel, since all colors can be reached anyway (except possibly very bright tinted whites).

Do you possibly have the full python debug printout when this occurs, so I can see in which function and file it occurs? What command do you try to run when it happens?

Your help to debug this is highly appreciated!

Best Regards Anders

[pauljones0]

RGBW_210_v2.8.4_Errors.docx

I have attached a word docx containing all the sample files that I had issues with. Each heading in the docx lists the file with issues and the cause of the problems, but can be opened to reveal the full printout if needed. Let me know if this format is too hard to read and I can modify and/or adapt it.

[Anders-Holst]

Thank you for your thorough error report.

It appears though that the problem is not RGBW, but in most cases it is the layout: The index out of range errors occur when trying to access the y-coordinate of the layout, so apparently it is a one-dimensional layout. Have you tried to map your leds using the app?

Of course, it is still not so friendly for the code to crash. I am not sure which solution is best: Printing out a message that at least a 2D-layout is required for the effect and then stop, or try to do the best possible even if it will just come out as jumbled colors.

Day 17 is a different error. The effect works fine here so I can not repeat it, but my guess is that it is a numerical problem, making interpolation between two colors get outside of the accepted range. I thought I had fixed this in all places, but apparently not.

I have also observed the flashes when uploading a new movie. This started with firmware version 2.5.6 or therearound I believe. It is somewhat annoying but harmless. Someone suggested that the best solution is for the code to always turn off the leds during upload and then turn on afterwards. This is what the app is doing. However, then it will go completely black instead during upload, and for some effects it takes a long time to upload so I start wondering if connection has failed or it has crashed. With the flashes I at least see that something is happening. But probably I will go with the turn-off suggestion in the end. (It was the author of the candycane effect that suggested it. He actually turns it off during upload in this effect.)

The subtle flickering of some colors is also observed here at times. Annoying, but I do not know what to do about it. I don't see it in the two effects you point out though, but I heard other reports of it in other effects, and it appears to be slightly device dependent. I don't think it is an RGBW thing but can not be entirely sure. The day5 effect, what does it look like on your device? Does it slowly change along a spectrum as described? Which colors and brightness flickers the most?

Anders

[pauljones0]

Mapping: I have left my LEDS with the default generic mapping in the app, as I find that the app mis-maps LEDS that are obfuscated by furniture (like my bed).

Flashing: I will think a bit further on the flashing. I think it's an okay feature, but if one wishes to loop through the days or samples in xled_plus, it might get annoying.

Flickering: Day 5 effect:

• Lights up strands 6-10.

• Strand 6 has the most saturation, which decreases incrementally with each strand until it reaches strand 10 which is white.

• Hue changes over time time.

• All strands flicker at a very noticeable 30hz or so, but gently as if it's only a small % change.

• Strands 1-5 do not light up at all.

• Day 4 effect:

• Lights up strands 3-10

• Strand 3 and 10 are the most saturated, with strands 4/5 being the least so (seeming almost white)

• Strand 1 and 2 do not light up over time.

• Hues changes over time.

• About the same amount of flicker. Noticeable, but small. Gives off fluorescent tube flicker vibes.

[Anders-Holst]

There is something strange with the patterns as you describe them, maybe due to ordering of the leds. Or maybe I make some wrong assumptions about RGBW after all.

You have the Twinkly Wall, with 10 strings of 21 leds each, right? I would have suspected them to be ordered starting on string 1 and then going through each string until string 10.

Day 5 effect is supposed to go from black (not lit up) in one end, and then slowly increasing in strength of the current color until full saturation and brightness of that color in the middle, i.e string 5, and then from there to white. So strand 6-10 should behave as you describe it. However, at most a few leds at the very beginning of string 1 is expected to be completely black, then they should continuosly get more and more brightness until the end of string 5 / beginning of string 6. The transition should be so smooth that it would be very hard to say whether string 5 or string 6 is the most saturated. I do not understand why the first strings are all black in your case.

For day 4, it should have slowly changing opposite colors at opposite ends. Say if string 1 is green, then string 10 would be magenta. There is supposed to be a gradient between them, over completely white in the middle, and more and more saturated towards the outer strings. Again, strange that strings 1-2 do not light up. 1 should be most saturated, not 3. It is correct that strands 5-6 should be almost white. This is what makes me suspect some led index offset, but not sure how it can happen.

Have you tried to download and test the interactive color picker? (See #5 ) Then it would be possible to check:

• whether all leds light up or some strings remain black
• whether it can show darker colors at all
• whether it is fairly accurate in hue, compared to what is shown on the screen (for me, with RGB profile, it is very accurate)
• whether all colors flicker or only some

[pauljones0]

I'll run more diagnostic tests tomorrow. Hopefully, I'll find the issue.

[pauljones0]

I've mapped the lights using the app, and now the xled_plus.samples command in command prompt seems to run an infinite loop and doesn't actually do anything (tried with multiple different sample programs).

I'm right now busy with other things, so I think I'm going to leave this issue thread for now, and if I have time for it in the future, I'll come back.

[Anders-Holst]

There appear to be a problem sometimes with the discovery code (in xled) that it just hangs. When it happens to me I have to disconnect the leds from the power, reconnect, and try again. Very annoying. I have tried to understand why it happens but without success. A workaround is that if you know the ip-address of your leds, you can provide that as an extra argument when you run the sample program. For example: python -m xled_plus.samples.day30 192.168.10.203

I see. No problem. I have not been very active here myself lately.