Is this happening with my user driver (linked at the top of this thread), or the in-box driver?
If mine, I'll take a look when I get home. If the in-box, then submit a support ticket to Hubitat.
With your user driver from this thread, and I've replicated the behavior on multiple switches. I just can't figure out why it only happens once, and what the "timeout" is. I.e. it happened last night, and again this morning, so I thought maybe it was after a mode change.
I changed the mode manually back to night and then to day, and couldn't replicate it, so it appears unrelated to mode change, and either due to a timeout or a new calendar day (if I'm guessing at this point)
Edit: I've turned on debug logging for a couple of the switches, so I might have more information tomorrow after it occurs next.
Ok. I'll take a look. I so rarely use physical presses, I'm not sure I would have seen this even if it is a driver issue. I'll post back.
I managed to capture the behavior with the debug code on. Unless there's some kind of time out that is resetting something, it could be when my mode manager changes the mode based on time of day (since it didn't work manually?).
Just speculating...but what I see here, it looks like the debug logs show the same command being sent, so I'm thinking this is a bug on Hubitat's side. Would you agree? I'll open up a thread in the support forum if I'm not missing something.
This is the same as earlier: physical on, physical off, physical on, and it reports the first as digital.
I think you need to make a slight adjustment to how you are reporting the switch events. When you call the command "ON", you immediately set the switch state to on-digital, which is correct. When you just get a report from the device without having the switch already in that state, you can assume that the change was physical. Since it appears there is no report confirmation when the switch is set to on by the hub, the state.bin variable is not being reset to 0. So, the first physical change comes up as digital. Changing the two references to change type from newType to physical for the switch commands made everything report correctly for me. The newType is still applicable to level change commands and that seems to work and report correctly. I can do a pull request to show you the two changes if I've completely confused you.
It's strange but it seems that there is no z-wave report back for the digital switch change and there is for the digital level change.
Yeah... That is odd. I don't remember it working that way in past Hubitat releases... Weird. It is almost like it is grabbing the basic report and trashing it. Unless the device isn't actually sending it, but I thought it did...
Maybe it has always been that way though? I would have thought I, or someone else, would have noticed it before though.
[EDIT: See 2 posts below for the reason why it doesn't send a basic report on ON/OFF]
@mike.maxwell Did anything change on zwave basic report parsing in 2.1.5? I assume no, but have to ask.
nope...
Yeah, looks like I broke it in my 8/28 driver update. The issue is that different GE/Jasco firmware act differently.
Some device firmware versoins turn the device off with a setlevel=0 and some don't. So I changed ON/OFF code and reporting to work with the new firmware and broke the physical/digital reporting for everyone. I'll get it fixed.
The device doesn't do basic on/off reports, as it uses those for DoubleTap the way I have the associations setup. The device can do basic reports for ON/OFF, but then it makes DoubleTap event reporting goofy.
I uploaded v2.2 to github. I think it should fix the issue.
Sorry about that. 
2 Likes
I also noticed that repeated double taps are no longer working with any of the drivers that supported it previously. Nothing shows up in debug logs either. It's like anything after the first double tap is also being ignored.
I'll take a look at that too. I definitely don't remember seeing that in testing, and I did test multiple doubletaps - but maybe I did doubletap up then doubletap down each time instead of two up or two down in my testing?
If the device isn't sending the report, probably not much that can be done on that. But I'll look!
Don't have an answer on that one.
On my devices repeated doubletaps are making events as expected. Just did 5 doubletap up in a row, all showed up.
Awesome! Is it expected behavior to encounter the error one last time? I updated the driver on Hubitat (and even rebooted), but my first on was still digital at the 5 switches I tried (3 before and 2 after rebooting...I try to be thorough 
)
For a sanity check, I just checked my double tap ups and had no issues with sending multiple in a row.
It wouldn't surprise me if you got the reporting discrepancy one more time until you toggle it again. If you keep getting it after that though, let me know
Your driver isn't even catching all the z-wave messages. It doesn't catch on events from my dimmer. Forget about reporting physical vs digital. It's doesn't report anything. We had a problem like this before. Is it possible there are two "flavors" of firmware out there for this device? I definitely have the Z-wave plus model (I found the box).
There are MANY versions of the firmware out there. You can look in basic zwave tool and see what version you have. For instance, the one I do most of my testing on is an old one:
dev:772019-10-17 07:59:27.005 pm infoVersionReport- applicationVersion:5.26
dev:772019-10-17 07:59:27.003 pm infoVersionReport- zWaveProtocolVersion:4.34
Is it reporting ANYTHING in the logs (with debug turned on)? If not, that probably isn't a driver issue, as the driver should report something on every message it receives when debug is ON - even if it is a command it doesn't support - that's how I troubleshoot the code when I'm developing it.
I'm on the same version.
No, I'm not seeing anything in the logs for the missing commands. No raw messages or anything. That's the oddest part. Did you comment out any of the "dumps" before releasing it? I haven't looked to add any extra logging yet.
The easiest way to troubleshoot is to put logging on the parse section. Every message that comes in, supported or not, goes through parse.
I don't have the code in front of me, but I believe I do log that on debug. If I'm remembering right, then no message=nothing received by the hub from the device.
Edit: I checked:
if (logEnable) log.debug "parse() >> zwave.parse($description)"
So with debug on, if you aren't seeing a parse() debug line when those events happen, then the device isn't sending them, or the hub isn't receiving them...
I added one extra logging step in parse to log the raw description at the top of the message, just in case something in the parse was affecting what was loggged (parse is still something that I am not as confident with, especially with z-wave messages) and it DEFINITELY is a device issue. Once the dimmer stops reporting double-taps, it also stops reporting any other physical events. This switch is in a place where I never turn it on physically (I have a motion sensor) and only use it to turn the lights off and the doubletap to adjust the room's speaker volume (the switch controls my bathroom lights). So, it appears that the dimmer has something going on that prevents the z-wave part of the device from sending messages after using the double-tap multiple times in a row. I can't image how that would happen and then how it would eventually recover all on it's own. The dimmer is right next to another z-wave plus device, a switch controlling my bathroom fan. So, my apologies for the implication that the driver was at fault. I never realized that a device could fail in this way. I figured if it was dead, it was dead. But it appears I have a Zombie switch. 
So, it looks like I'm in the market for a switch or dimmer that has the double-tap button press feature. Maybe one of the innovelli Red series switches. (And of course they're not on sale anymore....DOH!) Any other suggestions on dimmers or switches with central scene capability?
