I just turned on debug logging, so I’ll post log later but figured i’d run this by everyone:
I doubt its openhab…it would surprise me if it was.
I changed out 3 sets of batteries yesterday(2 multisensors and 1 door contact).
After that, all night, at random, random lights and smart plugs turned on and kept waking me up.
Usually it was the same lights and smart meters, but sometimes it was different ones.
What could cause this in a zwave network?
Thanks
Hello!
Is your OH instance accessible from the internet (via port forwarding)? Maybe it’s “hacker” attack, rather then z-wave network problem.
Best regards,
Davor
Hi Davor
It is, but its password protected with nginx.
I think i have it nailed down to one of the multisensors i changed the batteries out in last night.
I removed the batteries from it and it seems to have stopped.
Which begs the questions:
Old X10 RF sensors lost settings when batteries were changed, so default config sometimes triggered unexpected devices.
Z-Wave devices tend to have local permanent memory to store settings, with both the controller and OpenHAB databases maintaining addresses/ thing/ item names.
Does your OpenHAB event log show sensors turning devices on, either via a confused rule or perhaps via an association group?
The obvious thing to do would be to enable debug logging, trigger the sensors (not just motion/ door, but also other channels like temp, light, tamper, etc) and see what happens.
If you find something, what happens if you stop OpenHAB? e.g. is the sensor associated directly with the device, or is there a bad rule?
I’ve personally avoided device to device direct scene / association group config as it seems all too hard! Instead, rules get events from channels and trigger my own code (which hopefully is more understandable… or at least can be debugged with LogInfo / LogDebug calls).
Try looking in HABmin -> Config -> Thing -> -> Association Groups.
My Fibaro multisensors don’t have any association groups set, but I think there’s a default lifeline to controller link for status updates.
Oh i avoid direct to direct as well.
All my my stuff is done though openhab…and has been until i changed the batteries.
I shut down openhab and waiting…lights still went on…which means somehow a sensor directly associated with my lights…many of them…and I have no idea how…all i did was change the batteries.
Hi,
That does sound very annoying!
For reference what sensor kit are you using? (guessing Fibaro or Aeotec)
I’ve changed the batteries in my Fibaro Multisensors (FGMS001 on OpenHAB 2) a few times without issue. They do flatten a battery in 6 months making the Aeotec kit with its mains power option attractive.
A search shows a few issues with multi-sensors, but they look to be more about changes in the Z-Wave binding in OH2 to better support the full range of channels than associations.
It’s a bit of a nasty hack (like rebooting Windows for the 15th time!), but I guess if HABmin doesn’t show any Association Groups to remove, you might consider a factory reset of the sensor. This will need a new pairing with the Z-Wave controller, and the old Thing/ Channel manually removed, but the old item names can be linked back without changing rules.
I’m using aeotech for the sensor and the smart power switches, linearlinc bulbs. My batteries die on a monthly basis…i’ve never been able to dial them in and figure out why.
I only associate the controller (aeotech zstick) with the sensors.
What i plan on doing is unincluding it from the stick, resetting the sensor and reincluding it again.
Monthly battery changes seems rather excessive!
With Fibaro, there are settings to increase the time between sensor updates - e.g. only report temperature / light level every 15 or 30 minutes, increasing battery life. Motion will still wake the device up and report immediately.
I suspect some commercial controller software includes code to change poor factory default configuration parameter choices (e.g. motion sensors that don’t actually report motion…).
Tell me about it!
I’ve configured mine to report every 6 hours…i think the amount of motion detection is killing them.
I have them outside in front of my house and the get set off by the breeze blowing things…even tried adjusting sensitivity.
I might try to play around with using those usb solar battery packs one day
At the risk of two nasty hacks in one thread - I’ve calmed other over sensitive PIRs with a few layers of tape or plastic to partially block the IR (such as reflected sunlight).
Silly question - are you using the same power source as when the Aeotech devices were first included into the Z-Wave network?
Some discussion threads (definitely worth a search) suggest including a Aeotec unit when on USB power configures it as mains powered (e.g. higher current drain acting as a router, repeating RF traffic). The fix is to exclude it, power it from batteries only, then include it again.
Sadly this suggests an external USB battery pack (e.g. a pack of 4x D cells wired to a USB cable) could be counter-productive
I’ve always included them with batteries; interesting though, looks like this has a checkmark next to routing; is there a way to turn that off?
Ummm - why would you want to do that? It’s a mesh network right - you want it to use routing I think.
In any case, the answer is no - you can’t disable it.
Figured a battery device would be a “bad router” in that it would waste energy routing if it woke up and something asked it to transmit…would be nice to be able to designate routers within zwave and disable it on battery devices; i have enough plugged in devices to handle the mesh network
A battery device doesn’t route at all - that’s not possible if it’s not listening. The routing flag means that the device is able to route - without it the device would need to directly communicate with the controller.
All devices supporting routing that are permanently should be used within the mesh - this is all handled by the controller, so there’s nothing we could do even if you wanted to change this for some reason.
As above - battery devices won’t perform routing - they only route their own messages.
