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?
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.
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.
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)?
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:
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
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.
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.
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.
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.