I See the same issue on some fibaro Smoke Sensor and more rare also on fibaro Pir Sensor.
But Smoke Sensors are clearly the Most.
They are just gone from the Controller.
Only a reset of the Device and new inclusion Helps.
Ghost Devices dont play a role. I removed The…yet the issue happened again.
To early detect this you can Check the „Last Wake up“ to find the affected Devices.
Since fibaro also does reject to Release Firmware Files for 3rd Party gateways I avoid their Products. (To be fair other manufactorers also dont provide those in the Zwave world.)
hmmmm… interesting
I have one fibaro PIR. It was a bear to get included but since seems pretty good. But isn’t a smoke detector supposed to you know… save your life in a fire???
Not so sure I’d be counting on this hardware to ah… save my life
wow
Okay, altogether this does not sound promising to solve.
Maybe one thing to add: I used FHEM prior to Openhab for around 2 years and I never had issues like this with FHEM. I’ve been using Openhab now since Mai 2018 and it was also okay in the first year.
To me it seems that this started with one of the Openhab upgrades during 2019, but I cannot exactly tell when.
Do they also still show up as “online”?
How did you manage to remove the ghosts?
Yes, I set up some rules to check the last temperature report through the influxdb persistence.
there is an explanation somewhere in another thread here.
As long as there is missing communication the device stays offline. Since a battery device could be silent very long its still considered as online. I struggle often with that state.
You can either read the properties and make your own state by reading the last wake up or you could use a “profile”. Take a look at the wiki for items about that ( [profile=“timestamp-update”]).
By that you can have a rule and alert you when there was no communication with a device for a certain timeframe.
with the tool from silabs that was mentioned some posts above aswell.
also possible. or check the “profile” item tag from above.
I just had a talk with the Fibaro Technical Support (Intuitech). The summary is the following:
With Zniffer we found out, that the smoke sensors where completely excluded. Waking up the devices resulted in a broadcast without any node id, meaning the smoke sensors where not included anymore in any controller.
I am using basically the latest Firmware of the Smoke Sensors (3.3). There is a 3.4, but only available through Fibaro Home Center, not available for flashing. “Flashing” means, sending in the device and let it get updated by Intuitech. This also means, they had no “change log” of what’s new in 3.4.
Anyway there are no known issues with the smoke sensors.
So there are 2 reasons why this happens:
The device was reset manually (e.g. accidentally long pressing some buttons (unrealistic for smoke sensors))
The device was excluded (also did not happen)
The device received a reset command over the network
Besides this I tried to remove my ghost devices but without success. Until now I only tried things within Openhab like removing devices and config files. Next step would be to edit the json database.
@shorty707: I also have the tools from Silabs running on my computer and I can add my stick as slave controller. Could you give me a short description or link what buttons to click to remove the ghost devices?
I managed to remove all Ghost devices from my controller using a secondary controller on my Windows machine and the Z-Wave PC Controller which is integrated in the Simplicity Studio.
Since I did this I had no more connection losses to the Fibaro Smoke Sensors or Fibaro Motion Sensors.
@SeeAge I’m still having this issue. About every 3 to 6 months the smoke detectors are loosing the connection. (Also when battery is still fine) Are your devices still connected or did they loose the connection again in the meantime? And did you manage to update the device firmware to version 3.4?
I bought (and later sent back) a Fibaro Home Center Lite and updated all my devices to latest firmware. It was a bit tricky since adding the Home Center as a slave to the existing network worked well, but the devices were of course reporting to node1 and not to the new slave. Sometimes it worked by reading the configuration from Home Center, but sometimes I had to reset the devices. At the end it worked. Unfortunately there was no new firmware for the smoke sensor.
I removed all my “ghost devices” from the controller using the “Z-Wave PC Controller” which is included in Simplicity Studio 4 from Silicon Labs. I guess this helped the most.
I sold all my Fibaro Smoke devices on Ebay and now I am using Ei650RF from Ei Electronics. They are not Z-Wave and of course create their own mesh network, but they are working fine. I added the Ei413 coupling module which sends the fire alarm to a Fibaro Smart Implant which sents the fire alarm to my OpenHab.
Still I am having issues at the moment. From time to time one of the battery devices is not communicating anymore. Yesterday it was a Fibaro Motion Sensor. 2 weeks ago I had the same issue with a Devolo Thermostat. Both devices were not connected to my ZWave network anymore. Pressing a button on the devices started the inclusion sequence which means, the devices did a reset on themselves.
Now, according to the Fibaro support and the Devolo support with whom I had phone calls, this cannot be. The devices will never perform a reset on their own.
This leads to the conclusion that the ZWave controller / OpenHab is sending a reset command through the ZWave network.
This is the only explanation I have left after all this time. Maybe someone with ZWave knowledge should take a second look at the ZWave impementation in OpenHab and check if there is something somewhere which would explain this behavior.
The only other explanation I have it that the ZWave controller hardware has some issues. I am using a 2nd gen. Razberry on the GPIO pins of my Raspberry Pi.
Before OpenHab I was using FHEM and I never had issues like this in FHEM although I also had the Fibaro smoke sensors, motion sensors and the Devolo thermostats here, which points more at my first suggestion that it must be something in the ZWave binding.
Maybe @chris or somebody from the team could take a look
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…
