I have a bunch of Z-Wave GE/Jasco light switches I have added and they all work fine.
But none of them are secure, they are all either ? or - for the Security column in Z-Wave JS to MQTT.
When I re-interview them it says “Node xx supports Security S2, but no S2 network keys were configured.” How do I configure the keys?
I assume they were probably in the documentation for the switches that I threw out long ago…
Configure the S2 Keys in the z2m Z-Wave settings.
How do I do that?
Go to the Z-Wave Settings in Z2M. Did you try that? It’s pretty obvious.
No, I didn’t. But thanks, now I see them.
I have a key for S0 legacy that I manually imported from Open Z Wave, but the rest are blank (authenticated, unauth and access control).
Do I just generate new ones for all 3 of these and then re-interview the nodes?
Yes, just click the rounded arrows to generate random ones. You have to exclude and re-include if you want them included with S2.
Okay, I can try that. Thanks!
Okay so it worked except when I try to re-add the switch it asks for a 5 digit PIN.
As I mentioned above I threw out the documentation so there’s no way I have that anymore… Is there no way to add it without that.
The PIN is usually printed on the device. Take off the light switch cover and it might be there in the front, or in the back. There might be a QR code that you can scan and use instead.
Otherwise, you have to go into the advanced inclusion mode and manually select the security classes. If S2 Unauthenticated is available, you can uncheck any of the others and it won’t ask for a PIN. If it’s not available, and you don’t have the PIN, then you can’t use S2.
Okay I will try. Also any idea what “reset security classes” is? It’s a checkbox when I show re-interview node, wasn’t sure if this was related.
I don’t know the exact details, but that does not allow you to go from Insecure/S0 to S2.
Okay.
So I tried advanced inclusion and only checked S2 Unauthenticated (which was available in addition to authenticated) but it still adds in insecure mode. So I think I’d have to get the PIN to make this work, unfortunately.
At this point I’m going to roll-back to my backup with no S2 keys (you can’t delete them once you’ve added them for some reason in the UI) and for now leave everything unsecured since it appears moving to S2 secure is too difficult without the PIN.
I have to say I much preferred S0 which didn’t have all these problems (but I assume was not as secure).
Was S2 Unauthenticated checked when the initial screen was shown? If not, then you can’t enable it, you can only disable the items that are initially enabled. If the Unauthenticated was checked to begin with, then if it included insecurely it means some kind of error occurred during inclusion.
At this point I’m going to roll-back to my backup with no S2 keys (you can’t delete them once you’ve added them for some reason in the UI) and for now leave everything unsecured since it appears moving to S2 secure is too difficult without the PIN.
Why? Just leave the keys and include w/o security if you need to. That way you have the keys set already if you add devices in the future.
I have to say I much preferred S0 which didn’t have all these problems (but I assume was not as secure).
It’s insecure in that there are some very hard to exploit flaws. But the worse part is the performance, S0 requires 3x more messages than insecure. If you a device doesn’t require S0, then it’s recommended not to use it. That would include light switches.
Was S2 Unauthenticated checked when the initial screen was shown? If not, then you can’t enable it, you can only disable the items that are initially enabled. If the Unauthenticated was checked to begin with, then if it included insecurely it means some kind of error occurred during inclusion.
Yes it was checked when the screen was shown. I only un-checked S2 Authenticated.
Why? Just leave the keys and include w/o security if you need to. That way you have the keys set already if you add devices in the future.
The reason is I can no longer add z-wave devices through the Z-Wave JS integration that have a lost PIN. I will have to always remember to go into the full z-wave add-on, and use advance add. There’s a high chance I will forget this process in a year or two. At least with no keys everything just adds and works.
The reason is I can no longer add z-wave devices through the Z-Wave JS integration that have a lost PIN.
Why not? If you enter the incorrect PIN, or just skip the entry, it gets included as insecure anyways. Isn’t that what you’ve observed, or are you saying the device functions differently as a result?
If you have the S2 keys configured, then you can at least include future devices with S2 automatically. How often are you re-including the same old devices?
Also keep in mind, a device failing to include with S2 isn’t normal. It could mean several things: a bug in the driver software somewhere, a specific problem with that device, or even issues with your entire Z-Wave network.
The Z-Wave JS integration functions differently from the add-on.
The Z-Wave JS integration demands a PIN when you try to add a new device when you’ve put the S2 keys in. You can’t skip it. And if you put in a wrong (random) PIN it just fails to add.
The only way to add it insecure is to open the add-on and use advanced add and uncheck S2 auth. But I don’t remember that in the future, so better just leave it this way so it continues to function and I don’t need to mess around with it.
The Z-Wave JS integration demands a PIN when you try to add a new device when you’ve put the S2 keys in. You can’t skip it. And if you put in a wrong (random) PIN it just fails to add.
You can just submit with an empty PIN. I just tried this and it included as in-secure. What do you mean by “it just fails to add”? When I did this, the HA screen is hung. Is this what you mean?
That’s an HA bug (which we can get fixed). You can just exit out of the dialog (click the X button), and everything is fine (at least it appears so to me). The device I included was working normally.
Did the device not work after you included it this way?
Anyways, I’m not trying to convince you one way or the other, just understanding if there are any issues with this approach (which we’ve found one so far).
EDIT: this bug identified actually unloads the integration. 
I’ll go back on what I previously said, and say it’s probably better to just include the device as insecure instead of relying on the failed S2 bootstrapping. They seem to work the same, but I don’t know for sure if the device will be acting optimally.
I’d still recommend keeping the S2 keys configured. If you do decide to go back and remove those keys though, don’t forget it later on if you change your mind. 
At least we’re getting a bug fix out of this!