I have an LZW45 that I change the color on based on conditions. High level, they are an accent color until motion is detected, and then they fade to white … when the motion stops, they turn off, and then (are supposed to) fade back on to the initial color they were.
The off/on process to go back to the color is because I never found a way to gracefully transition from a white to an rgb … though there is a way from rgb to white. And this is where things go awry. The color staging used to work occasionally (not reliably), but now it seems not to work at all.
For example, if the lights were set to blue but turned off when the white transition happens … the transition back pre-stages the color back to blue, but isn’t supposed to turn the leds back on … the setting of the color immediately turns the lights on to blue and then turns them back off. The catch is that the color just ‘snaps’ in to existence without the soft start that you get when you just turn them on. This is also an issue if the lights were on to start … the off->pre-stage->on sequence was used to prevent the harsh transition from white to RGB, but since the pre-stage act turns the lights on in a snap, that objective is failing.
I don’t know if this is a firmware bug, a driver bug, or simple user error, but I’ve tried this every way I can think to, so perhaps someone here or @EricM_Inovelli can weigh in if this is just expected behavior.
This is a dead simple rule-machine rule that consistently reproduces the issue … if the lights are off, and I just run the actions, they flash on, and go back of.
I’m running a Hubitat C-5 with the latest firmware
LZW45 has firmware 1.2
LZW45 driver has the last revision dated 2022-05-04
“Enable Color Pre-staging” is active (I’ve enabled/disabled this and run Configure several times)
Does the value of the “switch” attribute under “Current States” on the device detail page update as expected? Enabling debug logging for the device and looking at Logs might also give you more clues. Also, does the same thing happen with “Set Color” from the device page, or is this a Rule-specific issue?
That being said, I hope Hubitat standardizes this command some day instead of using a preference, which changes the behavior of the standard command and can mess up a lot of apps that use it. The LIFX drivers added a “Preset Color” command that isn’t official yet, but I assume it’s the direction they’re moving in, and it may help with some things like this too…eventually.
I’ve played a lot with this, and I believe this is a driver bug. When I use the same code and such with an LZW42, everything works as expected … I’m only seeing this behavior with the LZW45.
An early revision to the driver added the pre-staging option, while later versions also made color changes … could there have been an unintended collision, maybe?
The state in Hubitat does not reflect the fact that the switch has pulsed back on when the color is staged, and there is nothing in the logs that indicates the event ever occurred.
I know that the Inovelli guys have there hands full with the Blue series right now, but once they get breather, maybe @EricM_Inovelli can take a look … my gut is telling me this is a driver bug.
Hmm …well, that’s very interesting; in my rule (that looks like yours) I could click run actions as frequently or infrequently as I wanted with the LEDs off, and they would always pulse back on and turn off.
I noticed in your screen shot the slight difference in the rule machine display which must be Hubitat 2.3.3 changes (which I had just upgraded to … I started this post about 2 weeks ago) … So I went back and ran my pre-stage test rule again and it no longer reproduced the issue like it did when I started the thread.
However, knowing that I still saw the issue in the actual rule the runs on triggers, I looked again to see what else might still be going on there. The relevant section goes like this:
Dim to 0 → fade time 2 seconds
Delay 3 seconds (to allow the 2 second fade to complete)
Stage the color
Since the pre-stage test no longer pulsed the LEDs, I tried increasing the delay and now a delay of 5 seconds is enough for the switch to finish whatever it is doing and be fully ‘off’ most of the time (4 seconds was hit or miss). It seems that If the staging occurs before the switch has reached a steady state of off, the LEDs pulse back on and then the unit shuts off (makes sense). A 5 seconds wait seems to be a long delay for a 2 second process to end, but it’s much more graceful then the pulse … so I can work with it. I guess it could have been related to 2.3.2? No idea, just speculating about that, but if it comes back, I’ll have to suspect 2.3.4 which I am loading now. Thanks for looking at it.
On the subject though, there is a way to transition gracefully from an RGB directly to a color temperature with a fade time … but there is no way to do the opposite. Perhaps that could be added in the next driver, or firmware change? If I could reverse the process gracefully, I wouldn’t even need this hack.
It implements a little differently than the fade to a color temperature … but this totally works and it’s soooo much more graceful then the hack was. Time to implement a bunch of rule changes … I’ll let you know if I run into any unexpected behavior.
