[REQUEST] User selectable Z-wave security levels in order for associations to work

Yesssss! by entering a bad PIN (eg: 00000) during inclusion, the Fibaro “Roller Shutter3” is not in: “S2 Authenticated” but in unsecured mode !!! so I can create flows with Zwave: “send raw command”. Many thanks to @Da_JoJo for suggesting this workaround by entering the wrong PIN code


Glad that worked. For the S2(unauthenticated) it’s not an option though. I haven’t looked at the driver-code , but is there a possibility to change the inclusion of S2(unauthenticated) to force S2(authenticated) and do the same security code trick ?

I have tried the new code with both “requireSecure”: true and false, changes nothing for my device (sunricher rebranded K8 remote)

I tried it too, same result. You can only enforce secure for locks or similar, ut not force uncecure. As secure is the default that seems hardly useful. That would only be relevant if S2 inclusion failed and unsecure was attempted because S2 failed.

Would have been great if false meant insecure, true meant force secure and unassigned meant default bahaviour.

Associations are made completely useless after 7.0. Had a bunch of fibaro dimmers with direct associations to namron switches, and it worked all fine (and still does after 7.0). Just refurbished a bedroom, bought a dimmer and switch to but no Sir, not this time. I want the direct association to work, just in case the Homey breaks or fails. They should have implemented a choice for what security level you want to add components with BEFORE they messed it up.


Any feedback from Athom regarding this issue yet? Or maybe someone has come up with a working hack?

In SDK:2 “drivers\fgbs-222\driver.compose.json” , I found the next part:

    "includeSecure": false,
    "learnmode": {
      "image": "{{driverAssetsPath}}/learnmode.svg",
      "instruction": {
        "en": "Press the button on your {{driverNameEn}} three times.",
        "nl": "Druk driemaal op de knop van uw {{driverNameNl}}."

IncludeSecure is the “old” tag to prevent S0 security. Sadly it was not used to apply to S2 security.

I’m new to Homey and this sort of protocols, but could it be possible to do a raw configuration to change the security parameters?

I’ve checked the manual for the dimmer and I see now that there is not any such secuity configurations listed, but was thinking that there might be more configurations available than specified in the manual…?

No. It`s part of the inclusion process.

Really hope this can be fixed in an upgrade soon. Losing the ability to set up associations between lights and push button remotes is a major set back in my opinion.


Having associations between light switches and lights is not only a nice fallback if/when homey for some reson is offline or breaks down, but a needed failsafe!


Here’s the answer I got from Athom support regarding the issue:

"Thank you for reaching out to our support.
We are aware of this and have implemented the secure pairing this way because adding devices with S0 security was causing many issues with devices overreporting and causing instability. Furthermore we recommend not to use associations but to use flows instead.

That being said, we are also working on this and improvements are being made which may result in the possibility to have a free choice in security level again without the earlier mentioned problems. Unfortunately I can’t give you a timeframe on if and when this will be implemented, but please know it is on our developers roadmap."


FINALY!!! Here’s a temporary fix :slight_smile: (CLI install method)
To disable security remove requireSecure and/or includeSecure from the zwave property in your drivers manifest (if you are using them).
and add “security”: [“none”],
in the driver.compose.json file.

Remove the line: “includeSecure”: false,
Add the line: “security”: [“none”],
Test, and let me know :slight_smile:

1 Like

PARTLY solved, Thanks @TagePP for the tip. I created and tested an app that was insprired on the previous Walli workaround. This app will allow you to add other z-wave devices unsecure using your temporary fix. I do not expect Athom to accept this in their store, but it is available in the community store. If you know how to do a CLI install, you can get the source from Github too.

By the way

That is a really stupid recommendation to follow, though I can imagine Athom would want that.

I had the good fortune to have to send Homey in for investigation more than once. Each time Homey was away for more than a week. Also, if Homey dies on you then Homey pro isn’t easy to buy as stock is limited or absent due to the shortages in chips. I was really happy that I could still turn the lights on and off when Homey was not there to execute flows.

So if you do not mind that you cannot control your lights is Homey has problems then: by all means. But if you are like me and you want to prevent the WAF dropping well below zero: go for associations if you can.

1 Like

@Edwin_D That’s why I spend my spare time, trying to figure this out. To be able to use my devices if Homey should have some downtime. But I guess Athom doesn’t see it that way.
I have downloaded the masters of my Homey apps, modified them and installed them on Homey (CLI method).
With your app, that won’t be necessary. But will “Capabilities”: [“onoff”] be overwritten by the “real” device driver. Or will you have problems with other devices?

The UnZ-Cure app should not conflict with any other apps, it doesn’t really do that much. You indeed won’t have to modify existing apps, and my app does not override any capabilities. My app is only very shortly active to kick off the pairing process, after that you can safely disable or remove the app. The original app will handle everything and won’t know the difference. You can also safely update the original app without worries.

Only if you remove the UnZ-Cure app, you will need to re-install it if you add other devices that you want to add unsecure, so I disabled it myself to save resources.

See the FAQ for any other questions you may have:

1 Like

Gotta love the timing. Decided to change from flow to association for controlling a z-dim from a z-push. Set everything up as one would expect, but nothing happened. Started googling, found out it is a known problem with securely added devices. Ok, so I just need to add them insecure. More googling. Oh, that is not possible because of reasons.

But wait, someone made an app to circumvent, nice!

Heads over to GitHub. Realize initial commit was just 8 hours ago, talk about luck!

Anyhow, ran your app, added both z-push and z-dim, and finally association works flawlessly!

To anyone else considering going from flow controlled behavior to association, just do it! The user experience is many times better! Much lower response times, and dimming actually works!

Thanks to the dev :blush: