It is about time to support Z-Wave S2.
Z-Wave 700 chip is under way to the market.
Perhaps, HA should switch to something more reliable than OpenZwave?
1 Like
It’s been 3 years now, and the maintainer of Open-ZWave has shown no interest in S2 security. Regardless of all the well-known, “crack your house from the street outside” vulnerabilities, he feels:
the fact that there isn’t a compelling event to support S2 when we already do S0.
If you push back at him, you’ll get nonsense responses like the following–which show he simply doesn’t understand security at all.
If I’m going to break into your house, I’m more than likely going to throw a brick through your window than wait outside with sniffers hoping you do a secure inclusion.
There isn’t a lock in the world which can prevent a brick through the window. Smash and grab isn’t the kind of problem a door lock can prevent. The kind of security problems that locks prevent are considerably more personally invasive, and often lethal.
But with aphorisms like this, he stands by his belief that security isn’t necessary. Even though the Z-Wave alliance is quite clear that S0 isn’t secure, and haven’t approved any devices without S2 security for 3 years now. If you question him, he’ll ban you from the open zwave organization–apparently very invested in remaining ignorant.
HA developers have indicated their intention to stay with Open Z-Wave regardless Z-Wave - Home Assistant
…which means that HA cannot use Z-Wave in any secure context. Maybe for plug control, or lights?
It is coming at last!!!
1 Like
How do we convert from S0 to using S2 with our locks?
At this time you would have to exclude the lock and re-include it. There is talk of supporting a kind of transition process that would preserve node ids, but that doesn’t exist yet.
1 Like
I tried to exclude a device last night and reinclude with s2, and I couldn’t get it to work. I saw that you needed to set the security keys in the settings for s2 inclusion. Mentioned here and also saw the documentation was updated https://github.com/zwave-js/zwavejs2mqtt/issues/1593
It got further along but still connected with no security. I’m going to try a different switch closer to the hub but has anyone got s2 inclusion to work? If so, any tricks you used beyond what’s in the documentation?
Update - I was able to include two GE switches with S2 inclusion. One I had to do twice to get going. The trick seems that you have to type in the DSK code when prompted super fast or it will time out. I also had better luck with a laptop vs mobile phone due to the layout of zwavejs2mqtt control panel.
Unfortunately though the central scene control double and triple taps stopped being recognized after S2 inclusion so I rolled back to no security. It’s odd because the switch’s levels updated and it was controllable to turn on and off, but the double and trip taps, which rely on central scene control, were not being recognized with the device being included in S2.
I filed a github issue - https://github.com/zwave-js/zwavejs2mqtt/issues/1620
Update again- s2 inclusion is fully working now and all central scene notifications are being recognized for my s2 devices- which includes inovelli and ge switches.
1 Like
You saved my day 
1 Like
This has been driving me nuts… finally got them to work with copy and paste into window during inclusion… seems like this must be a bug.
Since security key exchanging can leave the network vulnerable while it’s enabled, the zwave specification itself has only a 10 second timeout for security key exchange. That’s not a lot of time.
In Smartthings, you can scan the barcode first, which captures the security key, then pairing is initiated. I suppose zwavejs could have you enter the key here first then start pairing which would help with the 10 second limit. I wouldn’t call it a bug though necessarily, maybe more of a feature request. Or, possibly add a warning about the timeout.
I don’t think 10 seconds applies to the PIN input. AFAIK that is specified by TAI2, “User MUST have verified / input the DSK”, which is a 4 minute timeout. Granting the security classes (TAI1) is also 4 minutes. The footnote you’ve highlighted is a special note for the 10 second timeout conditions specifically, in that there should be a +/- 2 second tolerance.
It seems most devices do not implement these timeouts correctly. Maybe they are applying a 8-12 second timeout to the User DSK verification when they shouldn’t be.
There are also cases where devices just fail to respond to some of the bootstrapping commands, which fails the entire process.
Is this just the SmartStart feature? That is on the roadmap.
I suppose zwavejs could have you enter the key here first then start pairing
This has been proposed for zwavejs2mqtt. It would sure save a lot of headaches. HA already skips prompting for the security classes in the normal inclusion path (chooses the default automatically), so pre-loading a PIN would be a nice feature.
1 Like
Fully concur not bug and due to the protocol. Tthe stack up of time, stick->zwavejs->interface->wifi can make the user time very short… I think the idea of being able to input the code as you start inclusion is great. I imagine the smart connect will also simplify this challenge. Since I’m re-adding a lot of nodes (with security) it’s very time consuming and a bit of luck to get them included in the first try. Until this thread i couldn’t figure out what what happening so the addition to the documentation as a notice might be good also. Thanks.
1 Like
Thanks @freshcoast I saw the 240 after posting and figured I was missing some pieces of the puzzle. For some reason though I’ve found it timing much quicker though and the 10 seconds seems like all I had for most of my devices.
The proposed smartstart link you posted looks very promising and like it will probably solve most of these issues.
All of my S2 devices fail to include securely if it takes me longer than ~10 seconds to input the PIN (haven’t timed it precisely, 8-12 sounds about right). The battery ones will even go to sleep. Based on my experience and the conversations here this “10-second rule” seems to be common.
I wouldn’t understand the S2 bootstrapping process enough to make an argument that zwave-js is the one at fault. Until someone can tell us that it isn’t a problem on other home automation platforms, I’m blaming the devices.
After a long day I got about 30 of my devices added back in with S2… I have migrated from legacy zwave to openzwave to the current platform and have about 80 device with some of them are not compatible. Most of the S2 compatible device added after 2 tires (a few took more attempts). I have a Raspberry Pi4 w/ USB hard drive, Zooz S2 Stick, and battery pack so i can walk around and put the stick right up against the device to get it to add with S2. It was a lot of work to get the system updated it seemed very dependent on proximity of stick to device when adding ~6 inches. Still working through getting the system stabilized performance wise (heal etc…). This would have been much easier with SmartStart or even the capability to preload the DSK. I think ultimately the stick proximity to the device and the inclusion process latency determine combined with the zwave_stick/stack-zwavejs-HA-webUI determined if you can get it all done within the 10 secs. Not sure if any of this helps and wish was a better coder to help solve some of these issues/features.
FYI, turns out this was a bug in Z-Wave JS, now fixed in 8.7.0 (coming to a future addon release). Should be much easier to add S2 devices now!
1 Like