I have two of these devices working without any problems.
When the battery is gone they of course do no longer communicate with the controller.
Normally you should just replace battery and wake up the device a few times.
Worst is to add the device again with a new ID, so you have several (old) “ghost” devices remaining on the controller which will for sure cause troubles in your network …
I would delete Thing (NOT Exclude from the Network) and then rediscover it.
Thanks for your input.
I personally think the probability of a true alarm is quite low and if you are at home, the siren will inform you. If you are not at home, it might be of help but would you call the fire department if you are not sure if it is not a false alarm? I had 4-5 false alarms in the past 3 years where I needed to reduce the sensitivity in the end and no real alarm.
The best thing for me would be if it sends me a notification before the battery is empty. At the moment the devices typically loose their connection before they are empty and of course the batteries are typically empty during the night (Murphy’s law) waking me up with the beep every 60 seconds and you are sneaking through the house waiting for the next beep to determine the direction you need to head 
This actually does not help, the device is always displayed as online. If I delete the thing it will be rediscovered immediately without any change in communication behavior (still not communicating).
Is this really an issue? Maybe this is the actual problem here. I never managed to completely remove those devices since they are still showing as online.
I have in sum 18 of these “ghost” devices (only ZWave battery devices, Fibaro Motion and Smoke sensors). Altogether I have 84 active ZWave devices.
Just to mention, I never had issues with my Devolo ZWave battery devices. Only Fibaro.
Sad though, I think I will call Fibaro on Monday. I have spent a lot of money into Fibaro products since they are really compact and also really good except this issue of course. So maybe the will help me…
yes, I believe this could cause problems.
Do you use Habmin? (it is a user interface) it has some zwave options that may help you to remove these ghost devices. If that does not help, search this forum for ‘PC controller software’
edit to add: the PC controller software is Windows only so you must have a Windows PC to use it
Yes, I have Habmin and PaperUI. I typically use PaperUI for everything except excluding zwave things. Here I am using Habmin (just a habit). What would be the steps to remove a ghost device? As far as I remember, removing it didn’t really work since the device is still online and it has to be offline / failed so that it can be removed?
I searched a bit but I am not sure what you mean. Can you point me to something?
I have a Razberry ZWave Stick on my Raspberry Pi 4. I ordered a AeonLabs USB Zwave Stick now for my Windows PC. Let’s see what we can do with this then.
Maybe I will switch from my Razberry to the AeonLabs USB Stick since it has some nice features (battery, backup…), but reincluding >80 devices takes me several days.
here is a link, you need to create an account (free)
@robmac Rob knows this software really well and has some tutorials but can’t find link real quick
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.
It will still do the loud beeping though. 
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.
Hi once more,
I just had a talk with the Fibaro Technical Support (Intuitech). The summary is the following:
So there are 2 reasons why this happens:
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?
Hey guys,
I just want to update the case.
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.
BR,
Christian
@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?
Hi,
I did several things:
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 
Thanks a lot,
Christian
Or the firmware is responding incorrectly / non-standard to some standard Z-Wave signal / command.
I am not saying there may not be binding issues, but, with all the variety of devices from various brands, firmware may very well be the culprit.
The binding does not do this.
Hi got the same issue for a year now, did u ever figure it out;
For me it is an SRT thermostat and a aeon door window sensor.
Thanks!
Hi Chris, apologies for the obvious point here but doesnt this post imply it does send a reset/remove the device automatically from the network?
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.