C-7 secure join setting

Just got a C-7 and having poked through the forums in advance a bit I was aware that there is meant to be a setting for which z-wave devices should be included securely (only security-sensitive devices like locks by default). However I don't see that setting where I expect on my C-7 - on the z-wave settings page at the top there is only a region setting and an enable/disable setting. Shouldn't there also be a "secure join" option here?

Partly I ask because one device I included, an inovelli 4-in-1 sensor, shows "zwaveSecurePairingComplete: true" which isn't what i expected.

No, the C-7 only provides security options during pairing. You'll see options if the device supports S2 (and can choose to downgrade if desired--uncheck everything to pair without S2 or S0). If the device supports S0 only, you won't see any options, but that would either be because the device requires it (e.g., a door lock) and you can't downgrade, or you have a device that can pair either way (I have some older plugs and motion sensors that can) and you chose the on-device option for S0 instead of "regular" pairing (not sure what the spec requires, but every device I've used has a different on-device inclusion procedure for these two cases, so either way, you get a choice).

My guess is that Hubitat is aiming to get certification and a hub-wide option as before is unlikely to achieve that goal. :slight_smile:

2 Likes

Thanks, that makes sense. I wonder if this changes the old recommendation to pair with S0 for all devices besides locks etc? I read that S2 is more efficient than the methods available from that time, so perhaps there is now no purpose in downgrading to S0?

If you are going to pair a device securely, S2 is always better than S0 (if the device supports S2, of course).

(standard disclaimer: If you are using a user made driver for the device, make sure the driver supports S2 commands as well. Not an issue for in-box drivers.)

1 Like

I guess I wrote that wrong, sorry, I was incorrectly equating S0 with insecure! Is there still any useful benefit now in downgrading from S2 to insecure?

That is a debate I'm not getting into.

I, and many others, don't pair anything except perimeter security devices (locks, sirens, keypads, etc) as secure.

Others want to do everything secure.

It is up for the end user to decide.

From a performance standpoint, though, S2 and unencrypted should be similar. The 3x messaging penalty that was present in S0 was removed in S2.

2 Likes

I agree with the above ... which is to say that I won't tell you what to think. :laughing: I've seen at least one staff member recommend that the previous recommendation, except now using S2 instead of S0, is sufficient in his opinion. I think the Z-Wave Alliance would prefer you use S2 wherever it is available or at least make it hard not to, which again is why I'm assuming the Hubitat UI was changed in this way.

Eventually, I'll probably use S2 anywhere I can (this is initially how I tried pairing everything on my C-7 under the assumption that most users would do the same--it does say not to change settings if you aren't sure). For the time being, as mentioned, some community drivers won't work with it yet, so I'm avoiding security on those. The new Hubitat Z-Wave stick is also...well, new...and some devices seem to have problems pairing, particularly if secure, so I'll also avoid it for the moment if it's problematic for particular devices. But as always, I'll continue to avoid S0 except where it's the only option.

2 Likes

This was posted as a reason to choose S2 when available in another thread here where S2 vs. S0 was being discussed...unfortunately I just grabbed a quick snip of the conversation and can't remember which thread I found it in, or who posted it! :slight_smile:

If below is accurate this would suggest using S2 when available could improve overall performance as the number of devices increases:

    1. Network and hub performance. S0 sends 3x the amount of traffic that non-secure & S2 send. Hubitat has traditionally recommended to have many device types on a non-secure network. The improved performance of S2 allows a default-secure posture without sacrificing performance.

I have my IoT stuff on a separate VLAN w/full separation so I'm not so concerned about S2 w/switches from a security perspective (even if someone hacks into my IoT side they can't get to my main network) but the performance aspect mentioned here got my attention.

Does anyone have any additional context on this?

That statement seems correct. S2 does not come with the messaging/battery/performance penalty S0 does.

But considering I don't even use a login on my hub, I just can't get interested or excited about zwave encryption in general. But each to their own!

I agree with that, and I think MOST users will pair with the defaults, which are to use S2 (when the device supports it).

Now, the 1st time they need to re-pair a device and have to remove it from the wall to see the pairing code they may change their mind on the whole topic. Lol

3 Likes

THIS!

Found this out the hard way recently...what a PITA, had to take a switch out that I had just put in. Now I take pics of my S2 QR codes and save them in a local folder. Not going to get caught out again... <eek!>

2 Likes

Yes, that is a smart thing to do for in-wall devices.

Not sure most new/novice users will know to do that though.

1 Like

It seems like if you join them S2 unauthenticated, it provides you with the full key (at least it did that once for me). Potential work around? Join as S2 unauthenticated, copy down those first 5 digits, exclude, reinclude as normal and you now have the digits to enter without pulling the device? Assuming the key is the same between the two.

(Untested but it occurred to me as I was moving devices last night)

1 Like

Interesting idea... I also saw it give me the full key for an S2 unauthenticated pairing attempt.

1 Like

Yea, saw that a few times as well. What I've found to work is to hit cancel on both the key request and the pin, then wait. After a couple of minutes I've been able to go into Z-Wave Details page and hit refresh/discover a time or two, and then the device completes the initialization.

1 Like

How difficult is it to update drivers to be S2 compliant? Does the driver need to be completely rewritten or is it just small updates?

It's a small change, details will be available in platform release 2.2.3

7 Likes

I would say it LOOKS like a small change. Things that are easy for Mike aren't always easy for hacks like me. :slight_smile:

Now that I have 100% of my zwave devices cut over to my C-7 I'll start looking at it - I only have 2 drivers to update for S2 anyway.

I paired one of my GE Enbrighten dimmers as S2 unauthenticated (no issues pairing it S2, just FYI) specifically so I could work on this.

3 Likes

@JasonJoel: To quote my favorite book in the world... "Go dog, go!" :wink:

2 Likes

Sorry to ask what is going to definitely prove to be a dumb question, but I'm brand new to Hubitat, having received my new unit yesterday and I'm busy converting from Vera... I see all these mentions about associating in a non-secure method, but I've never seen HOW to do that?! All I seem to have is a button that generically puts the hubitat in ZWave pairing mode, but there's no separate button or slider to make it secure mode or not. I have 2 devices which worked great on vera, but I can't get working on Hubitat. Both of which were mentioned in another thread that they work better unsecure. Aeotec door/window sensor (old version with external temperature connector) and the Aeotec heavy duty outdoor switch. Both of them will pair no problem, but never report in, and are not communicating. How can I pair insecurely?

TIA!!
Steve

I had exactly the same question a week or two ago in my journey converting from Vera - C-7 secure join setting!
The C-7 doesn't give you the choice, apparently. I saw probably the same mentions as you, but the updated manual for the C-7 does cover it, I think.