C8 Pro running Zwave JS. Tried with debug and just tried with the "device" driver, it never shows anything from the double tap in the logs. It registers single on/off taps as well as hold to dim up/down.
I think at this point I need to swap in a different one of my GE dimmers and see if it behaves the same or if there is possibly something wrong with this one.
Agreed.
If still having an issue open the Zwave logs from the zwave details page. Capture some logs from the double tap event. It is a constant log while open with no filters so try to refresh the page right before doing the double tap then copy or download the log file before a bunch of other junk shows up. It will possibly just look like a bunch of gibberish but I can make sense out of it. Post as TEXT here (in formatted code blocks).
2026-01-05 04:08:46.658 PMDRIVER « [Node 012] [REQ] [BridgeApplicationCommand] - │ RSSI: -78 dBm - └─[MultilevelSwitchCCReport] - current value: 0
2026-01-05 04:08:46.656 PMCNTRLR [Node 012] [~] [Multilevel Switch] currentValue: 59 => 0 [Endpoint 0]
2026-01-05 04:08:46.653 PMSERIAL » [ACK] (0x06)
2026-01-05 04:08:46.650 PMSERIAL « 0x011100a8000001000c0326030000b2007f7fdf (19 bytes)
2026-01-05 04:08:44.946 PMSERIAL » [ACK] (0x06)
2026-01-05 04:08:44.943 PMSERIAL « 0x0118004984000c110411015e5686725a8559732627702c2b7a26 (26 bytes)
2026-01-05 04:08:44.198 PMSERIAL » [ACK] (0x06)
2026-01-05 04:08:44.195 PMSERIAL « 0x0107013b9ba0a0a1f8 (9 bytes)
2026-01-05 04:08:44.193 PMSERIAL « [ACK] (0x06)
2026-01-05 04:08:44.188 PMSERIAL » 0x0103003bc7 (5 bytes)
2026-01-05 04:08:44.185 PMDRIVER one or more queues busy
2026-01-05 04:08:43.871 PMDRIVER « [Node 012] [REQ] [BridgeApplicationCommand] - │ RSSI: -77 dBm - └─[MultilevelSwitchCCReport] - current value: 59
2026-01-05 04:08:43.868 PMCNTRLR [Node 012] [~] [Multilevel Switch] currentValue: 59 => 59 [Endpoint 0]
2026-01-05 04:08:43.866 PMSERIAL » [ACK] (0x06)
2026-01-05 04:08:43.864 PMSERIAL « 0x011100a8000001000c0326033b00b3007f7fe5 (19 bytes)
2026-01-05 04:08:42.366 PMCNTRLR [Node 012] [!] [Basic] event: 255 [Endpoint 0]
2026-01-05 04:08:42.365 PMCNTRLR [Node 012] treating BasicCC::Set as a value event
2026-01-05 04:08:42.362 PMDRIVER « [Node 012] [REQ] [BridgeApplicationCommand] - │ RSSI: -79 dBm - └─[CRC16CCCommandEncapsulation] - └─[BasicCCSet] - target value: 255
2026-01-05 04:08:42.360 PMSERIAL » [ACK] (0x06)
2026-01-05 04:08:42.357 PMSERIAL « 0x011500a8000001000c0756012001fff4ca00b1007f7f4e (23 bytes)
2026-01-05 04:08:41.218 PMCNTRLR [Node 012] treating BasicCC::Set as a value event
2026-01-05 04:08:41.215 PMDRIVER « [Node 012] [REQ] [BridgeApplicationCommand] - │ RSSI: -78 dBm - └─[CRC16CCCommandEncapsulation] - └─[BasicCCSet] - target value: 0
2026-01-05 04:08:41.211 PMSERIAL « 0x011500a8000001000c075601200100ea3a00b2007f7f5c (23 bytes)```Two double taps and a two single taps. If I am interpreting this correctly, this is a problem with the dimmer? It's not sending the right commands?
Looks like the device is not sending any "central scene" events to the hub, which is what gets used for button presses. I even searched the hex for 5B03 which would be the start a central scene notification.
I check everywhere I could find and the ZW3005 does not appear to have a parameter that disables/enables scene control actions.
What's crazy is I had every single one of these dimmers setup with double tap working so I'm not understanding what's going on. They are all the same model so once I get a chance to install another one next week I'll have to see if it behaves any different.
FWIW, what I get in regular logs and Z-Wave logs when I do a double-tap on one of my GE/JASCO dimers...not necessarily the same model as yours:
Any chance you've wired it up in a different than expected way? Is this wired to be part of a 3-way, or just a single switch?
Just throwing out whatever comes into my mind w/out filtering at this point... 
It is wired up as a 3 way with an accessory switch it was only wired up as a stand alone before
I have one of my GE dimmers set up as a 3-way...I'll give that a shot. I've never used double-tap on that switch...
Looks like it is sending the "central scene" events to the hub, so not an issue w/the switch setup as part of 3-way. Ruled out as a general issue, anyway.
Below is (starting from the bottom):
I swapped in a different GE switch with a different date code and got the exact same results. I am stumped since it was working.
Switch Z-wave to legacy ZIP.
There could be a bug in the current Zwave JS which is preventing the interview from picking up the central scene command class. The way Zwave JS works, is that if it does not "discover" a certain class and then messages do come in, they just get dropped before it even hits the logs. I think it is highly likely that is what the problem is.
There is a special endpoint (run against the hub IP in a browser) to use to force a re-interview with Zwave JS as well which you could try. I have these below in my notes, I forget what the node state shows exactly.
Force a re-interview, endpoint ## below is the decimal node number.
/hub/zwave2/reinterview?node=##
Get node state JSON data?
/hub/zwave2/getNodeState?node=##
I pulled the switch and put one of the new Zooz dimmers I had. If I end up using it elsewhere I will give it a try.
Two of mine quit working when I switched to Z-Wave JS. I have an older GE Fan Controller & GE Switch (Both Z-Wave Plus, but older than some of my other GE switches and dimmers). They should be model numbers (Switch: 14291) (Fan: 14287). These two devices stopped sending double taps. My newer ones, still work with the double taps. So it is the specific combo between the older switch, dimmer, or fan control and ZWave JS. Haven't switched back to legacy, since it seemed for things to take a couple days to settle when switching from legacy the first time. Didn't feel like having things wonky for a couple days again.
I was hoping for a fix with a HE update, as I checked firmware versions for my switches, which are all up to date. Not sure if a HE update would fix though.
I may play around with the re-interview thing when I have time, and see if that helps.
When you switch the gateway the database from ZIP is preserved, so if you switch back everything should work just as it was before. Same as if you switch back to ZIP and then back to Zwave JS again later. Only newly added devices would need to settle in when you switch.
Did you try the re-intrview?
The device is probably not following the zwave spec correctly in some way around the centralscene command class or Zwave JS would be picking it up. I would say it is highly unlikely you will see a fix unless the core Zwave JS gets patched to make it work with those devices, and then Hubitat updates to the new version.
@bcopeland knows about this issue, but it didn’t sound like an easy fix. Apparently the way these switches send double tap is a bit odd. Probably why it only works with the Botched drivers and Zip gateway.
This is what Bryan told me:
Another case of Zwave JS trying to be helpful but actually its not...
Just had some time to try it, still no luck. Looks like the reinterview process worked, got the DONE status in the browser. When loading the Node State, it showed interviewStage as complete.
For reference:
For my fan controller I am using the GE Smart Fan Control driver, from Hubitat
For my light switch I am using this driver: https://raw.githubusercontent.com/Botched1/Hubitat/master/Drivers/GE-Jasco%20Z-Wave%20Plus%20Switch/GE-Jasco%20Z-Wave%20Plus%20Switch.groovy
I believe those were the drivers I was using when it was working, but I'm not 100% sure since I have changed them around a little bit to see if that would help.
I can't even get the double tap feature from the Hubitat Commands page to register in the Current States view. Not a big deal though, We've gotten accustomed to not having them at this point for these two switches, and the main use for them (blind control in bedroom) I have just fully automated, so its even more reliable. If I really need to adjust the blinds manually during the day, then I just whip out my phone to adjust them.
Think I am going to stick on Z-Wave JS for now, as it has been incredibly reliable around the house. Maybe one day there will be a fix for it, but I'm not too worried about it overall.
Would be nice if we could get a device firmware update that fixes the reporting issues, but I'm guessing GE has probably given up development on these devices already
Download the Hubitat app
