Zwave device not marked as 'secure'


I had some issues with a Fibaro smart plug (it suddenly stopped working and stated that had used over 80million kilowatts in total in a few weeks through a small halogen bulb it is switching :slight_smile: ) and decided to unpair and repair it. During the unpair I found that it went ‘out of sync’ or something like it. When I pressed the button for the unpair procedure on my smart plug, the Homey app stated that it was another device and that THAT device had been removed.

So I went to the developer page and removed it manually from there. (healing etc. didn’t help). The pairing process went okay, no problems there. What I do notice now that it doesn’t show the ‘secure’ flag anymore.

If I however look at the app and look at the ‘Geavanceerde Instellingen’ of the smart plug it states “1”. All of my other devices (including another smart plug of the same type) have “manager.vdevice.drivers.zwavebasic.devicesettings.yes_true”. This is the only device I have added since the 2.0 upgrade

Can anyone confirm:
Is my device secure/encrypted? (which is the only thing I really care about - The ‘1’ suggests it is.)
Is this a bug in the 2.0 firmware/app (that it shows up as something different and the developer page doesn’t handle that properly?

((also the ‘Battery’ field says “0” on the repaired plug and on the other plug “manager.vdevices.drivers.zwavebasic.devicesettings.yes_false”))

Any insight is appreciated.

I have had the exact same issue, a device (Fibaro Dual Switch 2) which stopped working, when it was re-added it was added as insecure.

You will need to create a support ticket for this issue.

Thank you for your reply. So it IS actually insecure now. (even though the ‘Beveiligd’ field in ‘Geavanceerde Instellingen’ states it as ‘1’)

I’ll raise a ticket for this.

Did you get an answere? I have two devices that show as not secure…

I did, The problem I had was a bug on the device list page. The device was added as secure however it did not display correctly as secure.

I only got a reply that the behaviour was a known bug and they were working on it. (It is resolved by now)
I had to re-pair (not as in ‘fix’ :slight_smile: ) the device in order to get it to show as ‘secure’. I had no way of telling it was added as secure or not. (maybe it was possible via CLI, but I never tried that)

So maybe re-pairing the devices may help?

Thank, I will try that.

Talked to Telldus today. They told me that I shouldn’t add any device as secured that isn’t a lock, door, alarm etc. Sensors and wall plugs operates faster and better as not secure and the Z-wave protocol is crypted as it is.

In their hardware (controller) you can chose to add the devices as secure or not secure.
They did know about the Homey but couldn’t say if or how to do the same thing in Homey.

That’s actually interesting information. Did they also mention what in their view ‘secure’ means?

If you look at online sources, z-wave (as a protocol) is not encrypted ‘by default’ and the ‘secure’ flag/command actually means/adds encryption (with the included data integrity and confidentiality, etc. etc.)

I am a Linux Engineer at an international financial organisation and from my professional point of view, all data transmission, regardless of function, purpose or method of transmission, must always be encrypted. In the case of z-wave, in regards to home or office automation, it’s actually a no-brainer.

Any data communication that is not encrypted, is trivial to listen in on and mimic them. This of course is extra important for wireless transmissions (since you don’t need physical access to a cable).
At first glance you could think, well I don’t care if my neighbour accidentality triggers my living room bulb. You can just switch it off again, and probably won’t think anything more on it. But by switching it off, a potential burglar knows someone is in the house, and that that person has switched off the light without being in line of sight of your house. A small raspberry pi with a battery unit just needs to be close by (under a pile of leaves in your yard for example).
If the data transmissions are encrypted, the burglar would only detect, that there is communication, and with z-wave being what it is (very chatty) it’s far more difficult to detect actual activity in the house.

This is just one small example of course, and, of course it’s far fetched, but there are numerous thinkable examples, like someone else falsely triggering your motion detector. The majority of thinkable examples can be mitigated by simply making sure everything is (strongly) encrypted.

No, they did not and I did not ask because I don’t know for sure how it works.
Reading on, I see that they say that communication is

  • Designed specifically for control and status apps, supports data rates of up to 100kbps, with AES128 encryption, IPV6, and multi-channel operation

As I said, I don’t know about this things but isn’t AES128-bit encryption pretty strong?

AES128 is indeed very decent for the purpose (not the fastest encryption cipher, but strong, robust and fairly easy to implement for hardware manufacturers, which generally means higher quality encryption). But it says 'supports data rates’blablabla. The fact it supports it, doesn’t mean it’s enforced (by default) or even properly used by all parties.

(For example: In the past z-wave units always used a default key (0000000000) which does make it encrypted technically, but, as you can imagine also very easy to break :slight_smile: )

At any rate:
If you are interested in cryptography/encryption (in general, not z-wave specific) there is a nice playlist on Youtube on the subject: totally about 45-50 minutes I think. It shows how encryption works. Using metaphores with paint color mixing and still carrying the load. It starts with some very high level background/history (back up to the stone age and the Roman Empire) and in the end uses simplified math)

1 Like