To avoid getting spanked by the developer for an older post…
That algorithm/code does not reset/remove the node. It simply marks the node as dead, so no more messages will be sent to it. It also clearly shows up on the UI as Dead/offline, so it is easy to spot. If the controller later gets a message, say if a new battery is installed, it will come back like nothing ever happened. I have had an occasional dead node and they have always come back without re-inclusion, so have personally not experienced what you describe.
Second point that I have learned since that post in Feb is that only Z-wave plus devices will “figure it out on their own”. Since all my battery nodes are z-wave plus, I still disable the daily heal, mostly for battery life (See below). Instead I use a zniffer and occasionally review routings and may “heal” an individual node that I think has lost its way.
Lastly (IMO) I lean towards the battery being the cause of the problems described in this and other posts and it seems some manufacturers are more prone than others. In a network of my size a battery node takes about 11 seconds to heal. Using this guide somewhat liberally, an 11 second Heal uses as much battery as 4.5 days sleeping. The heal could drain the battery before another report shows the battery as dead. Could be wrong since I haven’t had the problem, but I’m happy with my battery device battery life.
hey Bob, lets avoid spanking all together
i am not sure what you describe is actually my experience either.
for example battery devices that go offline (no battery) stay online for me for ever in openhab. It would indeed be logical that if there is an X period of no messages after X wake up periods then it should be offline. but my devices at least dont do that.
how do you disable self heal by the way?
last - i did a check with the aeon stick gen 5 yesterday. my aeon door sensor (node 52) is connected but transmitting nothing. it appears that the controller doesnt talk to the battery device anymore. My guess is that for whatever reason the device is self disconneting or told to from the controller and therefore can no longer send anything. (this is the same as my thermostat) - battery dies/replace battery - device is no longer connnected to controller on the side of the device and the controller has it connected but no traffic. Openhab shows online and date from 4 weeks ago.
for me it is clear that this is a binding bug or something very much beyond me. my previous vera device didnt loose the connections to the battery devices.
I still have the same issues like before. Just last week, my Fibaro motion sensor was from one day to the next day not communicating with OpenHab anymore. In this case, I realized it immediately, since it was directly connected to a Fibaro switch to toggle the light without the controller via associations. This means, it did not just disconnect from the controller. The device was reset for sure.
Every time I have these kind of issues and it happens still frequently,
the device is still shown as “Online” in OpenHAB.
there is no communication anymore, even if I press the wake up button in the device.
changing the battery does not help
I have to reinclude the device and the old device will stay as a ghost device
and most important: If I press the wake up button three times, the devices goes directly into inclusion, not in exclusion, and a new node is added. I have no chance to exclude the old device.
The device for sure was reset somehow. Maybe by itself, maybe by some bug in OpenHAB, maybe by some corrupt message.
To get a battery device to show offline is rare because they are sleeping most of the time (and dead and sleeping look the same (if nothing is triggering the sensor). The “dead” routine noted above is based on polling and wakeup interval, but if a device is not fully configured, there is no polling, hence no marking as dead is possible. Besides during initial inclusion, a battery device is not fully configured after an OH restart, a binding reinitialization or if a heal has been requested. The quickest way to tell if a device is fully initialized is when there are five lines on the UI page. If not, the device will be shown ONLINE forever. Another way to check initialization is if the node XML in the zwave folder is time stamped after the controller XML
That is on the Controller UI page near the bottom.
Pure speculation, but if the battery dies during an active awake period (35000x more power being used), it seems akin to when SD card corruption happens with a sudden power outage on a Rpi. I do not believe it is binding or OH related and does seem to be reported with Fibaro (but not always). I get and time stamp a daily battery reading and replace the battery at the first sign of trouble. The Li ion 3v batteries go fast once they drop below 100%.
Apella12 I am not sure about the 5 items thing. for example. when i restart openhab I have 4 lines but after a while (i guess after wakeups) it shows “reinitialise the device”. this didnt appear just after restart. it would suggest that initiliazation is made available after a confirmed wake up. So it stands to reason that it should trun to offline when it isnt woken up for a while (which isnt happening). basically the 5 lines are the result of wakeup not the indication (only) of full initiliaztion. MAkes sense?
This makes sense. The device awoke after a restart and was reinitialized.
Keep in mind the device sends the wakeup, but if 5 lines are there and the device is dead, I agree it should be marked as such. The problem would be if the device dies during a heal, there will only be 4 lines (not fully initialized- heal did not finish) and will not get marked as Dead.
I have the same issue with Fibaro Smoke Sensor as well. After random long time it stops wokring. As an example I can see on all my other devices (mains power) that “last heal” was performed last night while the Fibaro Smoke Sensor says 28 December (probably when it disconnected from Z-wave).
However in OpenHAB the smoke sensor is listed as online but no updates are sent when I trigger tamper etc (and yes, parameter 2 is set to send those).
Last time this happened I removed the battery and followed procedure to change battery. The smoke sensor indicated that it was NOT connected to any Z-wave network…
