LZW45 Quick Strip Effects Calculations

Here are the calculations for each byte.

Byte1: Color

hue wheel - Set in byte 4 (colors ranging from 0 to 360)

Click here to pick your color, look at the HSL field and pull the first number.

calculation:

byte1 = h / 360 * 255

color temp - Set in byte 4 (temps range from 2700 to 6500)

calculation:

byte1 = (temp - 2700) / (6500-2700) * 255

Byte2: Color Level (brightness)

Brightness in increments of 10% (levels 1 - 10)

calculation:

byte2 = level * 256

If you want to set this between 0 and 99, it gets tricky, but this is the calcuation:

byte2 = 32768 + level * 256

Byte3: Duration

This can only be set in increments of 0 - 60 seconds, 0 to 60 minutes, 0 to 60 hours, or forever. You cannot mix and match minutes, seconds, or hours. They are mutually exclusive.

0 - 60 seconds

byte3 = 65536 * seconds

0 - 60 minutes

byte3 = 65536 * (minutes + 60)

0 - 60 hours

byte3 = 65536 * (hours + 120)

forever

byte3 = 16711680

Byte4: Effect & Color Type

This byte also effects Byte1. Use the appropriate calculation. If color type is set to 0, use the hue wheel equation. If color type is set to 1073741824, use color temp equation.

This one can seem complicated but it’s really not. If you’re using color temp, add 1073741824 to every value. If you’re not using color temp, add 0 to every value.

hue wheel color

color_type = 0

color temp color

color_type = 1073741824

Off

byte4 = color_type + 0

Solid

byte4 = color_type + 16777216

Chase

byte4 = color_type + 33554432

Fast Blink

byte4 = color_type + 50331648

Slow Blink

byte4 = color_type + 67108864

Fast Fade

byte4 = color_type + 83886080

Slow Fade

byte4 = color_type + 100663296

Finalizing your result

config_value = byte4 + byte3 + byte2 + byte1
5 Likes

Thanks so much for the breakdown! I was messing around trying to set parameter 21 in node red via a subflow unsuccessfully until I ran into this post. It now works perfectly with the exception of brightness. No matter what I set, the value always appears as max brightness (which honestly doesn’t bug me since I’d only ever use max brightness anyways. I was hoping to eventually release this once it’s fine tuned though, so it would be nice if all works).

Tried a few different equations, used both of yours above and a couple of mine which more or less break back down to what you have listed anyways:

byte2 = level * 256
byte2 = 32768 + level * 256
byte2 = (level / 10) * 256 (for if you accept values 0 - 100 but don't use 32768)
byte2= (level / 99) * 100 (which is apparently how parameter 23 is set for brightness, but doesn't appear to work here)

The value is calculated successfully and the config option is ultimately set as expected, so it’s not an issue with my subflow. I even did the calculations manually to double check.

Any idea if other configuration options interfere with brightness? I’m going to keep playing around with this in the mean time, if I figure anything out on my end I’ll circle back.

That’s correct but only works if level = 1, 2, 3, 4, 5, 6, 7, 8, 9, or 10. Nothing else. 1 = 10%, 2 = 20%, etc.

This is correct if you want to use increments of 1 instead of 10. So this will work for 1 to 99, where 1 - 99 = %.

1 Like

Really appreciate your assistance, I just have no idea what I’m doing wrong then. I went back to using byte2 = 32768 + level * 256 only as I like the ability to define any value between 1 and 99, but it’s still only spitting out max brightness. Do you maybe see an error in my calculation?

I’m shooting for white at 4500K, 50% brightness, forever with a solid effect type.

temp = 4500
level = 50
duration = 16711680
color_type = 1073741824

byte1 = ( 4500 - 2700 ) / (6500 - 2700) * 255 = 120.789473.... -> 121 rounded
byte2 = ( 32768 + 50 * 256) = 45568
byte3 = (16711680)
byte4 = (1073741824 + 16777216) = 1090519040

1090519040 + 16711680  + 45568 + 121 = 1107276409

Hopefully this is followable, I know my subflow is calculating correctly as I just double checked all those values by hand, but this still only ever gives me max brightness. Changing level to different values does spit out a different number, but it’s only ever max brightness… Hoping I’m just overlooking something stupid :slight_smile:

try just 2560 for it.

Wasn’t sure exactly which value to define as just 2560 so I tried a few different ones. I set brightness itself as 2560, so byte2 = 2560. That resulted in max brightness again.

I tried setting parameter 21 itself as 2560 and that didn’t do anything. Lastly, I also tried setting the value of level to 2560, so 32768 + 2560 * 256, but that also ended up not turning the strip on at all once added to the rest of the equation. Thanks again for your assistance. I’m going to also poke around with different parameters to see if something might be interfering somehow.

It overwrites the whole thing, this is most likely a bug in the firmware. 2560 should be 10% unless I have the documentation wrong which is quite possible. @EricM_Inovelli do you have any incite?

1 Like

Yeah just double checked one more time just in case, but 1090519040 + 16711680 + 2560 + 121 = 1107233401, which is solid white but at max brightness and not 10%. Could be a bug then, but everything else works very well!

One thing I found interesting while working on this, is that the max brightness defined here is actually brighter than the max brightness if set elsewhere outside of parameter 21. So one of my automations uses the service call node in node red to set brightness to 99%. When set to 99% here, the brightness is actually fairly substantially dimmer than the max brightness if set through parameter 21. Maybe that has something to do with it, who knows! I personally prefer max brightness and would likely only ever use this as such so I’m still happy, but if anyone wants a hand testing this out I’m happy to do so!

I’ll release my subflow soon once I’ve fine tuned it a little more. It’s mostly done, but wanted to define a few other color options to line up with what can be done in parameter 22.

Apologies, scratch what I was saying. Brightness works just fine, but what appears to be the case is brightness cannot be defined when the effect being used is Solid.

I did almost all of my testing with solid, but once I changed it to something like chase or slow blink brightness worked just fine. Sorry for all the confusion, and thank you once again for your help! :slight_smile:

1 Like

There is a firmware bug related to brightness in the quick effect parameter that we are working on. I’ll post back here when we have it fixed.

1 Like