@mike.maxwell
Just tested the Lutron changeLevel commands for the first time and noticed this.
If I startLevelChange(down) on my Caseta light it does not go till the light turns off. The state shows as off, but there is still partial illumination of my bulb. Looking at the logs I see the following.
The highlighted logs show a light level of 0.01 which is technically not 0 and the switch state shows as off and the level remains the same as it was when I first started the level change.
Stopping the level change before it gets to its lowest point returns the correct level and switch state.
This is what Lutron does. When you give it that command, it goes straight to the Lutron system as Start Lowering. I'm not aware of anything that says what the result of that should be, so what you are seeing is the result. Why Lutron does it that way is inscrutable. If you want it to actually dim to zero, you would have to send an off() command or setLevel(0) command to it.
Lutron reports dimmer levels as decimal values, hence the 0.1. Nothing else does that, so we decided to deal with dimmer levels as integers uniformly. So, 0.1 is being rounded to 0 in the driver.
I just tested this on a RA2 system. The light dims to off, and reports absolutely nothing back. So the driver / device still thinks it's on at 90, where it started. Then giving it Start Raising had the same result, nada, but the light came back up to full on, and reported nothing. So, this feature is not really very useful.
What does work as expected is dim to 0 with a fade time. I just set the light to 50, then gave it setLevel(0,5). Nice smooth dim to off, both in the real world and the driver / device.
I actually don't use the changelevel on my Caseta switches. I use the picos, so this is a non-issue for me. It was just something I noticed when I tried it from the driver page out of simple curiosity.
The reason I presented it to you was mainly because of the inaccurate switch state. It shows as off in HE when the light is actually still on. This could present an issue with automations for those not using picos to control these switches. Really just an FYI.
Nothing to be done about that if Lutron doesn't report it.
When I first read this thread, I thought it might be related to the problems with the startLevelChange
and stopLevelChange
commands on Hue Bridge bulbs a couple of us noticed here: Hue lights Start Level Change
However, upon further reading, it appears the end result is the same but for a different reason. The Hue lights correctly report their (brightness) level, but the switch state somehow shows as "off" in Hubitat despite the switch actually being on, and it corrects itself at some point after (not sure if it's the next scheduled refresh since a manual refresh doesn't fix it for me).
if the Lutron problem can't be fixed, I'd be curious if the Hue one can at least be investigated. I see Patrick wasn't able to replicate it, but I'm not sure if maybe it's just that the problem wasn't clearly explained. I can on both of my hubs with any light on my Hue bridge I've tried so far.