Help. I don't know where to go from here:
I have been using my C7 hub since 2020 but haven't had much troubleshooting outside of initial set up type issues (full disclosure that I only have used C7 for a subset of devices and apps for most of the time since I had other hubs in use already and feared the transition breaking what worked). Slowly moved my Zooz switches and some bulbs/outlets over and created scenes for public areas in house hoping to reduce increased issues with ST. But within last few days, several Zooz items quit working.
I noticed that control has dropped off for many but not all Zooz item and not other sensors, plugs or zigbee bulbs (Zooz is mostly dimmer switches like Zen27, 24, etc which are Zwave).
The scenes quit working and I also noticed when looking into it- in logs that if I press switch on/off directly in app locally, no log of that push happens (log does recognize physical operation). I also noticed that my garage door on a Zooz relay (Zen17?) wouldnt respond to commands. I complicated my troubleshooting in that I recently added a few Zooz Zen15 poweroutlets and the makerAPI to existing HA hub as well as did an Hubitat update. The Zen15 outlets seem to work okay and send logs as power graphs to HA. Also, the issue started a few days after those updates, so not immediate but initially still working with changes. I have a mix of drivers 'Zooz ZEN Dimmer Advanced' , 'Zooz Central Scene Dimmer' and 'Zooz Central Scene Switch' which worked up til now. I do get some warnings 'The device's firmware version doesn't support custom duration for setLevel.', but I think I got those before the total drop of control.
I am totally out of ideas after rebooting and still having the application buttons do nothing in terms of logging. thanks in advance!
Post a screenshot of your Z-wave details page (Settings tab, Z-wave Details). You may have to do multiple screenshots to get all devices, but please post them anyway.
In my mind, when I think of the symptoms you have, I imagine a ZWave (or Zigbee if it's that radio that is stuck) packet that is "wedged in sideways" in the path between hub and Z-Radio. There's no mechanism for unsticking it except power cycle.
Both radios have an Enable option in the UI and again, in my mind, the radio gets disabled: somewhere just beyond that switch. Toggling it does nothing,
above is device log for lower hall bank of led cans on three way. I pushed the application on/off buttons then went to physical switches to turn on and off. does not do anything from app.
below is from devices page of Zwave settings with an example of several of these Zooz switches (lower hall device above is second to last in this list)
My read of your ZWave Details is 1) they all have "repair" buttons, which tells me they are Powered devices (not battery) 2) There should be a route showing, although if this is right after a power cycle, they may not have had time to report in yet.
No route, if legitimate, means they are out of range. "Worked yesterday, not today" often means you lost an important Repeater, as my first wild guess. One of my favorite stories, because of how nuanced it is.. regards a home that worked fine, until the wife got dressed in the morning. The husband would wake first, get dressed and all the automations would work. Then when the wife got up and started doing her morning process, the automations would fail.
I'll jump right to the punch line, the problem turned out to be a mirror. When the wife was getting dressed, being shorter, she tilted the mirror, then once done, would tilt it back to make it look tidy. When the mirror was tilted just right, the RF got reflected too and some important repeater got cut off. Adding an additional repeater cured the problem, as the story goes.
That 0x1D (29) node has a pretty poor RSSI (signal strength).
I would tend to agree you either need more devices, or more repeaters. Typically it takes about double the devices you have to form a strong, stable mesh.
I can understand the repeater concept. Given most of the devices don't move (with exception of recent additions days before), this I will have to think about. Does Hubitat keep much of a 'change log' on re-path of devices' communication and does the dB or any other signal strength bear looking into? I see the route changes info, but I did just do a power cycle. I wonder if worth snapshotting zigbee and zwave routes every so often for future troubleshooting.
If it were me, I'd repair every device with no security.
At the very least, I would do the one outlet (c2) that's paired with S0. If that's a power reporting outlet, then they typically are pretty chatty in the first place. S0 adds a fair amount of overhead so that one device could bring the entire zwave network to a halt by chewing up the air time.
The last device with the discover button may be dead. Hit that button and see if it comes back.
Before you do anything, hit that Firmware Update button on the top of the Z-wave Details page. The firmware updates have made some significant improvements to the Z-wave radio.
I would let it do that firmware update, and do a shutdown, pull plug at the wall for 30 seconds, and boot back up again. Let things settle for an hour or two before trying to determine what else is going on.
Just to elaborate a little bit on what @FriedCheese2006 has said. All encryption for Zwave is 256 bit AES. They are also suppose to have hardware to assist in that encryption if they support it. The problem is S0 for whatever reason triples the traffic where as S2 does not. So a chatty device is 3 times as chatty if it is connected with S0. The general rule is only use S0 as a last resort for perimeter devices only. That would mean Locks or window sensors and such that are at the entry points to your home.
S2 is a little bit muddier. It doesn't increase the traffic per se but it does potentially take additional cpu on the hub to decrypt each packet. I have over 53 zwave devices on my network and 41 of them use s2. I do have a zwave dead bolt and it is connected with S0. My network works great.
One thing you could also consider is sometimes a device can get in a bad state. I have two devices that do that occasionally. Things stabilze generally after i pull the airgap on it, or flip the breaker on/off.
thanks, all. i will do a bit from all three suggestions and report back.
If I am not S2, it must be because it didn't ask me when pairing (or I didn't know how to sequence to control pairing in desired Sx modes). As I recall, ST would prompt for which Sx mode, but I could be mistaken.
As to device issues, I do occasionally have to pull the airgaps on select (usually specific Zen models) ZooZ dimmers on occasion, but usually there are tell tales: like even the physical button is locked up.
Got 'partial healing'. Some devices and scenes are responding; albeit very slowly. I will have to keep working on it and possibly do a reinstall of some zwave devices to rebuild.
As an aside, I don't quite understand the mesh paths (I assume it considers latency, signal strength and other factors), as some paths are not the shortest distance or most open path. Also, since most of these devices are 120v, I am not sure why signal strength is all over the place (regardless of hub distance).
Naive question - I always thought this encryption/decryption was done by the ARM cpu on the z-wave SoC, as opposed to the hub's ARM cpu. Is that not the case?
Well it has to be encrypted and decrypted on both ends right. So whatever is doing it is on both ends. My understand was that on the device side there was a dedicated piece of the SOC that handles it. So it could stand to reason that there could be a similar piece of hardware that is part of the Zwave radio on the Hub as well. Part of my logic though is that there is a difference between handling ones own traffic and the entire mesh so it would lean on the hub more. I could be wrong on that. But I am confident that the chips had dedicated encryption hardware to ensure low power draw.
somewhere just beyond that switch. Toggling it does nothing,
