I am waiting for delivery of my new HE Hub to migrate from ST, in the meantime I have been lurking these forums and I'm intrigued by this, what is the reasoning behind defaulting to a less secure communication for all devices but locks? kind of suggests there is a downside to it, is there any reason why I would want this versus always joining secure as long as the device supports it?
Secure data transactions are three times slower than normal transactions.
Additionally secure communications can be less reliable.
I would also just turn this around and ask, given the above why would you want this?
Oh wow! I would have never imagined such a big impact... is it a problem of the Z-Wave chip not having enough power to handle the added overhead with good performance?
I've seen so many people complaining about reliability and speed issues with Z-Wave devices in ST and many other home automation forums and have never seen anyone suggesting to try joining devices in non-secure mode as an attempt to improve communication... I don't think anyone is aware of this!
I agree with you, personally I think in the home space even with locks its a lot easier to open a house with a bump key or a hammer than hacking my z-wave network, but of course as a tech person if you are given the option of doing things securely you will always go for it...
I'm not saying it's a good idea to keep doing something the way it's always been done just because it's always been done that way, but this change will more or less just let things work like they always have. Despite having been around for a while, secure pairing of Z-Wave devices was rare in my experience. Many didn't even support it. The relatively new S2 ("security 2") spec has superseded original S0 and is now required to be supported on all new Z-Wave devices, so I think that explains the sudden influx of devices trying to join securely (though on most such devices I've seen, there are different ways to put them into S2 vs. insecure pairing, and the S2 button press/hold/whatever tends to be a more complicated, less intuitive process, so insecure joining is easier).
If a more secure join type fails, the device may "fall back" to a less secure type (S0 to insecure, or S2 to S0 or insecure), except for specific types of devices (like locks) that require secure joining. I think Hubitat only supports S0 at the moment now anyway (as did ST last time I used it), so S2 devices are already falling back to at least S0.
But really, at least on ST, most people have been doing "insecure" joining for most of that product's lifetime to such an extent that most people would just call it plain "joining." The same is probably true for Hubitat. I suspect things will improve as secure devices (especially routing devices and controllers) become more common, but right now this default is probably for the best to allow most devices to work well (while keeping the devices that need security on at least S0 per the Z-Wave spec and device requirements)
PS - S0 also has a reputation for eating batteries faster than insecure joining, perhaps due to the multiple-messages-needed issue Mike mentioned (S2 reduces this consumption significantly). So, if you need another reason to consider S2/S0 vs. not, there's one if you have a lot of battery-powered devices.
So, I guess the recommendation right now is to use insecure as much as possible unless you have a very real concern about security and really need it and even then all you can do is S0 as that is what the Hub currently supports.
If/When S2 support gets added, does this recommendation stand? is S2 is as problematic (triple messages, less reliable and battery consuming) as S0?
I guess we'll have to wait for that to be implemented to know for sure but I would think the Z-Wave alliance has learned and improved not only security but reliability with S2... Although some of their decisions baffle me like not implementing a way to send encrypted firmware updates...
You will not see false, the secure pair line will just be missing. It is only there if paired securely. The device in your screenshot is not paired securely.