Issues after Upgrade to 2.4.2.134 (ZWaveJS Issue, Legacy Works)

Spo I have a c8 pro and 2 days ago I tested my devices including my Utilitech Z-Wave Water Sensor and it worked. Now today I upgraded to 2.4.2.134 (from 2.4.2.129) and added another Utilitech Z-Wave Water Sensor that I had and it does not report wet always dry, so I tested my other one and it also now does not report wet. so the update killed the driver or something. everything else seems to work but not my Utilitech Z-Wave Water Sensor, I have 4 of them and have tried adding in the other 2 and also no reporting. so 4 now do not work.

thought on how to fix? (no ghost devices, and 5 feet from hub when pairing)

I have also tried the community "Utilitech Water Sensor driver" with no luck

Roll back to 2.4.2.134 and verify that both devices work once again.

1 Like

Ok I just tried and reverted back to platform 2.4.2.129 and restored the database to 2.4.2.129 afterwards and no go. Seems odd it kicked the bucket after that but I gues stranger things have happened and all 4 dont pair, but any other zwave does and works. so who knows.

Im back to 2.4.2.134 and restored my most reced backup fromthe version just befor I reverted back.

Thanks for trying. Forgot I could roll back the platform version.

maybe you can help me still. So I have a device on my z-wave that is a ghost device and seems to be active. I have accounted for every device on my network and I can trace it to anything, but seems to be active. I have unpaired all and its still there, I have repaired and its still there (That was alot of work) how can I force remove this device.

I have tried refresh several times and I never get the delete option:

I have tried rebuilding the z-wave several time, and rebooting sever times and again refreshing the device, but nothing makes it go away. Nothing is making it go away. how can I force remove it, as that might be the issue getting my utilitech leak sensors working as they report in with battery but not wet or dry anymore.

this is the only thing I can see that would cause the issue.

Here's the community's most comprehensive information on dealing with ghosts...

1 Like

@csteele Please read this: I have found the issue and verified it is an issue with ZWaveJS for my Utilitech Z-Wave Water Sensor Issue

So that is something new I was unaware of.

" Since release 2.4.5.151 in April of 2025 Hubitat has made ZWaveJS (an open-source Z-Wave library) available as an optional Z-Wave library. One of the benefits of ZWaveJS is more effective removal of Z-Wave ghosts via the hub's built-in Z-Wave removal tools.

On the C8-Pro you can switch from ZipGateway (the original/default Z-Wave library on HE hubs) to ZWaveJS via a button on the Z-Wave Details page. On C8 and earlier hubs running ZWaveJS on an ongoing basis isn't recommended (ZWaveJS has memory requirements that those hubs don't reliably support), but temporarily switching to ZWaveJS to remove a stubborn ghost and then switching back to ZipGateway is supported."

Looks like using ZWaveJS breaks my Utilitech Z-Wave Water Sensors, As I switched back to legacy to also try removal from there also and figured I would test the Utilitech Z-Wave Water Sensor again, and it just works now.

And relized it must have switched over to ZQaveJS after I did the update as I had migrated from a C* earlier this month and not on the Pro and the platform update must have triggered it on. And would explain why it work a few days before the Upgrade.

I have verified that switching back to ZWaveJS breakes the z-wave device again and going back to legacy it works again.

So something in the new ZWaveJS (open-source Z-Wave library) breaks them. (Others seem to be ok.

1 Like

There are still bugs in JS, I'm not surprised that you found a device that doesn't work with JS. I don't recall seeing this device mentioned in Beta where a lot of these bugs have been reported, but I may have missed it.

I am not certain what the status of fixing these bugs are. Tagging @bcopeland so he may add this to his list of things to check.

2 Likes

Zwave Legacy has a lot more hours on it.. probably why we use "legacy" :smiley:

ZWaveJS is however, the future. It needs to be poked and prodded into being better than anything before. Reports like this, in which a logical (which usually means repeatable) discovery is made, will provide feedback to Hubitat's staff.

Although Hubitat is really quick at getting fixes out, it is not instantaneous. It may be that YOU want to stay on Legacy for a few weeks longer.. carefully reading release notes for a fix for your devices.

5 Likes

I did report it to the zWave Gethub (once I found it) and reported it (Hopefully gave them the info needed) All my other ones work, so I should be ok for a while, I will put a different leak sensor in its place, just harder to access to change batteries, but I can like with that for a while, and will keep an eye out. Also reported the Glass Break version is also not working.

Thanks for getting back to me. Otherwise I am loving the new C8-Pro, so much more responsive. :slight_smile:

Z-Wave JS is a popular Z-Wave "driver" (their terms, not the same on Hubitat). It is not developed by Hubitat. They Z-Wave JS devs cannot address any specific platform's use of their code. Are you sure this is a Z-Wave JS issue and not something related to just how Hubitat is using it? Providing whatever that information was here is likely to be more effective.

2 Likes

It was missing from their list of compatible devices is why I reported it there, and did see online that Home Assist users have reported the same issue. So now both hubitat and zWaveJS people have the info

Hubitat doesn't really need Z-Wave JS to list "compatibility" with a device for it to work; Hubitat does a lot of the work itself that some other platforms rely on Z-Wave JS itself to handle. As long as it passes commands to the hub, that's generally enough.

In your discussion there, I don't see any Z-Wave JS logs (rule #1 under the troubleshooting step you checked in the checklist), so I suspect they won't have enough evidence to think it's a Z-Wave JS issue. Often this kind of thing is in some sense, but with devices so far, it's often just that they choose to pass on only certain command classes and it happens to be one the Hubitat driver isn't looking for. Z-Wave JS logs (Settings > Z-Wave Details > Z-Wave Logs on Hubitat) or driver logs for unhanded Z-Wave reports (I see you're using custom code, so you'll need to log and catch the base Command as well as anything else you're actually handling) during a wet/dry event would be the easiest way for you to tell. Alternatively, staff may need to enable and pull more detailed logs from your hub if there are no clues in either of these logs.

Them adding formal "compatibility" might help, but typically staff have had to modify Z-Wave JS slightly for Hubitat to work around issues like this in the past (on Hubitat, the driver generally expects unfiltered reports; Z-Wave JS is sometimes more opinionated).

Anyway, don't be surprised if they ask for more information or if "compatibility" doesn't change anything. :smiley:

5 Likes

Sorry health issues. But here is my zwave log after adding the device and getting wet to trigger. is this what they are looking for?

2025-08-02 02:15:46.366 PM|CNTRLR   [Node 171] [~] [Alarm Sensor] severity[5]: undefined => undefined [Endpoint 0]
2025-08-02 02:15:46.361 PM|CNTRLR   [Node 171] [~] [Alarm Sensor] state[5]: true => false             [Endpoint 0]
2025-08-02 02:15:46.360 PM|SERIAL » [ACK]                                                                   (0x06)
2025-08-02 02:15:46.358 PM|SERIAL « 0x011500a800000100ab079c02000500000000af007f7fdb                    (23 bytes)
2025-08-02 02:15:43.511 PM|DRIVER   all queues idle
2025-08-02 02:15:43.509 PM|DRIVER « [RES] [GetBackgroundRSSI] -                                     channel 0: -106 dBm -                                     channel 1: -105 dBm -                                     channel 2: -105 dBm -                                     channel 3: -101 dBm
2025-08-02 02:15:43.505 PM|SERIAL » [ACK]                                                                   (0x06)
2025-08-02 02:15:43.500 PM|SERIAL « 0x0107013b9697979bcf                                                 (9 bytes)
2025-08-02 02:15:43.498 PM|SERIAL « [ACK]                                                                   (0x06)
2025-08-02 02:15:43.488 PM|DRIVER » [REQ] [GetBackgroundRSSI]
2025-08-02 02:15:43.483 PM|SERIAL » 0x0103003bc7                                                         (5 bytes)
2025-08-02 02:15:43.480 PM|DRIVER   one or more queues busy
2025-08-02 02:15:43.109 PM|DRIVER « [Node 171] [REQ] [BridgeApplicationCommand] -                                   │ RSSI: -81 dBm -                                   └─[AlarmSensorCCReport] -                                       sensor type: Water Leak -                                       alarm state: true
2025-08-02 02:15:43.107 PM|CNTRLR   [Node 171] [~] [Alarm Sensor] duration[5]: undefined => undefined [Endpoint 0]
2025-08-02 02:15:43.103 PM|CNTRLR   [Node 171] [~] [Alarm Sensor] severity[5]: undefined => undefined [Endpoint 0]
2025-08-02 02:15:43.100 PM|CNTRLR   [Node 171] [~] [Alarm Sensor] state[5]: false => true             [Endpoint 0]
2025-08-02 02:15:43.098 PM|SERIAL » [ACK]                                                                   (0x06)
2025-08-02 02:15:43.095 PM|SERIAL « 0x011500a800000100ab079c020005ff000000af007f7f24                    (23 bytes)
2025-08-02 02:15:38.478 PM|DRIVER   all queues idle
2025-08-02 02:15:38.475 PM|CNTRLR   [Node 171] The node is now asleep.
2025-08-02 02:15:38.472 PM|DRIVER « [RES] [SendDataBridge] -                                     was sent: true
2025-08-02 02:15:38.471 PM|SERIAL « [ACK]                                                                   (0x06)
2025-08-02 02:15:38.468 PM|DRIVER » [Node 171] [REQ] [SendDataBridge] -                                   │ source node id:   1 -                                   │ transmit options: 0x24 -                                   │ callback id:      0 -                                   └─[WakeUpCCNoMoreInformation]
2025-08-02 02:15:38.457 PM|DRIVER   one or more queues busy
2025-08-02 02:15:38.454 PM|CNTRLR » [Node 171] Sending node back to sleep...

They'd be in a better position to tell you there for Z-Wave JS, but for Hubitat, that looks good. Does anything make it to the driver if you have debug logging enabled, and what driver are you using?

so i use the "Generic zwave water sensor" and on the legacy one it works, but on the zwave js nothign shows up in the normal log.

I got more from my zwave log after triggering the wet and tamper. Note this is node 171. (also is this the best place to post this, or should I create a new thread?

Hubitat
Dev

Res
Home C8-Pro
1
2025-08-02 08:29:58.655 PMDRIVER all queues idle
2025-08-02 08:29:58.653 PMDRIVER « [RES] [GetBackgroundRSSI] - channel 0: -105 dBm - channel 1: -106 dBm - channel 2: -106 dBm - channel 3: -100 dBm
2025-08-02 08:29:58.651 PMSERIAL » [ACK] (0x06)
2025-08-02 08:29:58.649 PMSERIAL « 0x0107013b9796969cc9 (9 bytes)
2025-08-02 08:29:58.647 PMSERIAL « [ACK] (0x06)
2025-08-02 08:29:58.644 PMSERIAL » 0x0103003bc7 (5 bytes)
2025-08-02 08:29:58.641 PMDRIVER one or more queues busy
2025-08-02 08:29:28.653 PMDRIVER all queues idle
2025-08-02 08:29:28.650 PMDRIVER « [RES] [GetBackgroundRSSI] - channel 0: -105 dBm - channel 1: -105 dBm - channel 2: -105 dBm - channel 3: -100 dBm
2025-08-02 08:29:28.648 PMSERIAL « 0x0107013b9797979cc9 (9 bytes)
2025-08-02 08:29:28.647 PMSERIAL « [ACK] (0x06)
2025-08-02 08:29:28.645 PMDRIVER » [REQ] [GetBackgroundRSSI]
2025-08-02 08:29:28.642 PMSERIAL » 0x0103003bc7 (5 bytes)
2025-08-02 08:29:28.640 PMDRIVER one or more queues busy
2025-08-02 08:28:58.654 PMDRIVER all queues idle
2025-08-02 08:28:58.651 PMDRIVER « [RES] [GetBackgroundRSSI] - channel 0: -106 dBm - channel 1: -105 dBm - channel 2: -105 dBm - channel 3: -102 dBm
2025-08-02 08:28:58.649 PMSERIAL » [ACK] (0x06)
2025-08-02 08:28:58.647 PMSERIAL « 0x0107013b9697979ace (9 bytes)
2025-08-02 08:28:58.644 PMSERIAL « [ACK] (0x06)
2025-08-02 08:28:58.641 PMSERIAL » 0x0103003bc7 (5 bytes)
2025-08-02 08:28:58.639 PMDRIVER one or more queues busy
2025-08-02 08:28:53.635 PMDRIVER all queues idle
2025-08-02 08:28:53.621 PMCNTRLR [Node 171] The node is now asleep.
2025-08-02 08:28:53.619 PMCNTRLR [Node 171] The node did not respond after 3 attempts. It is probably asleep, m - oving its messages to the wakeup queue.
2025-08-02 08:28:53.616 PMDRIVER « [REQ] [SendDataBridge] - callback id: 207 - transmit status: NoAck, took 5460 ms - routing attempts: 14 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: Resort to Direct - TX channel no.: 1 - route failed here: 63 -> 171
2025-08-02 08:28:53.613 PMSERIAL » [ACK] (0x06)
2025-08-02 08:28:53.612 PMSERIAL « 0x011d00a9cf010222007f7f7f7f7f00010600000000020e3fab7f7f7f7f7f3a (31 bytes)
2025-08-02 08:28:48.126 PMDRIVER « [RES] [SendDataBridge] - was sent: true
2025-08-02 08:28:48.124 PMSERIAL » [ACK] (0x06)
2025-08-02 08:28:48.123 PMSERIAL « 0x010401a90152 (6 bytes)
2025-08-02 08:28:48.119 PMSERIAL « [ACK] (0x06)
2025-08-02 08:28:48.116 PMDRIVER » [Node 171] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 207 - └─[BatteryCCGet]
2025-08-02 08:28:48.115 PMSERIAL » 0x011000a9000100ab0280022500000000cf86 (18 bytes)
2025-08-02 08:28:48.111 PMDRIVER « [REQ] [SendDataBridge] - callback id: 207 - transmit status: NoAck, took 5780 ms - routing attempts: 17 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: Resort to Direct - TX channel no.: 1 - route failed here: 63 -> 171
2025-08-02 08:28:48.109 PMSERIAL « 0x011d00a9cf010242007f7f7f7f7f0001060000000002113fab7f7f7f7f7f45 (31 bytes)
2025-08-02 08:28:42.294 PMSERIAL » [ACK] (0x06)
2025-08-02 08:28:42.292 PMSERIAL « 0x010401a90152 (6 bytes)
2025-08-02 08:28:42.290 PMSERIAL « [ACK] (0x06)
2025-08-02 08:28:42.287 PMDRIVER » [Node 171] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 207 - └─[BatteryCCGet]
2025-08-02 08:28:42.284 PMSERIAL » 0x011000a9000100ab0280022500000000cf86 (18 bytes)
2025-08-02 08:28:42.280 PMDRIVER « [REQ] [SendDataBridge] - callback id: 207 - transmit status: NoAck, took 5610 ms - routing attempts: 17 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: Resort to Direct - TX channel no.: 1 - route failed here: 63 -> 171
2025-08-02 08:28:42.277 PMSERIAL « 0x011d00a9cf010231007f7f7f7f7f0001060000000002113fab7f7f7f7f7f36 (31 bytes)
2025-08-02 08:28:36.630 PMDRIVER « [RES] [SendDataBridge] - was sent: true
2025-08-02 08:28:36.628 PMSERIAL « 0x010401a90152 (6 bytes)
2025-08-02 08:28:36.626 PMSERIAL « [ACK] (0x06)
2025-08-02 08:28:36.622 PMSERIAL » 0x011000a9000100ab0280022500000000cf86 (18 bytes)
2025-08-02 08:28:36.617 PMCNTRLR [Node 171] Timed out while waiting for a response from the node (ZW0201)
2025-08-02 08:28:35.531 PMDRIVER « [REQ] [SendDataBridge] - callback id: 201 - transmit status: OK, took 60 ms - routing attempts: 2 - protocol & route speed: Z-Wave, 40 kbit/s - routing scheme: Direct - ACK RSSI: -83 dBm - ACK channel no.: 1 - TX channel no.: 1
2025-08-02 08:28:35.528 PMSERIAL « 0x011d00a9c900000600ad7f7f7f7f01010100000000020200007f7f7f7f7f57 (31 bytes)
2025-08-02 08:28:35.466 PMDRIVER « [RES] [SendDataBridge] - was sent: true
2025-08-02 08:28:35.462 PMSERIAL « 0x010401a90152 (6 bytes)
2025-08-02 08:28:35.461 PMSERIAL « [ACK] (0x06)
2025-08-02 08:28:35.458 PMCNTRLR » [Node 171] querying battery status...
2025-08-02 08:28:35.456 PMDRIVER » [Node 171] [REQ] [SendDataBridge] - │ source node id: 1 - │ transmit options: 0x25 - │ callback id: 201 - └─[NotificationCCGet] - V1 alarm type: 0
2025-08-02 08:28:35.454 PMSERIAL » 0x011100a9000100ab037104002500000000c977 (19 bytes)
2025-08-02 08:28:35.452 PMDRIVER one or more queues busy
2025-08-02 08:28:35.431 PMCNTRLR « [Node 171] Received updated node info
2025-08-02 08:28:35.429 PMDRIVER « [Node 171] [REQ] [ApplicationUpdateRequest] - payload: 0x00ab0c04a1028672858480709c2071
2025-08-02 08:28:35.428 PMSERIAL » [ACK] (0x06)
2025-08-02 08:28:35.426 PMSERIAL « 0x011300498400ab0c04a1028672858480709c2071e9 (21 bytes)
2025-08-02 08:28:29.437 PMDRIVER « [Node 171] [REQ] [BridgeApplicationCommand] - │ RSSI: -84 dBm - └─[AlarmSensorCCReport] - sensor type: Water Leak - alarm state: false
2025-08-02 08:28:29.436 PMCNTRLR [Node 171] [~] [Alarm Sensor] duration[5]: undefined => undefined [Endpoint 0]
2025-08-02 08:28:29.435 PMCNTRLR [Node 171] [~] [Alarm Sensor] severity[5]: undefined => undefined [Endpoint 0]
2025-08-02 08:28:29.430 PMCNTRLR [Node 171] [~] [Alarm Sensor] state[5]: false => false [Endpoint 0]
2025-08-02 08:28:29.428 PMSERIAL » [ACK] (0x06)
2025-08-02 08:28:29.427 PMSERIAL « 0x011500a800000100ab079c02000500000000ac007f7fd8 (23 bytes)
2025-08-02 08:28:29.356 PMDRIVER « [Node 171] [REQ] [BridgeApplicationCommand] - │ RSSI: -84 dBm - └─[AlarmSensorCCReport] - sensor type: Water Leak - alarm state: false
2025-08-02 08:28:29.355 PMCNTRLR [Node 171] [~] [Alarm Sensor] duration[5]: undefined => undefined [Endpoint 0]
2025-08-02 08:28:29.352 PMCNTRLR [Node 171] [~] [Alarm Sensor] severity[5]: undefined => undefined [Endpoint 0]
2025-08-02 08:28:29.351 PMCNTRLR [Node 171] [~] [Alarm Sensor] state[5]: true => false [Endpoint 0]
2025-08-02 08:28:29.348 PMSERIAL » [ACK] (0x06)
2025-08-02 08:28:29.345 PMSERIAL « 0x011500a800000100ab079c02000500000000ac007f7fd8 (23 bytes)
2025-08-02 08:28:28.566 PMCNTRLR [Node 171] [~] [Alarm Sensor] duration[5]: undefined => undefined [Endpoint 0]
2025-08-02 08:28:28.561 PMCNTRLR [Node 171] [~] [Alarm Sensor] state[5]: true => true [Endpoint 0]
2025-08-02 08:28:28.559 PMSERIAL » [ACK] (0x06)
2025-08-02 08:28:28.556 PMSERIAL « 0x011500a800000100ab079c020005ff000000ad007f7f26 (23 bytes)
2025-08-02 08:28:28.490 PMDRIVER « [Node 171] [REQ] [BridgeApplicationCommand] - │ RSSI: -83 dBm - └─[AlarmSensorCCReport] - sensor type: Water Leak - alarm state: true
2025-08-02 08:28:28.487 PMCNTRLR [Node 171] [~] [Alarm Sensor] duration[5]: undefined => undefined [Endpoint 0]
2025-08-02 08:28:28.481 PMCNTRLR [Node 171] [~] [Alarm Sensor] state[5]: false => true [Endpoint 0]
2025-08-02 08:28:28.479 PMSERIAL » [ACK] (0x06)
2025-08-02 08:28:28.476 PMSERIAL « 0x011500a800000100ab079c020005ff000000ad007f7f26 (23 bytes)

Is this still true with "Enable debug logging" enabled in the device/driver preferences? (Keep in mind it auto-disables after 30 minutes by default.)

I would keep everything here and not create a new topic.

Correct, But I just removed and re-added the device and this is all that shows up on the log with debug enabled: (even after triggering wet or tamper (Also node is now 172 since I removed and re-added)

dev:17252025-08-02 08:39:31.563 PMwarnconfigure...
dev:17252025-08-02 08:39:23.666 PMdebugParsed '{"cc":114,"cmd":5,"ep":0,"values":[{"request":{"args":[],"command":"endpoint.invoke_cc_api","commandClass":114,"endpoint":0,"messageId":"expected6704","methodName":"get","nodeId":172},"response":{"manufacturerId":96,"productId":1,"productType":11}}]}' to [[descriptionText:ST812 MSR: 0060-000B-0001, isStateChange:false]]
dev:17252025-08-02 08:39:23.665 PMdebugmsr: 0060-000B-0001
dev:17252025-08-02 08:39:23.580 PMwarnconfigure...
dev:17252025-08-02 08:39:23.535 PMinfoinstalled...

Good to know! Tagging @bcopeland on this one to see if there is some magic that can be done to make Z-Wave JS pass what it looks like shows up fine in your Z-Wave logs on to the driver for parsing (which doesn't seem to be happening).

3 Likes

thanks so much for your help, I have a friend and a family member that use these on the c8 pro so they would love to get these working on the new zwave js (its just so much better)