Why are some log events marked `[physical]` though the event is produced by an automation action?

The screenshot looks like it’s showing a preceding event that occurred about 3 hours before, so I think we’ve got all the events here unless I have an incomplete assumption about the data or this view.

If a second event/response was logged, would it be shown here?

This is a Leviton DZ6HD Z-Wave Dimmer.

Did you already mention what type/make/model of device is involved, and which Device Driver you have selected for it (under Devices > device > detail page)?

I used to have those. Not sure if it's a driver or device issue but those do no report physical/digital correctly.

The bottom line is that physical vs. digital is often not very reliable. You must know how each device behaves. Can things be made better? Maybe, sometimes. But not always. The Lutron example is a good one. Hubitat guesses, but it can't know for sure as there is no such designation on the Telnet feed. If my Control4 system does something Hubitat logs a physical.

I looked around in the view for this device but couldn’t find which driver is in use.

Do these screenshots show it? Is the driver called “Leviton DZ6HD Z-Wave Dimmer”?

Please read this thread:

2 Likes

Correct. If that were a custom / 3rd party / community driver, then you could read its source code under UI > Drivers Code to see how it is dispensing event data. Unfortunately (for you), the built-in drivers are not Open Source and therefore unavailable for review in the same way.

Thanks!

It looks like this thread ends a couple years ago with @dennypage mentioning that there is a bug in the driver causing the device to report physical events.

What’s a good way to ask Hubitat for this official driver to be fixed?

1 Like

You can submit it as a feature request. Or tag @support_team (which I've done). In the meanwhile, does the generic driver work (as @dennypage indicated)?

1 Like
4 Likes

Thanks!

I’ll try changing drivers to see what the results are.

That helps! Thank you.

Is it known why the logs don’t show each of the two state requests?

Sorry, I don’t understand the question

The two state requests were mentioned in your reference:

Attached is a screenshot of logs for a device using the driver with the bug but it looks like there are no first responses marked as digital; just the second responses marked as physical:

1 Like

This happens alot with my devices. In some cases a driver fix can help parse the responses correctly, assuming the device has unique messages for physical vs. digital. It should be possible for the hub to know if the hub itself sent the command or was from an external source, but it might be too much work..I have no idea

1 Like

I've got several Leviton DZ6HD dimmers. I've found that changing the driver doesn't fix the [physical] or [digital] reporting.

1 Like

To really answer your question about what is logged as a state change, I would have to look at the source for the driver. I do not have access to the source. My knowledge comes from sniffing the Z-wave packets between the hub and device and from prior discussion about the bug with one of the driver developers.

2 Likes

If memory serves, the first one is not logged because the flag incorrectly says it is in response to a digital request, which should already have been logged. When the second hail comes, the flag is clear so it is logged as a physical event.

1 Like

For me, using the Generic Z-Wave Smart Dimmer driver instead of the DZ6HD driver seems to work. Are you on the latest firmware for the switches? Firmware below 1.2 could be problematic, if i remember correctly.

1 Like

Yes, definitely advisable to Update to latest firmware. 1.22 fixed a rare lockup that happened during physical operation which required an air gap pull to reset. Latest firmware (that I know of) is here.

2 Likes