I am using several Fibaro smoke sensors (FGSD-002) around the house as well as Fibaro motion sensors (battery devices). Today it happened the third time that some of the devices do not communicate with OpenHab anymore. I typically realize this when one of the devices starts beeping because of low battery.
The picture is always the same:
Some devices are still communicating, some not
The devices are still displayed as online in OpenHab
I cannot exclude the devices from OpenHab anymore
When pressing the wake up button on the device, OpenHab does not receive anything
It is not all of them, only some, and I cannot see a pattern. Most of the time is only the smoke sensor devices, but it also happened for some of the motion sensor devices at least once.
To recover I add the device again to OpenHab and edit my items files to the new node id. There is no reset on the device required, therefore I assume it has no controller anymore?
I am not sure what causes this, maybe a reboot of my Openhabian, maybe a system upgrade or maybe only when the power is lost on the ZWave controller (I sometimes perform a backup (image) of my flash disk).
Did someone found a solution meanwhile?
Is there a better procedure to recover the connections instead of re-adding them?
Hi Christian, I also still have this problem with my Fibaro smoke sensors and I also have to reset them every time they loose the controller. I never found out what is causing this problem. I guess the smoke sensors have some hidden secrets that are just not documented and I also guess they would be running fine with the official Fibaro controller. For instance there is some sort of internal History that is collected by the device, but there is no documentation how to access this information. Also the firmware of the device can be updated but also only with the official controller. So this could simply be a bug in the firmware that I cannot fix because there is no official tool for the Aeotec ZWave controller to update the firmware.
Currently Iām looking for a much simpler and cheaper alternative to replace those smoke sensors. My idea is to modify a standard smoke detector that cost about 15$ with a simple circuit that does not use any power until smoke is detected. Then the circuit will turn on an ESP8266 that sends a message to OpenHab via WiFi or a via LoRa (or both). The smoke alert is the only thing of interest to me on those smoke detectors. Also without the constant ZWave communication the battery should last longer and the final solution would only cost about 20 to 25$.
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 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.
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
