Since updating my hub to 2.0 my light dimmers behave oddly. First I saw this in my HousePanel app so I thought it was my app, but then I tracked it down to the actual switch behavior. What is happening is when I click "On" in the main web interface, the light turns on and the Current State changes to "on" just like it should. However, when I click on "Off" the Current States switch status doesn't change to off. It stays set to "on". If I click Off again it changes. If I click poll it changes. If I set Level to 0 the light goes off and the status changes to off. I updated my code to use setLevel(0) in addition to the off() command, but this seems like a workaround hack to a bug to me. Prior to updating this didn't happen.
What type of device is this and what driver?
GE Zwave dimmer - same bug also on a newer GE Jasco Zwave dimmer
Driver is Generic Z-Wave Dimmer
the middle two in this screen grab both show this behavior
I was discussing something similar with the HE team last week. Seems like the dimmers update status as soon as the button is pressed, while it's still ramping down to off. @bravenel, were you guys looking at adding a delay or something after the "hail" before requesting an update from the dimmer?
@kewashi when you click the switch on and it ramps to full brightness, does it change to on/2% or something really low? Then when you click off it goes to something like on/85 or similar?
Are you referring to this thread?
Some of my (random as to which ones) dimmers do not report the correct state, and the situation does not update to the correct state later on. The indicated locked state will stay for days.
All the affected dimmers use Generic Zwave Dimmer or Generic ZWave Smart Dimmer. My Inovelli's do not exhibit this issue.
The reported dimmer state seems to be somewhat random. Sometimes it reports 10% other times 30% or other numbers. No matter how long I wait after clicking off the state never changes away from on to off. The workaround that seems to always work is to send a setLevel(0) command, which I can easily do in my HousePanel code. Others trying to use the built in web GUI will have to manually click on off again or poll or StopLevelChange.
Thanks for posting this @JohnRob - the discussion over there appears to be a variant of the same problem I am experiencing. Looks like I will just leave my workaround hack in place for now.
curious @kewashi, I have a bulb that acts like this at well.
try something for me? Set the dimmer to less than 30% and push off. See if it updates.
It was a different discussion via PM. My take on it is that it's a timing issue between the ramp on/off behavior of the switch (it takes ~3.5 seconds) and when the hub asks for an update from the switch (hub asks on non-Plus devices to get around the old Lutron patent is my understanding).
this is a bug in the generic zwave smart dimmer driver, will be fixed in the next release
Some of my devices (with this issue) use the "Generic ZWave dimmer" driver (i.e. not the "smart" version)
And @cwwilson08 I will post a HousePanel patch that works around this bug later today. As for your bulb, that sounds like a HousePanel race condition issue that can be solved by increasing your poll time from 5 seconds to 10. One day I will implement direct updates for local rPi installs since the HP server IP can be reached and I can hit it in a subscribe to events. This will only be possible on Hubitat and with a local endpoint install.
I meant from driver page. The bulb only updates to off first press IF I have it set to 30% or lower. Otherwise I have to push off twice. Was curious if the same behavior was shown with your dimmer device.
No worries though the bulb is really non critical. I made a topic about it some time ago. For an osram light. @mike.maxwell mentioned they we're going to make an adjustment. I don't know if that happened. The behavior remains for my light.
Was just wondering since your description is so similar to what I see if the problems we're related.
I set to 20% and turned on, then turned off and status is still wrong - so @cwwilson08 the dim level doesn’t make the bug vanish. I look forward for the team fixing this.