HA_fanatic:
Well, S0 failure to include an Aeotec multi sensor means that the sensor was paired non-secure. S2 devices are not that rare, as you highlighted, new devices are required to have it, however controllers are rare. So what good does it do to have an S2 device if your controller can only handle s0. Might as well not encrypt the device, because S0 is flawed anyway and creates more problems than it solves. Again, personal opinion of non expert, which I am sure @JDRoberts will debunk when he feels better. See, we need you @JDRoberts , get better soon
You would think that would be true, but in fact, smartthings just recently, like in the last couple of weeks, made yet another platform change where they are now going to encapsulate everything. It’s requiring some changes to some DTHs, which may be part of what’s going on here.
Starting with 0.25.X hub firmware release, the handling of encapsulation for Z-Wave messages are now delegated to the hub. This change was mainly driven from the forthcoming of Z-Wave S2 to our platform and instead of having to add additional encapsulation functionality to the DTHs, we decided that it is best to perform auto encapsulation at the hub level and remove any encapsulation added to the message in order to reduce the responsibilities of the DTHs.
There are two main changes starting in 0.25.X hub firmware release that we should discuss and the impact it will have on the DTHs.
Auto Encapsulation (Security 0, CRC-16, None) of Outgoing Z-Wave Messages
Auto encapsulation of messages is based on the properties of the device and command classes, reported by the device itself. In past…
2 Likes