I believe this is a firmware bug in the Dimmers when using the Set Level command with a duration.
If the dimmer is ‘off’ and you send a SetLevel command, the dimmer will start ramping up to the requested level over the duration specified. The internal switch turns ‘on’ as soon as the dimming level goes above zero. That is expected. However, the switch ‘on’ status is not sent to the Hub until after the full duration has completed.
For example:
Sending a SetLevel(50,300) tells the dimmer to slowly fade up to 50% over 300 seconds (5 minutes). If the switch is initially in the ‘off’ state, the switch will turn ‘on’ at minimum brightness and slowly fade up BUT the hub has NOT been notified that the switch is ‘on’. Then AFTER the duration of 300 seconds the dimmer sends the ‘on’ status change to the hub. So, for 5 minutes, the switch is ‘on’ (power to the load terminal) but the hub believes it is ‘off’ because the ‘on’ status was not sent when the load switched from off to on.
This is less noticeable with short durations but can cause automation issues with longer durations. Any automations that use on/off status before performing an action may not work as expected. One classic example of this is a Dashboard which will indicate the light is off during the 5-minute slow fade up, even though the light is on that whole time. It gets worse with rules that test if a light is on or off before doing something else or triggering on action based on the off/on state change.
It is my belief that on/off state changes should be reported to the hub as soon as the state actually changes and not be waiting for any fades to finish. I.E. it should report on as soon as it turns on.
It likely depends on which commands your hub is using.
In Home Assistant using zwaveJS, if I send SetLevel(50,300), my hub is sending a Supervision Get command telling the dimmer to fade to 50% over 300 seconds, and the dimmer immediately responds with a SUCCESS message. At this point, Home Assistant is showing the dimmer as ON.
After 300 seconds, the dimmer sends an additional status report.
I’m using Hubitat and the Inovelli customer driver translates the groovy setLevel(value,duration) command to a zwave switchMultilevelSet(value,duration)
I’m not familiar with the Supervision Get command. Can you tell me the full syntax of what your HA zwaveJS is sending? Then I could try that command and see if I get the same results.
Just to confirm we are talking about the same thing. Are you saying the ‘Switch’ state in the hub is showing ‘on’ (on/off are the only two possibilities for this capability). Or are you saying the ‘Switch Level’ state is showing non-zero? They are two different capabilities reported to the hub.
Supervision Get is an encapsulated command, and within it is switchMultilevelSet. It basically tells the device to execute the Multilevel Set command, and to respond indicating whether the command was executed successfully or not. I am not really sure what the syntax looks like within zwavejs, but the command looks like this in a zwave packet sniffer:
(in this example I set it to a value of 50 and a duration of 60s)
The immediately responds with a Supervision report indicating the command was successful
As soon as the Supervision report is received, Home Assistant shows that the light is on, and is at 50% brightness (even though it is still slowly transitioning to 50%)
After 60 seconds, the device sends a Multilevel report indicating that the brightness value has changes, but nothing changes in Home Assistant because it was already showing that value.
The older Home Assistant zwave integrations (prior to zwavejs) would send a multilevel set command and then immediately poll the device to confirm that the command went through. This would “fix” the delay experienced when turning a light on, but would cause delays when turning a device off (because it is considered on until brightness reaches 0)
Home assistant is showing the target values (switch on, brightness 50%) immediately after issuing the command, even though the dimmer is still in the process of transiting to the new brightness value.
That is great info! Thanks for that I wonder where I can find the syntax My limited zwave docs don’t show “Supervision Get” command details but it does have all the switchMultilevelSet commands (and lots of others).
@EricM_Inovelli can you add any insight here? What I’d like to do is edit the groovy driver (DTH) to wrap the switchMultilevelSet command in the Supervision Get encapsulated command and see if I get the same results on Hubitat as jtronicus gets on HA.
If I immediately poll the device after the setLevel command is sent, I do get the ‘on’ status report and that is my work-around for the time being. But Hubitat doesn’t’ do that automatically, I have to create the two commands (‘setLevel’ (switchMultilevelSet) followed by ‘refresh’ (switchMultilevelGet). That mostly works but seems like a bit of a hack and creates more zwave traffic than necessary.
Ultimately, I still would like to see my original statement considered as a future fix to the firmware. I still believe that ANY time the switch state changes from off to on, the basic ‘on’ state should be reported imediately and not wait for any slow fading to complete. On should be reported as On even at the lowest dimming level and without requiring polling (or Supervision)
I wonder where I can find the syntax 
My limited zwave docs don’t show “Supervision Get” command details but it does have all the switchMultilevelSet commands (and lots of others).