I have several Zooz dimmers with 3 sec ramp rates.
The issue Iām having is that that the status feedback of the dimmer is laggy on the dashboard (both local and remote). This seems to be connected with the ramp rate. So I tap ON and only after 3 sec. the status is updated. I did not have such an issue with the same dimmers running on SmartThings. Once dimming starts, the status should update.
Is there any chance this could be implemented?
In my opinion this is how it should work - the on/off and the level status should be updated only after receiving a confirmation from the device.
If you power off the dimmer and try to change its state from the device page or from a rule - the status must not change, as the command was not confirmed by the device.
3 Likes
I do not think this is related to device communication. Like I said, works just fine with SmartThings.
See demo:
-
Notice the delay when turning ON.
-
Notice no delay when turning OFF. The delay only happens to the brightness status slider. This is expected.
So the ON feedback should function in the same way. Tile should turn yellow right away, and the actual brightness level feedback should come once dimming stops.
If the user is not physically there to see the light being turned ON, he instinctively wants to click the button again, assuming it did not go through. However, this then results in the light going OFF.
Probably because the driver generates an event "optimistically" after you send the command instead of waiting to hear back from the device? Hubitat normally waits to hear back from the device. This is the approach mentioned above. You can turn on debug logging to see what data is coming in from the device when. Chances are, the "delay" is in the device sending data back, not something in the driver.
If you want different behavior, you'll either need a custom driver with different behavior (I don't recommend that for the same reasons as above) or ask Zooz to change the way the device firmware works.
Is this actually causing a problem for you, or are you just curious about the behavior?
1 Like
Are you saying the communication delay is only with the ON command? Very unlikely...
Notice the feedback for the OFF tap in the GIF attached is right away.
The Z-Wave logs also seem to indicate that response is "instantaneous" for both commands.
No, I am saying the "delay" is between the receipt of the "On" command by the device (typically nearly instant after sending) and the sending of a report from the device back to the hub containing the fact that the device is now on. Again, if you enable debug logging, you will see what the device sends to the hub when (for a switch or dimmer turning on or off, the Z-Wave commands you'll be looking for are sometnhing like "SwitchBinaryReport," "SwitchMultilevelReport," or perhaps "BasicReport").
To be clear, this would all be happening on the device side: the device receives the command, turns on, then sends a report back to the hub noting that is has been turned on. The timing of that last thing probably does not happen until the light has fully ramped up. That is under control of the device, not the hub (unless the device offers confiuration parameters to change this behavior).
1 Like
I can confirm that the logs show the same rate of response for both commands.
It does seem to be "optimistic" as you say for the "OFF" command only. So, as I show in the demo, response to the tile's off state is instantaneous. But the dimmer level slides down only after the light fully turns OFF.
It is not so "optimistic" for the ON command.
So it seems to be a matter of inconsistency on Hubitat's side.
I would prefer that the ON behavior worked the same as the OFF ->
- change status of light right away,
- slide dimmer state on/off once confirmation is received.
This give more level of feedback, both tactile and actual status confirmation.
In what ways? Debug logging shows you what is coming into the hub (from the device) when. The device is sending an "off" report right way -- the hub is not doing anything "optimistically" there, either. The device is also sending an "on" report, but only after the light is fully on. This is a firmware choice made by the device manufacturer, and your choices are as I stated above. The hub/driver is not reporting anything except for what the device tells it and when.
You did not provide that information or indicate that you looked (at debug logs, which must be specifically turned on, not the descriptionText/info logs), but it's the case with nearly 100% of Z-Wave devices, including all Zooz devices and drivers I've used, so until proven otherwise... 
But again:
1 Like
What driver are you using? Try my driver [DRIVER] Zooz ZEN Switches Advanced (and Dimmers)
Turn on debug logging, it will log every incoming message from the device.
Post a screenshot of the results.
I am pretty sure, as was said above, that the device does not respond until it is finished with the transition.
With my driver linked above, the events will get posted only when the device sends something back, otherwise we assume the device did not take action so no state change is made.
The driver could be modified to issue a "get" request right after the set, which may force the device to respond quicker, but I am not sure what that response would be.
If you want me to test anything specific let me know, I have all the different Zooz dimmers and I also maintain the driver posted above.
3 Likes
Have you reviewed the demo gif I posted?
Debug logging shows you what is coming into the hub (from the device) when. The device is sending an "off" report right way -- the hub is not doing anything "optimistically" there, either.
As I pointed out, the debug logging is consistent. What is inconsistent is the feedback on the dashboard. So the time to respond to confirm the ON and OFF status is identical (per debug). But on the dashboard feedback it is not.
Is this actually causing a problem for you, or are you just curious about the behavior?
Yes:
@jtp10181 Do you not observe the same behavior on the dashboard with Zooz dimmers as in my demo?
I am using the Zooz ZEN77 800 series dimmers. Driver: "Zooz Zen77 Dimmer".
In case there is confusion on the demo gif, the red radar effect indicates the moment the tile is clicked.
Yes. I understand the behavior you are describing. I am simply explaining why it works this way.
Please provide the output of debug logs that demonstrates this behavior.
1 Like
dev:142024-03-07 16:24:39.465infoStage Track 3 was turned off
dev:142024-03-07 16:24:39.463infoStage Track 3 was set to 0
dev:142024-03-07 16:24:39.461debugparse:zw device: 10, command: 2603, payload: 00 00 00 , isMulticast: false
dev:142024-03-07 16:24:37.208debugsupervision report for session: 45
dev:142024-03-07 16:24:37.206debugparse:zw device: 10, command: 6C02, payload: 2D 01 02 , isMulticast: false
dev:142024-03-07 16:24:37.131debugnew supervised packet for session: 45
dev:142024-03-07 16:24:37.130debugoff()
dev:142024-03-07 16:24:34.178infoStage Track 3 was turned on
dev:142024-03-07 16:24:34.176infoStage Track 3 was set to 99
dev:142024-03-07 16:24:34.173debugparse:zw device: 10, command: 2603, payload: 63 63 00 , isMulticast: false
dev:142024-03-07 16:24:30.899debugsupervision report for session: 44
dev:142024-03-07 16:24:30.897debugparse:zw device: 10, command: 6C02, payload: 2C 01 03 , isMulticast: false
dev:142024-03-07 16:24:30.820debugnew supervised packet for session: 44
dev:142024-03-07 16:24:30.818debugon()
So the dashboard does show OFF status before the last line appears in the live logs:
dev:142024-03-07 16:24:39.465infoStage Track 3 was turned off
Everything I see in your Logs output is consistent with my explanation above. Specifically:
This is you sending the "On" command.
This is the device responding with a "SwitchMultiLevel" report indiciating that the device is on. This is approximately 3-4 seconds later, apparently for the reasons I described above. Again, when this report gets sent is under control of the device.
These indicate that the hub actually processed an event from the driver in response to the above report (just a few milliseconds later, so practically instant). This is when you would see the change reflected in apps, including Hubitat Dashboard (though cloud Dashboards may introduce a separate issue of polling delay--but that is not the problem based on your logs above).
EDIT: I do see a possible issue with "Off" in your logs (thanks for sharing those!), which could indeed be Dashboard responding differently to such taps -- this would be an app-specific issue if indeed the case, though I have not tested this with any device or noticed it myself.
I can test it out, I typically do not have a long ramp rate set and I also do not use dashboards very often.
My issue, as per OP, is that the dashboard feedback is different.
Before that line appear in the logs, the dashboard already updates to OFF.
I just want the same behavior for the ON tap.
Yeah you may be on to something, the dashboard may be pre-emptively showing the off state as soon as you tap on it, before the event is posted. That would explain why it shows off right away and then a second or so later the slider goes down to 0 (when the device actually responds).
1 Like
@vadimchp I am seeing similar to you. I changed my ZEN77 to be 5 seconds ramp rate both ways.
The main difference I have is the hourglass icon. I think because you are using custom icons that is not showing for you. Also I noticed on yours when you turn it off the slider eventually goes down to 0, mine is not doing that probably due to the driver. I am guessing the driver you are using is setting the level to 0 when it turns off which IMO is a bad practice. I like to keep the level showing where it was and only changing the state to off.
1 Like
I see your point. Though I think the instant tactile feedback is still more important. If there was a 3rd color used to indicate this (like a dark/grayed yellow), that would allow us to clearly distinguish between a tap/click and a status update.
How do we forward this issue to the developers?
Probably make a post in the feedback section, you could give a link to this thread for reference.
