Security 2 Class 2 - Access Control (mainly for locks / keypads requires DSK PIN or Smart Start)
Security 2 Class 1 - Authenticated (most devices fall into this category this also requires DSK PIN or Smart Start)
Security 2 Class 0 - Unauthenticated (no DSK PIN needed but still encrypted)
Security 0 - (old security.. avoid if possible as this is very network intensive)
In order to include a device with no security all options must be unchecked. This provides the best performance for devices that don't need security.
I just ran into this during migrating some switches over to Hubitat. Some of the switches I didn't pull out to get the DSK code.
So there is really no reason to need to use security for basic light switches? I understand we want it enabled for locks and such. Do switches that could repeat for a lock need it enabled though?
My general rule is to only use security where it makes sense or the device requires it to operate correctly. Generally this mean locks, garage doors, etc. Devices that repeat don’t examine the data, they just pass it along, and so don’t need to be joined securely to perform that function (Ring Extenders work best when joined with S2 though).
In a perfect 700 Series world you would just accept the manufactures default with the assumption that you would be getting the "optimal" connection based on their specs/testing etc.
Every S2 capable device I have paired is paired S2 (the default).
On the products I have, S2 works fine. I'm not saying that there aren't issues on some devices/manufacturers out there though.
I guess I'm more in the camp that:
The default pairing needs to work, and work basically 100% of the time
When it does not work
If it is a hub or SDK issue then Hubitat is on the hook to work around it or get it fixed.
If it is a device issue, we should be feeding that back to the manufacturer and have an evergreen list of "bad S2 devices". In my opinion it is really in Hubitat's best interest as the customer facing portion of this to maintain the list to reduce their support tickets and customer exasperation.
If Hubitat really thinks the default pairing selections are wrong/inappropriate, that is a discussion they need to have with the zwave alliance. It isn't reasonable to expect an end customer to know which of the default options are OK or not OK. Defaults need to work. Period.
And while they are voicing their objection to the alliance, try to bring back selectable options for S0 security on S0 max security devices. That's the one place in secure pairing where there is a very reasonable discussion to be had in using it/not using it due to message proliferation in S0.
We don’t.. Only thing I would note is no-security is more reliable, most of the time.. I am looking into some supervision wrapper functionality that would in theory make S2 guaranteed packet delivery..
S2 does have a higher overhead .. Nothing as bad as S0 which requires 3 packets for every command.. But this is really noticeable when trying to do firmware updates as the max payload is reduced, resulting in way more packets needed to transfer the firmware image.
The only thing that leads to S2 being slightly less reliable is when nonce synchronization needs to happen, you can end up with a lost packet, which is why Supervision was introduced..
That makes perfect sense. I'll only use the S2 for locks and such.
Lastly, any performance difference in pairing a switch with S2 that sits directly next to a battery powered lock? (On the old ST platform we always talked about beaming repeaters and such but S2 never came up)
Makes no difference if it is S2 S0 or no security.. Repeaters don't "see" the security.. You do want a beaming capable repeater.. but "most" z-wave plus repeaters are beaming.. It was optional in Z-Wave Plus so it could be hit or miss.. Z-Wave Plus V2 (700 series) repeaters beaming was mandatory..
I have one of the first version of the hubitat. I have a GoControl Garage door controller. Worked fine for months. Recently my GoControl garage door stopped reporting status to hubitat. I've removed it from hubitat and re-added it a few times but it still won't see the status (whether the door is open or closed) I'm thinking that's because of Z-wave security. Is the original hub capable of using it or do I have another issue?
Which version of the HE hub do you have? Sounds like C4 or C5?
S2 is not required for devices to work/communicate, but can in some instances help make communication more reliable. I have dozens of S2-capable devices and none of them are connected using S2, and things work just fine.
I would start by putting in a new battery, in case low battery is affecting reporting.
Sorry I forgot to mention I put a new battery in the tilt sensor as well. I have a C-4. I'll pop this question over in a more appropriate area of the forum. Thanks for the response.
If it was reporting before and now isn't, then security can't be a factor, because the security hasn't changed on the C4. The chief suspects are usually, battery (you've already changed), interference, loss (battery or failure) of an intermediary device that was providing routing.
That's the one place in secure pairing where there is a very reasonable discussion to be had in using it/not using it due to message proliferation in S0.
