All of mine are non-secure, it was the same on hubitat as well. I think everyone having issues is on the ZwaveJS (Zwavejs2mqtt) implementation but if someone is not please correct me. I don’t know if the old open zwave implementation supports associations but I’m tempted setup a single instance to see if this can be duplicated there.
1 Like
Every single device is unsecured. I have 5 devices on my network that use S0, but none are bulbs.
All devices in this association use no security.
Agreed, and mine had been working for over a year in their current config before this random issue started a few weeks ago.
2 Likes
My two are non secure as well, but I am also not using ZwaveJS and instead using OpenHAB so the issue is definitely not limited to ZwaveJS
2 Likes
What Z-Stick are you using? I am using an Aeotec 5. But, I’ve used it with Hubitat in the past and don’t recall this issue happening back then. Wish I could remember when it started.
Just chiming in to say I’ve successfully gotten associations to work (and tested the crap out of them) on both the Hubitat C7 and SmartThings over the weekend and they seem to be working fine.
Not sure if it helps this thread at all, but I wanted to at least give some info around other hubs.
In both cases, I had one Red Series Dimmer and three Ilumin bulbs on the 2.31 firmware – all with no security.
FYI I also have my setup working now, but it breaks again whenever I heal the network. I havent setup zniffer yet to get more data. After healing when I factory reset it seems to work indefinitely.
Im using the Zooz 700 series stick
I’m also using an Aeotec 5, I originally had the older non-usb3 compatible model and now have the newer revision as of a few months ago instead. The weird thing is that some days it works great and some days I get the intermittent single bulb not working correct. It also seems that my older red series seems to exhibit the behavior more than one of the later ones I bought but that was only with brief testing so it may or may not be a factor since both switches are on the same firmware and may just be testing bias.
All of mine are non-secure as well.
I believe this is strictly related to zwave-js. I had this exact association setup on Hubitat and it worked perfect. It wasn’t until I moved to zwave-js that I started seeing this behavior.
Another Zooz 700 stick user here.
I don’t think it is strictly a zwave-js issue though since i’m using OpenHAB that has it’s own interface for zwave and I have the same issues. I also notice the same behavior without my zwave stick even plugged in, although the lights respond via association MUCH (as in seconds) slower in that case for some reason which is odd because I would think the point of association would be to work independent of the controller.
Just to add some further data. I have 4 total associations in my home. 1 switch with 2 bulbs that has the same issues as others in this thread. 2 are separate ones that control groups of switches and I don’t have any issue there. The 4th controls 4 bulbs and 1 Inovelli led strip and no issues there either. Only issue exists on a red dimmer with 2 bulbs combination…
Yup. I had this same stick on my prior Hubitat install. Don’t recall seeing this issue present there. I can DM more info to you.
So, I’ve been able to do a little more digging into this.
Strangely, the bulb sends a report back to my hub and says it’s off, but the light remains on.
So, is there somewhere on the firmware that parses an off or basic set, changes the variable, transmits it, and then misses the actual led change part of it? Seems super strange.
I’ll also note — I have 5-15 non-Inovelli Z-Wave lights associated, and I’ve never seen them exhibit this issue. It definitely seems related to the LZW42.
Edit: Just wanted to say, this can happen for both on and off events. Not just off.
Another behavior: the light won’t turn off, doesn’t report a status change to being off, and doesn’t report to any basic set/z-wave commands until you turn it on. It’s like the bulb thinks it’s off or on, and refuses to change state.
This is still a persistent issue for me on ZJS2M and Home Assistant.
I finally upgraded switch firmware a couple of weeks ago and while I was using PC controller with my Nortek stick I deleted and recreated the association using that software and had no issues recreating the issue. I still have some of the bulbs from the first ever batch that have the first firmware on them, I’m going to try replacing in my bedroom where this is occurring. I don’t recall having this issue prior to upgrading.
I have had this issue for a long time
What seems to help for me is to unscrew all the bulbs, perform a network heal, then once the heal is complete screw the bulbs back in.
Wait — did associating via the controller software fix it? If so, I might give that a whirl, one room at a time.
Has this been a permanent fix for you? Wonder why it’s happening…