I have a C7 with about 80 Leviton zwave dimmer switches and have seen unreliable behavior for months now. I’m at the end of my rope on troubleshooting and hoping somebody else can help. Throughout the house there are a number of switches that intermittently stop logging and responding In Hubitat (physically these switches behave fine).
If I wait 15 or 20 minutes, suddenly they start working fine and respond quickly. Several of these switches are within 10 feet of the C7 and have a direct connection to the C7 with no nodes in between .
I have one ghost node that refuses to die. It has no route and won’t remove. I’ve rebooted, powered off and waited, done repairs, done removals, and even followed the backup plus a soft reset and restore followed by a few days of waiting.
I’ve done a number of full repairs and have let it go for days to let the network straighten things out.
I realize that completely destroying my network and then rebuilding it is an option, but this becomes an entire weekend project at that point with no guarantee that it will resolve.
My zwave logs have never once had an entry in 6 months, so I’m not sure what to do with those and there seems to be no way of identifying a specific problem device.
At this point I’m on the verge of throwing my C7 in n the garbage and hiring a local teenager to turn the lights on when I shout… that might be more reliable.
Any suggestions on how to determine if maybe there is a single bad device causing the issue? Or alternatively suggestions on how to resolve this?
I'll give it a shot... Zooz UZB 700 ordered. Thanks.
Is there a reason why the Hubitat C7 itself can't just remove the node? The "Remove" button functionality in the Hubitat zwave list seems like it doesn't really work, so why does it exist?
We have all complained that "zwave gohst removal" should be possible with Hubitat.
Unfortunately, for technical reasons it isn't possible (apparently).
That's why many of us have a zwave stick (aeotec, and zooz are the common ones), and we use that PC Controller software to get rid of it.
It sucks, but that too is reality.
(I also put a lot of blame on slicone labs and their sdk, but that's another story).
P.S. I had one Zwave Plus Leviton dimmer, and found that there were issues with it.
Mkae sure that you are using the latest firmware on it.
Also, there are a few drivers floating around here for that device - perhaps you may have better success with another driver.
How do you do firmware updates? I have read posts from the Hubitat team saying there are built in firmware updates and if you push the "Firmware Update" button that they have support for most of the popular devices (but the list of what is supported for FW updates is not published), but Hubitat also does not reveal the current firmware version of a device anywhere... So how do we know if the update is done? Or is this something you do through the usb stick?
The first step in the zwave firmware update is to find out by looking at the device page what level of firmware you have now.
The second step is to contact leviton and find out if there are any new firmware updates, and ask them to send you the update file(s).
Then you will be ready to use the built in zwave firmware update tool. There should be documentation on how to use it here on the forum.
The following is a good background on this subject (even though it's about Zooz):
As mentioned, the reasons are not very satisfying but the major difference between the C-7's Replace and a secondary controller using PC Controller software from SiLabs is that they use two code sets. The C-7 with it's 700 series chip uses the 700 series communications method driving the 700 series commands on the radio chip.
PC Controller communicates using the 500 series communications method using 500 series commands... even to a 700 series USB stick. In other words, it's using the old style communications and commands to do the job and on occasion, those older commands are "more compatible" with certain devices and how they get themselves "stuck". PC Controller is much lower level, meaning you and I have to click more stuff, read and interpret the result, then based on the result, repeat or move onto the next step.
It's that "use it like a 500 series" ZWave radio that I think, (repeat, "I think") allows this method to overcome situations when the ghost is really stuck.
I use a 700 series USB stick with my instance of PC Controller to blast away ghosts on the rare occasion when I get them. (I am done with my automation journey, mostly and thus I'm not buying many devices, not adding many devices, not open for ghosts from that Inclusion process. )
You can either use a stick or the built in updater. Click APPS, then ADD BUILT IN APP and pick device firmware updater. That said you need to have the update file. Some are built in and will even have a firmware update button on the device page. (open a separate log window to watch what goes on). Others can be obtained from the device manufacturer by emailing their support.
I'll chime in and say, yes you're ghost needs gone.... Likely this is hampering your whole mesh. Can you also post a copy of your z-wave details page? We may be able to spot other issues.
Another think that can slow you down is security. It's recommended you leave it off except for locks and garage openers. The reason is overhead that encryption uses. This is especially problematic for things paired as S0. S0 encryption is quite chatty. There are some devices (zooz 4-in-1) that can bring down your mesh because they are so chatty. Power reporting is another issue. Defaults can be too chatty and flood your mesh. If you have devices that power report, check their settings.
Thank you all very much for the useful suggestions.
A few updates:
No change on the ghost. My USB Stick arrives tomorrow so that will be interesting to evaluate.
Updated all of my Leviton dimmers to Ernie's driver because the Hubitat system driver for those dimmers does not show the firmware version. Thankfully all of the dimmers are on 1.20 (latest).
One of my devices named Powder Bath Dimmer Switch (which is one of the problem devices) will not save the "Indicator when off" setting. Only this one device refuses, and physically when the switch is off, the indicator light does not turn on. I'm hopeful/suspicious that this may be a bad device since it is 10 feet from the Hubitat and has no nodes between, but is a frequent misbehavor.
Here is my full zwave list sorted by routes. I have a bunch of Fibraro Window Sensors v2, they have been reliable, but occasionally when viewing the zwave list, one or two of them won't have a route... but then inevitably they get a route back later. I'm not sure if that is normal behavior for these low power devices or maybe this is indicative of a problem (or maybe they are trying to repeat through a problem device?)
Well you have the ghost issue with the top 3 nodes it looks like but you also have a ton of S0 devices. I would include all those window sensors without S0. S0 generates roughly 3 times more traffic than including them with none.
How does one include them and specify the security? I usually go into the Devices->Add and do a zwave inclusion, but haven't seen any options or choices about the security mode.
The easiest way is to uncheck all the boxes if you get a popup when including them. Next would probably pair it with a USB stick and uncheck the security settings for S0 in the Z-Wave PC Controller software.
You've seen the opinion here that a couple of issues are Silicon Labs based. Hubitat is a ZWave Certified hub and the criteria for that is specifically (and only) a SiLabs certification. They are the ones that insist that certified hubs Include at some form of security and thus the older devices that are only capable of including as "S-None" or S0 are FORCED to be S0. Nobody but SiLabs wants that. As mentioned, S0 is 3x the number of packets over "S-None" and thus we're all forced to extraordinary lengths to be better than SiLabs.
Again, with your ZWave stick and PC Controller, you'll be able to fix this too.
Older devices that are NOT S2 capable are often only able to be S0 or none, "S-None" as I call it. Those devices are forced into S0. Newer devices that are S2 capable are able to join "S-None", S0, or one of the S2 options. Those need us to click "skip" when the Security Options popup displays.
Count the number of S0 devices and add double that number to your total Device count. If you have a 100 device mesh, 60 of them S0 then your mesh is functioning the same as if you had a 220 device mesh (60x2 + 100)
The symptoms you described in the first post seems to have caused a lot of us to imagine the resources are exhausted. The Z-Radios have a finite bandwidth, ZWave is 100k max, with 40k and 9.6k as alternatives. Zigbee is always 250k. Verses 4 core gig processor. The processor is waiting really fast on the ultra slow radio speeds (by comparison.)
This is a really fantastic explanation, thank you! I'm excited to dive into the USB stick to explore the items that are outstanding.
Two questions while I have a smart person here on the topic:
With the SI Labs software and the USB stick is there any way for me to observe the traffic that is flowing on the network? Basically I'm trying to figure out how I can quantify whether my network is congested or not.
If congestion is indeed one of the challenges, would doing a Hubitat mesh such that I have 50% o my zwave devices on one network and 50% on another resolve that in your opinion (assuming that I'm no longer adding devices)? When I first switched over to Hubitat from Homeseer due to the much better ecosystem support, I purchased two C7s, so I just have a brand new unused C7 sitting here. In another thread some time ago, a lot of people were of the opinion that using mesh introduced unnecessary complexity and problems. Any thoughts?
I have a dedicated ZWave stick (SiLabs from Digikey) that has been flashed with the Zniffer code. It's theoretically possible to flash it back, but you'd have to capture the original code, since I'm not aware of SiLabs distributing it.
That single Zniffer (along with SiLab's Zniffer tool for a PC) allow me to watch any of my 5 hubs and their traffic. Be aware though that it's a radio too.. interference and distance are always a factor.
I have, as I mentioned, 5 Hubitat hubs (active. 2 more are older and packed away) so I'm the last person that will try and dissuade anyone from implementing multiple hubs.
Since you have one, fire it up and get HubMesh running. Mirror a bunch of devices to it. (That way you can have it working in an hour, vs Exclude/Include a dozen devices before you can even experiment.) You'll find it's faster than you can detect. Turn a light on from the second hub and it will be exactly the same as done from the first hub. Ethernet is very fast and we humans can't really "see" 12 ms or less. If that seems good, then you can take the time to start planning for and implementing a migration. I chose to split the devices in my home by area. I'm mostly a ZWave house, so I have an Upstairs Hub and a Downstairs hub... then when I crossed an imaginary line I set for myself on device count, I got another hub and took devices from both Upstairs and Downstairs to become "Front"
and thus I'm not buying many devices, not adding many devices, not open for ghosts from that Inclusion process. )
