@bobbyD
Back in V1.1.7 you posted; unless its really required (i.e. locks etc) one would be better off not pairing devices with security.
Is this still the case in 2.2.4?
i really only pair locks and garage opener if i can securly.. and extenders..
i have a couple of light switches and multisensors paired s2 only becuae i was having issues pairing and they seemed to work best that way.
1 Like
I pair everything S2 that is S2 capable. Why? Dunno, I just do. There is no (appreciable) performance or functionality penalty to go S2 - so why not make it more secure? Not that it matters, but that is the recommended pairing philosophy from SiLabs, too.
That said, when I do an S2 pairing and it decides to just pair non-secure anyway, which happened just this weekend on a device, I don't go back and remove/re-pair it as S2 either. 
I would only do S0 on perimeter security devices (locks, garage door openers) that don't otherwise support S2, as S0 does have a performance penalty.
3 Likes
That's an interesting choice. I personally go out of my way to ensure that no devices are encrypted, unless they must be (locks and garage doors).
2 Likes
the extenders at least the aeon 7's needed to be secure i think in order to run tests to other secure devices and also be able to turn the light on and off? also I believe the ring ver 2 needed to be secure to check for power outages.. and least the one i am using for that?
1 Like
Just about everything I own (mostly Zooz) always wants to include with S2, and I always just choose whatever the default is when pairing. Is there a performance hit I should worry about with basically my entire mesh included with S2? I have something a bit north of 60 devices...
My Ring Extenders won't pair unless I use S2 Authenticated
2 Likes
In my mind security is an unneeded layer of complexity that if not required should be opted out.
I keep thinking of junior engineers dimensioning a mechanical part. They seem to put the default tolerance to every dimension. When I asked they why they invariably state "...well its the default..". My response is "so consider the following:"
One day a quality engineer comes to you and says a lot of parts were received and a number of them are 0.001 over the tolerance. You say that OK its not a critical dimension. The quality engineer says "well change the drawing if you don't need that tight a tolerance". You say "I can't without customer permission". The quality engineer says "then I will have to reject the lot and we will be out of parts for the scheduled build".
This has happened a number of times that I've been involved in. So this is where I get the inclination to not add complexity unless it is needed. I fully realize the above scenario is quite different that a light on a Hub however it reflects my philosophy.
Sorry for the long post.
I don't know if this reflects your situation or not.
In repairing my WD200+ dimmer w/o security the flow was somewhat unexpected.
- Reset the 200+
- Start the Hub Z-wave looking for devices, pressed the 200+ top button (initialize discovery)
- A device is found and the security window popped up
- I selected NO Security pressed OK (or whatever closed the box)
- Nothing happened..... waited some more....nothing happened.
- I restarted Z-Wave discovery
- After a while the 200+ was detected without the securing window popping up.
- I saved it and it was joined w/o security.
I would not have expected steps 5 - 8 but it allowed me to pair w/o security. You might give it a try.
The same here. I just don't see any reason to add complexity if I need to later unpair and repair them and have to track down S2 codes and worry about that additional baggage...I've never noticed a performance problem or issue from pairing unsecured.
The only things I pair securely are my garage doors and locks.
1 Like
