I've run into a rather strange issue with setting colur/level in one of my rules. Very simple rule, reproduceable every time. 2.3.0.113. Bulb is a inovelli RBG z-wave bulb.
Very simple rule. When furnace is running in heat mode set my notification light to red. Light gets set either bright or dim depending on the modem (don't need a real bright red light in the evening, but brighter during day so it can be seen).
What I am seeing is that the light comes on correctly, but the level never gets set correctly. Here you can see from the logs that the correct 50% runs, but upon checking the level in the device, its running at 100% (the last level I manually set it to)
okay, now I am completely baffled. I wrote the following rule to test a few things.
given I start with notification light (last was RED, but off), I run the following. I would expect the light to turn blue.. wait 10 seconds, go to green, wait 10 seconds, and then change back to blue.
Instead the final color of the light is RED when it restores. What am I missing?
What driver are you using for this bulb? From your description, it sounds like the state on the hub is not getting updated accurately, or possibly just not in a timely manner. Among other ways to check this, you can look at "Current States" on the device page as either you or an app changes things. If it's wrong there, Rule Machine will also capture (and restore) the "wrong" state--that's all it knows, too.
mode is evening. Here is the log when it runs. The light ends up as RED.
dev:9112021-11-29 06:51:23.857 pm infoNotification light color mode is RGB
app:15182021-11-29 06:51:23.840 pm infoAction: Restore: Notification light
app:15182021-11-29 06:51:23.829 pm infoDelay Over: Delay 0:00:10
dev:9112021-11-29 06:51:15.113 pm infoNotification light was set to 99%
dev:9112021-11-29 06:51:15.110 pm infoNotification light was turned on
dev:9112021-11-29 06:51:14.085 pm infoNotification light was set to 99%
dev:9112021-11-29 06:51:14.082 pm infoNotification light was turned on
app:15182021-11-29 06:51:13.790 pm infoAction: Delay 0:00:10
dev:9112021-11-29 06:51:13.786 pm infoNotification light color mode is RGB
app:15182021-11-29 06:51:13.767 pm infoAction: Color per mode: Notification light
Evening: Green -> Level: 100
app:15182021-11-29 06:51:13.754 pm infoAction: Capture: Notification light
app:15182021-11-29 06:51:13.743 pm infoDelay Over: Delay 0:00:10
dev:9112021-11-29 06:51:12.342 pm infoNotification light was set to 99%
dev:9112021-11-29 06:51:12.339 pm infoNotification light was turned on
dev:9112021-11-29 06:51:08.056 pm infoNotification light was set to 99%
dev:9112021-11-29 06:51:08.053 pm infoNotification light was turned on
dev:9112021-11-29 06:51:04.292 pm infoNotification light was set to 99%
dev:9112021-11-29 06:51:04.289 pm infoNotification light was turned on
app:15182021-11-29 06:51:03.704 pm infoAction: Delay 0:00:10
dev:9112021-11-29 06:51:03.699 pm infoNotification light color mode is RGB
app:15182021-11-29 06:51:03.559 pm infoAction: Color per mode: Notification light
I don't see any color information in the logs, so that could be an issue. But the authoritative source would be "Current States" (or "Events" for history) on the device page. For color, you're mostly looking for the hue attribute. Values close to 0 or 100 are red. Green and blue should be...somewhere in the middle, with green a bit lower than blue. The "color" name attribute should also be accurate, though it's up to the driver what to report there.
well that is interesting.. you might have just hit on something. if I go to the device page, and set the bulb to say "hue:25". The bulb turns yellow. Current state though still shows the hue as 0 (red).
I have to "refresh" the bulb to pick up the correct state.. doesn't seem right to me.
Sounds like the problem to me! But now the question is why that's happening. What driver are you using? (There is a built-in driver but at least one community offering.) Also, is the bulb paired with security? Check for an "S2" entry under "Device Details" or look at the hub Z-Wave Details page to check. Since these devices only support S0, you'd be better off pairing them without.
Getting closer. Swapped out the built in driver for Bryan's written inovelli driver. getting much more useful information. Levels and Hue are showing up in the log. Its seems like now the initial problem with with the capture/restore. The hue is not always being reported back correctly, so the capture is returning storing the incorrect color. Here is a run of the test app from the beginning in the log
This happens to me as well, using Hue lights set to a Bulb Group with Groups and Scenes 2.1. It is 100% reproducible on the latest firmware (2.3.0.113), as it happens every time when setting either color temp or color AND level at the same time, when the color temp or color is already at the correct setting, The workaround is to set the color (or color temperature) per mode, THEN set the desired level per mode (and optional fade). Sucks having to have 2 rules, but it has been working perfectly.
What I learned from this..
don't use the built in LZW42 driver, it sucks.
Don't use restore/capture with these bulbs.. definitely gives weird results. I was able to work around that.
break the set color/level into two separate actions. Works correctly as birbeck says.
BTW, I recently picked up one of the lifx 1100 lumen color bulbs. Very nice. I find them very fast, and a whole lot brighter colors than the inovelli zwave bulb. (-:
I ran the little test app with the color change and capture/restore against the lifx bulb and it worked perfectly.
If you're using these on HE, not the Hue bridge, this is a known problem as of this past week. Sometimes the bulbs will ramp to the set level, then go right back to the previous level, but still say they are at whatever level they were supposed to be at. Any command sent after this will set them to the level they should have been at.
