Z-Wave devices that should be changed from secure to non-secure

Beginning with version 1.1.7, it is now possible to include non-critical Z-Wave devices in non-secure mode (except for locks and garage doors).

There are several advantages of joining Z-Wave devices in non-secure mode:

  • respond faster
  • have better range
  • don't require special repeaters

By default, newly added devices no longer join in secure mode. However, previously added devices that have been included in secure mode, must be excluded and re-included to take advantage of this new option.

To identify which devices are secure (encrypted), go to your hub's web interface and click "Devices," then click on the link for each device and scroll down to the "Data" field in the bottom table.

An encrypted device would display: zwaveSecurePairingComplete: true. A non encrypted device would not display the "zwaveSecurePairingComplete" field.

image

Below are some of the devices that we have identified as being included as secure*:

Aeotec (Aeon Labs.) all models. Although Aeotec allows users to pair devices as non-secure, hitting the Z-Wave button twice on the device (accidentally or not) triggers the secure inclusion.

Zooz

  • Zooz 4 in 1 sensor
  • Zooz Zen15 Power Switch
  • Zooz Zen20 Power Strip
  • Zooz Zen26/Zen27 Switches
  • Zooz ZSE18 motion sensor

Monoprice

  • Monoprice Contact Sensor

Inovelli

  • Inovelli NZW31 dimmer

*NOTE: not every device listed above is encrypted automatically, if you have one of these, it would be a good idea to check the "zwaveSecurePairingComplete" flag before performing the exclusion and re-inclusion process.

If you happen to discover other devices, please share their model by replying to this post.

5 Likes

Zooz Zen15 Power Switch
Zooz Zen20 Power Strip
Zooz Zen26/Zen27 Switches

1 Like

My Fibaro FGMS-001 "eye" motion sensors were in secure mode

1 Like

Zipato Siren

1 Like

Monoprice 4in1 motion sensor.

1 Like

Fibaro Flood Sensor FGFS-101

1 Like

FIBARO Z-Wave Plus outlet FGWPB-121

1 Like

My Fibaro FGK-101 Door & Window sensor looks like it is joined in secure mode as well

1 Like

I have 2 zooz 4 in 1 and a monoprice contact with secure mode :man_facepalming:

I had the aeotec HEM with secure mode and it was a mess, after adding it as non secure problem fixed.

1 Like

Monoprice 15270 Window/Door contact
Monoprice 15271 Motion & Temperature Sensor
Monoprice 15268 Recessed Door/Window contact. These are all secure devices.

That 15268 recessed contact is not found as a generic zwave contact sensor. I had to manually set it and it works fine.

I would be helpful to get a proper device handler for those 15271 motion temp sensors.

The generic DH has a pulldown list of plus and minus 5 degrees for the temperature offset. That is often not enough to correct these Monoprice units. A fill-in box would work better.

These sensors allow for user settings via the DH for Inactive Timeout, Motion Sensitivity, and Manual Poll interval. Not too excited about losing those controls in Hubitat.

So I inadvertently set up all my aeotec recessed door sensors (exterior doors) in secure mode. They do seem to work okay though. Being lazy and having other interesting things to experiment with in HE I may leave them alone for now.

It makes sense for locks and garages and other "critical" infrastructure devices. If a bad actor compromises the not secure devices though (or the hub via the not secure devices) couldn't they possibly trigger the secure ones? What is the point of secure mode? Seems like an all or nothing proposition..

Because it's in secure mode a sniffer cannot ask it send it the unlocks codes stored in the lock easily.

Some devices send/receive sensitive info. Obviously Lock Codes is one. "Open the door" is a command you wouldn't want a bad guy doing. ZWave calls those types of devices "Barrier" and they have mandatory Secure.

Door / Window sensors on the other hand, are "dumb" in the sense that they don't control anything... status only. A bad actor "taking over" a door sensor will not be able to change it to a controller and somehow gain access to the entire network. (Not exactly sure what "taking over" a door sensor actually means. :slight_smile: )

Yeah that makes sense - also for protecting open/closing/unlocking of those critical devices.

I guess since an attacker could possibly take over an unsecured sensor preventing it from responding properly that in my case with the exterior recessed door sensors it might be a good idea to keep them encrypted.

I wonder how the mix of secure/unsecure devices affects total security.

Somebody sophisticated enough to hack you zwave probably wouldn't bother. It would be easier to just flood the bandwidth with so much noise and interference that nothing could communicate.

HA is not a really a security system it is a deterrent, a convenience and for monitoring.

1 Like

Is there are way to test for this? If a bunch of my devices on a network (Z-Wave/Zigbee networks) drop or become non responsive but the hub/lan/internet is still functioning it would be good to get an alert about something like this..

I want to second the idea of "a proper device handler for those 15271 motion temp sensors". I've got a couple of them, and they are readily available, inexpensive and work well.

1 Like

EDIT: Aetec Home Energy Monitor GEN5 does not require secure join and due to the amount of data this type of device generates it is strongly recommended to join it non-secure to avoid z-wave mesh problems...

Also, I don't have the Monoprice contact sensors anymore but back on my ST days I had problems with them and found that joining them securely fixes those issues, confirmed by other people. This is actually the Hank Door / Window sensor (HKZW-DWS01) (rebraded by Monoprice).

I believe this is incorrect, I have my HEM not secured paired and I have 0 errors, all parameters working. You can use it secured or not secured, but @bobbyD suggested to use it unsecured because the amounts of data slowing the mesh, after doing his recommendation my mesh has been working normal.

1 Like

Interesting, I added the device this morning and was not getting any data until I finally added it securely... maybe firmware related? I do not see any firmware published in the support page for the NA version but that does not mean they have not shipped them with newer versions... I can't figure out how to check the firmware version of a Z-Wave device in Hubitat though...