Sometimes they will sometimes they won't.
After the rash of failures I've seen, honestly I didn't want them to replace them. Would rather move on to something that doesn't have such a colossal failure mechanism.
2 Likes
Same here. Every single one died quite suddenly, and all within a few months of each other. They were destined to fail or designed to fail, not sure which.
I think they had to be within a certain age (5 years?).
When ZWave is working, all the Jasco switches are working both by Zwave and by the switch.
I'm seeing no spamming in the logs either way. These switches are about a year old, and I do not think they are the source of my issues as I had them 6 months with the C7, then several months on the original C8 with no Zwave issues. Only had Zwave issues after moving to the warranty hub.
I would agree, that doesn't sound like the issue I am talking about on the older 14xxx models. If you bought yours that recently that wouldn't even be the 14xxx models anyway.
So different issue - sorry to derail things.
1 Like
No problem, good feedback, it was just a theory I had that seemed to fit but I did not know all the details. So that theory probably debunked. No we just wait and see what happens with the replacement hub.
1 Like
I had a similar issue (perhaps) at a client site.
The issue was that a critical repeater (which was close to the Hub had failed.
I found out about that device, by using the Hubitat Zwave Mesh Details app from Tony:
- Install the Z-wave mesh tool [BETA] A Z-Wave Mesh Tool [C7 and 2.2.4+ Only] from Hubitat Package Manager and use the Mesh tool to identify the neighbor nodes that the ghost devices are hanging onto. Use the
expand arrow in to expand the ghost device row in the Mesh Details app to see the device's neighbors. See the "Neighbors" column in the example screen cap below:
(that was from @danabw )
I installed the app. Lots of good info, but I'm not sure what I am looking for to really tell me anything.
I have some unknown LWR RSSI entries. Some TRR StdDev greater than a second. The ghosts devices I removed earlier are not showing, they had no names.
ZWave has only failed once since last reboot. I reset it last night using the Region update again, and it has been working since. I seem to at least be back to the old failure rate of 1-2 days, unless it just keeps working now.
Does it take some time to work ghost devices out of the system?
Edit: Huh, ZWave is down after using the app. Region update got it working again. I should note, I still have not seen a ZWave crash, I have been watching for that event in Webcore for a week now. Zwave simply stops working/responding, and no errors I can find anywhere.
When Zwave is not working, it still makes logs, but the entries are missing this info when down:
rssi: [-83 dBm, N/A, N/A, N/A, N/A], Ack channel: 0, Transmit channel: 0
Log entry when down:
dev:4842024-07-24 03:43:25.851 PMinfoseqNo: 185, routeChanged: false, transmissionTime: 1ms, repeaters: None, speed: 100 kbs
vs. working log:
dev:4842024-07-24 03:39:21.039 PMinfoseqNo: 176, routeChanged: false, transmissionTime: 1ms, repeaters: None, speed: 100 kbs, rssi: [-83 dBm, N/A, N/A, N/A, N/A], Ack channel: 0, Transmit channel: 0
- Look closely at the results of the Zwave Mesh Tool. If you see a line (a device) with a large number in the Route Changes column, (perhaps >100?) that is likely a problem device.
- Look closely at the lines that show an RTT Average >200. Find out why it's speed is ls slow.
- 90% of all devices show be connected "DIRECT". If not, and the device goes through many other devices, you have a problem.
1 Like
I have 2 zwave devices in total. Used to have more but I really cba with this rain-dance.
Zigbee - no worries.
Sorry I can't contribute anything more helpful. Good luck.
No route changes over 100, I have one at twenty is highest.
I do have one device, a Fibaro multi sensor, at 47145 average. It is outside and furthest from the hub of all my ZWave devices. I have a 2nd Fibaro inside, and it is only showing 88. Not sure if this is from the distance to the outside sensor, or an actual problem. The sensor is working fine otherwise.
Note, this is a battery powered sensor, and not a repeater.
I only have three devices not DIRECT, so about 90%. The ones not direct are the devices furthest from the hub, so that makes sense.
Well, at least I tried to figure out what is wrong.
In terms of that one Fibaro multi sensor, perhaps unpairing it and repairing it may assist in getting it's signal to the Hub faster. I'm not sure that will make a difference.
Another possibility:
In the Settings -> Zwave Details page, first column (Node).
Do you have any devices that show "LR" ? (see the following for an example):
If so, then why don't you downgrade those devices, and see if the LR feature is causing you the problem? (To downgrade, I mean unpair, re-pair (without LR) ).
Nope, no LR showing. I did lose ZWave again this afternoon, and the Region update fixed it as usual. So looks like ZWave is still doing the usual stopping thing roughly every day as it has been. The other day while messing with stuff, it would not work more than five minutes for a spell there, so back to once a day down at least has made the hub usable until the replacement hub arrives.
I just checked tracking on the replacement hub, and it should arrive tomorrow. So I will be on my third C8 in six months. I don't know what the odds are I would get a hub with bad Zigbee, only to be replaced by a hub with bad Zwave, but that is looking like the case (if the new hub fixes ZWave like the last new hub fixed Zigbee).
From the picture you showed, you have connected the Zwave Plus device as S0? I seem to recall that S0 was the least desirable method for inlcusion as it causes some mesh issues (such as spamming, particularly for items that poll frequently, like for power or multisensors). Just curious as to whether you have tried changing that to "none" as has been recommended on similar posts, unless it is a barrier device. Then it would be preferred to use S2 where possible.
Just a thought 
1 Like
Good catch! Yeah, the only thing I would ever pair at "S0" is an older lock that had no other option (classic example = the Yale ZW2 module) -- in the particular case of a lock, S0 is fine.
But I would otherwise avoid S0 like the plague.
Did the replacement hub solve the problem?
Everything was good for over a week, so I thought it was the hub. Then ZWave was unresponsive again. Very frustrating. I reset every Zwave device in the house, and it came back up, but then same issue again about two weeks later. I then power-cycled the hub, leaving it off for for a bit, and everything came back with no other intervention. It has been running since (for about a week now).
The issue is much less pervasive than it was, but there is still an issue, apparently. I still don't see any spamming in the logs though. Since everything was good until the hub was migrated from the first C8 to the replacement C8 for the Zigbee issues (that hub DID fix that issue), I have to assume something happened in that migration, that continued to the migration to the latest hub, though it is now better than it was. I just wonder if the root cause was the ZWave migration between the C8 hub it was working fine on, and the C8 hub that started having issues.
I'm now thinking that maybe I should exclude every ZWave device and re-add them one at a time, building the network again from scratch. That would be a lot of work though, as I also have to update the devices used in apps.
I am also thinking I should just buy a new switch, and start switching them out one at a time. I guess just change a switch and wait a week or two to see if the issue is gone, and if not, move it to another switch. This could take months, but I do not know any other way to find a "bad" device that is not causing anything in the logs.
Do I really have a bad device, or just a bad mesh from the migrations of all the ZWave data? Why is the issue so much better with the new hub compared to the old, but it is still there?
Right now I am just waiting to see if it go down again. The hub had not been power-cycled since the migration to the new hub until last week, so right now I am just waiting for the issue to reappear before taking further action, in case the power cycle fixed it? I have my doubts.
It just gets me that all the same ZWave devices that were working fine before a migration, start having issues after a migration. Seems if it is not the new hub, then maybe it is the migration itself that started the issue. Why did I have no issues until the first C8 to C8 migration? Zwave was fine after my C7 to C8 migration, only had issues after the C8 to C8 migration to a warranty hub.
Yeah definitely frustrating.
I am running all of my zigbee devices on a C7 that only acts as a radio. I did this because when I first migrated to the C8 the zigbee radio was going down constantly. There were a lot of posts at the time - so I just left all of my zigbee devices on the C7 and did everything else on the C8.
When I got my C8 pro I did a similar thing - left all of the zwave devices on the C8 and moved all rule processing and most apps to the C8 pro. This was some time ago when the C8 Pro's shipped.
But recently my C8 started causing issues. My z-wave network becomes unresponsive about every week or so. No errors anywhere that I can see or understand. Rebooting the hub does solve the problem for me.
So I added a routine to reboot the hub once a week. It wasn't enough. So I moved it to once a day. And then the other day the network became unresponsive in the same day after a reboot. Hopefully an anomaly but it shows that it can happen.
I haven't added anything new from the z-wave side in a long time. I am in the process of consolidating on Lutron as it is just rock solid.
I am working through this post going through the various suggestions to see if anything helps.
Mine started having issues with the zwave going unresponsive every day. I used a zniffer to see the hub was spewing out garbage transmissions in response to devices, instead of the proper acks. I eventually tried swapping it to a different power supply block and that seems to have fixed it 
. The old one I had it on must have started having voltage fluctuations. I dont have one of those fancy USB voltage testers to test the supply.
2 Likes
So I did see a lot of ghost devices when I looked. I followed the instructions to remove. I was able to knock out about half of them but there are still 6 that will not remove. Every time I try I get the message "Z-Wave Network responded with Busy message." usually followed by "Failed node XX remove status: no reply" or "Failed node 86 remove status: 0 SDK failure node is no longer in failed node list".
So I continued through the instructions and apparently I have to look at devices around these to see if the ghost is next to the actual device. Here is an example:
So if understand this I have to go to the device - in this case the "Garage Light Between Doors" - disconnect it and then try to remove the ghost? Am I trying this because the Garage Light Between Doors is next to or close to the ghost and is the same device class?
Assuming this is the case - it seems very trial and error and it's a major PIA. Is there another way to get rid of these.
I did also try the Mesh Tool and I get a ton of neighbors. So not sure what to do at this point? Open to suggestions. Thanks.
IMO That is a myth and wont get you anywhere. Has never been proven to work.
Yes, a UZB stick as a secondary controller. It is the main topic of the guide you were probably using.
It is all the neighbors stuck in there that is hanging it up from the z-wave chip removing it.
