Lights turning on and off from sensor despite controller being unplugged!

I’m hoping to find some help here before I wipe my Z-Wave network and start from scratch as I have a lot of devices.

My current setup:

  • HASS 0.45 running on Ubuntu server 16.04.2 (HASS version outdated due to another issue with pip…)
  • Aeotec Z-Stick Gen 5

Zwave devices acting oddly:

So the other day I was doing my occasional maintenance on my HASS setup which involves updating the Ubuntu system libs, updating HASS, and rebooting, and after doing so I began noticing some very suspicious behavior out of my Z-Wave network.

[As an aside, the HASS update command (pip3 install --upgrade homeassistant) executes fine but the HASS instance does not get upgraded after multiple reboots].

Ever since then ALL of my Z-wave dimmers/switches have been getting triggered by any of my four Z-Wave sensor’s state changes. I open my closet door, every light in the house comes on. Close the closet door, they all go off. (My neighbors must think we are nuts cause the outdoor lights come on too :P). There is a significant delay between the lights being triggered and the door opening, which was not present prior to this issue.

What I have tried:

  • Rebooting server
  • Rebooting HASS
  • Updating HASS (does not stick as mentioned before)
  • Unplugging Z-Stick (issue persists with stick unplugged).
  • Rebooting controller via OZWCP (I can’t make sense of the logs, but can post them if needed).

I thought sibling node control was impossible? Can Z-wave nodes directly alter states of other nodes without a controller? The Aeotec Z-stick does have a built in battery, but I was under the impression that it would not function as a primary controller while unplugged, only as a secondary for node inclusions. All of my automations are via HASS, and since it is unplugged, the device does not exist in /dev/ttyACM0 any longer, so HASS shouldn’t be able to execute the actions. Irrelevant anyways as the issue also persists with both the controller unplugged and the HASS instance (along with the server itself) turned off.

Does anyone have any suggestions? I’m hesitant to completely wipe my Z-Wave network but if I can’t find a solution, I think I might have to…

Absolutely - ZWave was originally designed for simple associations like switches directly setting scenes for lights etc. A controller is not necessary for that kind of activity.

The question is though, why have your sensors become associated with your devices in that way, and I am afraid I don’t know the answer to that :frowning:

Maybe just start with clearing all associations with one sensor or remove/readd that sensor and see if that stops all lights from turning on. I’m guess you probably dont need to blow everything away if its just the senors triggering the lights and everything else is fine…

Also I would turn hass off and see if the the sensor still triggers the lights. If so its a zwave association. If not its probably some faulty automation in hass.

Yeah I did try that already. The issue persists with HASS offline and the Z-Stick unplugged.

Good idea to do one sensor only! I will try that and get back.

How are Z-Wave assocations created in the first place? I’ve never heard of them, and hadn’t made any changes to my setup when the issue started occuring. Odd…

Usually you have to manually establish the association using software or some sequence with the device itself. Like @aimc mentioned this was the inital idea behind them. A person without a hub can have lightswitch1 trigger lightswitch2 directly. Each manufacturer that supports it, though, can implement the pairing however they want.

How it happened with yours I have no idea…

Small info blurb:

FYI to future readers, what ended up fixing it for me was to exclude all the switches and dimmers being effected and re-including them into the Z Wave network.

1 Like

Thanks for this post. I have currently the absolut same issue. First I thought is is a Hassio miss configuration.
Butt hassio withouth inserted the USB Z-Wave Controller stick: same issue. Even if the Raspberry with hassio (0.82.1) has no power. -> I will try to remove and add all Z-Wave devices.

You should be able to remove the association from the Zwave configuration menu without removing and adding. If there are battery powered devices, you will need to wake them to make changes.

1 Like

I did a factory reset on my Zwave (controller, network key, HA) and added my nodes to the ‘new’ network.
Since then, no issue. But a lot of work. I had to open all my wall switches…

@mischoe sorry you had t go through that. Far too much work that didn’t need to be done. Creating and removing associations is a trivial thing through the menu. Hope things are better from now on.

This started happening to me this evening. It’s strange that it’s starting to happen to multiple people. I can’t say I’ve ever setup an association so something must be getting corrupted. I’m don’t think it’s an HA issue, but I’m wondering if it’s something that can be at least identified and maybe fixed programatically.

1 Like

This just happened to me after restarting HASS! What’s really strange, is that this “effect” seemed to be applied instantly to several multisensors, which should not be possible as they would need to wake up first. Also, HomeID was shown as 0 in the logs and no Z-Wave devices appeared in the config section. After next restart, my devices were back in Home Assistant, but still turned on by the multisensors. I can’t see any strange associations on the multisensors.

1 Like

I also had the issue after a reboot last week. All 3 of my Fibaro FGMS-001 got associated to broadcast group 255.

There is instruction is the documentation https://www.home-assistant.io/docs/z-wave/control-panel/#broadcast-group that is supposed to fix this issue. That didn’t worked for me, but you should try.

In last resort, I ended up factory resetting the sensors and now I cannot even add them back to HA. I love HA, but I’m very frustrated with Zwave ever since the node renaming feature was removed a few months ago.

Thank you for the link! I got it working by making a small appdaemon app, looping through all nodes and removing node 255 from their association. No idea how it happened, though.

When it happened to me I had to go through each zwave device using the zwave configuration screen and clear any associations to 255. It was a real pain in the backside.

can you post a copy of that code, or put it out on github and provide a link. That would probably be helpful for others if they have this problem.

Sure. It was just a quick and dirty loop trying to remove all associations.

for i in range(1,128):
  for j in range(1, 10):
    try:
      self.log("Removing association {} from {}".format(j, i))
      self.call_service("zwave/change_association", association = "remove", node_id = i, target_node_id = 255, group = j)
    except:
      self.log("error")

thanks for sharing but where does this code go? or how do you implement it

In an appdaemon app. If you don’t have this set up, it’s probably easier to remove manually on problematic devices.

I have manually but it keeps coming back…
Any ideas on how to keep that from happening. I have 16 zwave devices setup, spread across light dimmers, lights switch, smart plugs, battery door contacts, motion sensors. It seams like I have to keep remove it from the Leviton dimmers, the Leviton outlet plug along with the Aeotec smart plug and the ZooZ motion sensor