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