A while back I moved to C-7 and upgraded everything to S2 security (all my hardware already was -- I was just waiting for a capable Hubitat). Mostly the same hardware as my old C-5 network, though I've probably added a couple of things since.
What I've noticed is that Z-wave network repair gives me a few hops that seem silly to me. It may have been the same with C-5 but I never looked so closely because I had fewer problems. For example, Hubitat will reach out to the far side of the house to come back to nodes that are much closer. Maybe it's working around the chimney but that's not strictly a line-of-sight obstacle.
But anyway, what I've found is that some of those intermediate hops are prone to locking themselves out of the network. They're all Homeseer light switches. They continue to work with the local switch but become unresponsive or intermittent with Z-wave traffic and need a full power cycle to recover. This means that they also wipe out parts of the network that went through them.
First, has anyone else started to have these problems since moving to S2, or since moving to C-7?
Second, can I blacklist certain nodes so they can't be used as intermediate steps in the mesh?
Yes.. There are quite a few devices that lock up, as you described, when included with S2. This is a firmware issue on the device, when included without S2 they behave normally.
@shos1 What bcopland said... That said, re pair everything with no security. Really only door locks and garage door openers should have security. The rest, not so much. This will also lessen the overhead of the mesh for decryption. And as always, since you just moved everything, check for ghosts!
Yup. I've been a big advocate that the default pairing needs to work, and needs to work flawlessly. But that being said I found at least four different devices that have problems when paired with S2 security... Thanks SiLabs.
So now I'm more in the "no security" camp... Even though it's completely ridiculous to have to do so. But it is what it is at this point.
It might be difficult for them to do that without straining relationships with manufacturers... Might be something easier for the community to do than for hubitat to officially do.
Support probably has this data, and we (community) will likely have a harder time proving it was S2 causing issues. But maybe if someone in the community knows of devices that "act naughty" when paired S2, then that would be good to have a compiled thread of them. Maybe Hubitat would even sticky the thread?
Not really .. It seems to be a lot though.. But not every model of those manufacturers.. And probably not every firmware version of those affected models..
Any such list would need firmware and maybe hardware version in it as well. Especially for things like Jasco/GE devices that just magically come out with new firmware and hardware versions seemingly randomly.
Everything needs to be encrypted. As people are still learning (painfully slowly) with the web, there really are very few cases where unencrypted traffic is as benign as once presumed. If it wasn't going to be properly encrypted then I would never have bought any Z-wave devices in the first place.
Originally I bought a Hubitat C-5 because Z-Wave implied that everything put on the market after a certain date would be S2 compatible. That turned out not to be the case, but I still only bought S2 peripherals on the basis that eventually I'd get the Hubitat situation sorted out. So I got a C-7, and only then do I learn that S2 doesn't actually work anyway, and apparently all that money has gone to waste.
Are any of these devices getting fixed with firmware upgrades?
Couldn't there be better diagnostics on these situations? It's fairly hard to tell when a device is responding as it should or if its response is just not changing, and having a list of devices that haven't acknowledged their latest communication in the proper way would go a long way to explaining why other strange behaviours are coming up, like lights (even lights which haven't themselves crashed) taking forever to switch on or off.
The device firmware would come from the manufacturer. Also just because something is encrypted doesn't mean it's good. See S0. Chatty AF and poorly implemented. That said, I really don't need encryption on a light switch or bulb. I need encryption on door locks and garage. I do a lot of network security (Network Engineer for 30 years)... Even with that, if people want in, they're gonna get in to the house. Unlikely they're going to get through my firewall into my hubitat and the worst they can do is scan the signalling to my house to see what light turned on. They won't get any lock codes etc...There is also no real way to backdoor from a lightswitch signal into an ip network either.
Yes, S0 was plainly a disaster, which is why I wanted nothing to do with it. S2 is certainly questionable but at least the result of a serious effort (even if it did turn out that nobody could implement it). That's really all you can do for any level of security. Keep to the things that have the fewest known serious flaws, which is what rules out cleartext and S0.
