Device shows S0 in one place and S2 in another

Hi,

I have a C7 Hubitat and a couple of 'Fibaro door/window sensor 2' devices (among many others). Under Devices, Device information, they show:

suggesting S2 security.

but under Settings->Z-Wave Details they show:

suggesting S0 security.

Also, when installing the device, I'm not given the choice as to whether to use security or not. I understand devices with S0 security don't allow the choice of security or not, and can be problematic (which these are, or can be).

Is this a bug? Should Fibaro Door/Window V2 sensors have S2 security? And thus should I have been given a choice?

Also, is the security 'choice' (to use or not) with S0 something controllable by the hub? I read about needing to use a Z-Wave USB device to install S0 devices without security. Seems this should be a hub option...or is it something to do with the Z-Wave chipset used in the C7, so not under SW control?

The S2 data on the device is a bitmask field and 128 is what it will show for S0 security (dont ask me why).
The Zwave details page however is really the source of truth, so your device is for sure S0.

SilLabs has decided in their SDK that if a device is S0 that the hub cannot offer the user a choice, it must pair with S0. This is force legacy border devices (locks) to be paired securely.

Honestly, with a window/door sensor, I would just leave it S0 and see if you have any issues. Its going to be low volume of zwave messages so it should not really cause any issues.

People go way overboard touting that S0 is so horrible and make it out like your hub will implode if you allow S0 devices on it.

4 Likes

I think it is because S0 uses AES-128 encryption.

Also tagging @bcopeland for the answer.

2 Likes

Its been explained before but don't remember what it was. Does not seem to have any sort of pattern besides maybe being some sort of 1 byte binary bitmask.

00000001 -- S2 Unauth = 1 
00000011 -- S2 Auth = 3
10000000 -- S0 = 128
10000111 -- S2 Access Control = 135 

Yeap, bitmask. S2 Access Control gets all the bits, plus an extra one.

2 Likes

Thank you jtp! I'm having trouble with one of the switches, so am grasping at straws... Could be (likely is) something other than security, like range, or just a bad device.

I have a GoControl switch which is just wacky, so I guess these things are somewhat hit-or-miss out of the box, or can be corrupted somehow if the wrong sequence of tamper switch activations and/or battery removal, or whatever happens at the wrong time.

Is it the one that you posted the screenshot of above that is giving you trouble? Garage outside Door? It only has one neighbor, the route looks direct though. It has two route changes. Those stats reset every reboot, how long has the hub been up? If you see excessive route changes that is a sign that it is having issues talking to the hub. Some sort of hard wired repeating device in the area may help.

1 Like

Yes, that's the culprit. Currently it's un-installed, mid way to its final resting place, where it got no updates. It's sitting right next to a Z-Wave First Alert smoke alarm, which is supposed to repeat traffic, but I don't know if it actually does (it's battery powered...). The smoke alarm will be midway to the hub at the end of the day. The hub has been up for a few days, since the last FW update came out.

Battery powered Z-Wave devices do not repeat signals.

4 Likes

S2 uses aes128 as well but doesn't suffer from the chattiness that s0 implementation uses. S2 uses single frame transmission while s0 uses three-frame transmission. This goes more to the chattiness of s0 not to mention certain hardware firmware implementations are just not well done. There may be some other technical aspects that I'm missing but I think that is the main one. (I'm sure someone will correct me if I'm wrong)

1 Like

If it has a hardwire option that is the only way it will repeat.
You might consider adding either some zwave light switches, or dedicated zwave repeaters between that device and the hub. My Garage tilt sensor for example has 19 neighbors.

Its also possible its location is interfering with zwave transmission (lots of metal?)

1 Like

S0 & S2 both use AES-128, but they differ in how the network key is derived. In the case of S0, the same key is shared among all devices and can be intercepted during a device inclusion. S2 uses Elliptic-curve Diffie–Hellman key exchange protocol (basically allowing the sharing of a key over an insecure channel that used to derive another key).

3 Likes

I still feel that it's a bug in the Hub code (apparently), Under Devices, Device information, which reports S2 security for a device which supports S0 security. It adds to confusion at the least....

Thank you all for your helpful information and network advice!

Wondering what (exactly) this does:
image
for Z-Wave and Zigbee devices...??? And does it make a difference whether the device is a repeater (plugged in) or not?

It’s for when you want to share the device with another Hubitat hub.
https://docs2.hubitat.com/en/user-interface/settings/hub-mesh

A Repeater needs to be plugged in to work.

3 Likes

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.