Zwave Fibaro flood Sensor battery change doesn't reconnect to old Thing

I have a Fibaro FGFS101 Flood Sensor. Every time I have to change the battery on this device, I end up having to create a whole new Thing to get it working. Most of my Zwave devices, when the battery goes dead, I change the battery and a few minutes later, all the linked Items start working again.
I recently changed the battery on this device. Now I have the old device listed in my Things but none of the linked Items update. If I delete the Thing and go to the inbox, run discovery, both the most recent nodes (8 and 9 in this case) pop up as discovered. Node 8 and 9 are duplicates of the same device from last time the battery went dead. If I pick one, it immediately appears in my list of Things, all the previously linked Items are again linked, but none of the Items ever updates. Hope I am explaining this clearly enough.
One thing I notice, Bob always states a correctly linked Thing should have five lines at the bottom of the Thing page, this one only has four

What do you see in the zwave log immediately after you install the new batteries?

There have been scattered reports of battery devices (mostly Fibaro) “losing their minds” from time to time with a dead battery. For a while I tried to run batteries out/low to observe, but never did. It is a lot like watching paint dry.

Anyway, if the five lines on either of the devices do not appear after an awake or two, they are going to need to be deleted using the Silab Simplicity Studio, no way to do with OH.
Z-Wave Zombies.pdf (571.9 KB)
Then try to include as new device (again). You might need to factory reset the device, but try without that step first.

I’ve had some Zooz motion sensors and a HomeSeer leak detector lose their info after the battery died. Same symptoms as above. It’s painful to shut everything down and turn on the Silabs tool and remove the zombies. My limited solution is to set up a battery level rule and when they start getting low, replace them, don’t wait for them to go completely dead.

I’ve never had to do that with any other zwave device. I also own a Fibaro motion sensor and when it dies, I put a battery in it, it comes back to life. No fussing around. I also own two Zooz motion sensors, old school Monoprice Gen1 (made by Zooz) and newer Gen2. I only own a few zwave devices but when they quit working, I’ll usually check them out and the battery will be dead. I pop a new battery in and a few minutes later, they will start updating again. All of my zwave devices have a function. They turn stuff on or whatever. If they stop functioning, I notice because the automation stops functioning.

Thanks for the suggestion Steve. I went to the Zwave binding page, clicked the gear icon, fancy new addition to OH4, ability to change log levels from the UI and… nothing. No logs at all (I got front tail running) I uninstalled the battery, reinstalled it, trigger a few zwave devices… nothing. Not sure if the log level change didn’t work or the binding wasn’t outputting any log entries (which I doubt because as I recall zwave is very chatty in debug mode) Went and looked for a separate log (which I’m almost positive you have to configure to get) Nothing… anyhow set it back to info and moved on.

Thanks Bob, I didn’t want to ping you directly but I was hoping you would see this thread. You have become the resident OH zwave expert and I really appreciate all the times you help users with this technology. Zwave is goofy and you’ve really dug in. I wish Chris would either review your 700 series controller PR or turn the binding over to you. Great job

Anyhow… I went to download SiLab and good news… they have a Linux version now!!! I have a Windoze laptop but didn’t feel like shutting down OH (on my Linux host) to unplug the dongle. Then I saw you have to create a user to download it and laziness got the better of me again so I didn’t bother.

I had twice deleted the non-functioning Thing and rediscover it. Both my old node numbers would pop up in the inbox. Neither would function. So then I found the documentation for the device, figured out the exclude sequence, put the controller into exclude mode and triggered the button. Nothing seemed to happen but then went to the inbox, ran discovery and voila! Fibaro flood sensor pops up with a new node number. Create a new Thing, it immediately had five lines at the bottom of the Thing page, linked old items to new Thing and they immediately start to update.

So… zombie nodes… :scream_cat:
I have a very small zwave network, 7 nodes total not including the controller. I have a dead node (the monoprice mentioned above that absolutely eats AAA batteries no matter how the settings are set) and the node left over from the last time the Fibaro flood sensor died, and have never had a problem with zombie nodes slowing the system. I’ve given the zombie advice to many users myself but have never had the problem myself. I guess because the network is so small. Anyhow… my flood sensor is back to life, we’ll see if the zombies cause problems. Thanks everybody who helped.

Oh, meant to mention, I have two Fibaro devices, consider them over-priced, but they work (other then the above problem with the flood sensor) I’ve ran both down to completely dead and never observed such behavior. One thing I have noticed about the motion sensor is it reports 100% battery right up until it dies. I’m almost certain the battery is pooping out right now and battery level reports 100% :upside_down_face:


:grinning: zombie battery nodes will not cause any issues. They aren’t involved in routing. For a type A personality they are just hard to look at everyday.

Thanks for the thoughts, but I don’t have the Java chops to maintain the binding. Actually I’m testing zwave-js-ui with OH. It is a zwave to Mqtt solution with lots of features including zombie removal. There are some quirks, but it is promising IMO (at least for me).

1 Like

good to know, I actually only have battery operated nodes, that explains why I’ve never had issues. My network is small both in node count and physical distance (tiny 1 bedroom flat)

Sounds interesting, share when you know more. mean while I’ll google

Sorry, ain’t buying that
We got guys like Jan, Wouter and Łukasz who will help you if you run afoul and Chris is over the fence :slightly_smiling_face:

I was curious to see what, if any, messages were sent from the device after the battery change.

I’m still on OH3 but this is what I had to add to my log4j2.xml to get Zwave debug logging:


		<!-- Z-Wave -->
		<RollingRandomAccessFile append="true" fileName="${sys:openhab.logdir}/zwave.log" filePattern="${sys:openhab.logdir}/zwave.log.%i" immediateFlush="true" name="ZWAVE">
						<Pattern>%d{yyyy-MM-dd HH:mm:ss.SSS} [%-5.5p] [%-50.50c] - %m%n</Pattern>
						<SizeBasedTriggeringPolicy size="10 MB"/>
				<DefaultRolloverStrategy max="4"/>


		<!-- ZWAVE -->
		<Logger additivity="false" level="DEBUG" name="org.openhab.binding.zwave">
				<AppenderRef ref="ZWAVE"/>

Alternatively, Vesternet are having a summer sale at the moment so if you’re in the UK you could maybe get one of these for £25 if you get bored of including the device again and again :slight_smile:

I am not, I’m on the other side of the pond in the US of A but the price is certainly right! I have another water leak sensor I purchased at the same time, runs on Zigbee, has a coin cell watch battery, no longer available, was $19 usd. It came with an almost died battery but I replaced the battery and it’s going strong two years later. This one seems to be the exact same sensor. I have a Nortek HUSBZ dongle that does both zwave and Zigbee

One piece of unsolicited feedback :wink:. If you haven’t already; disable the network heal, you can safely do so with all battery devices. There is no mesh to ‘heal’. That will keep the battery device awake duration as short as possible and save battery life. One second of awake is about equal to 10 hours of asleep. I also use 86400 for the wake interval.

I see a similar behavior on one of my motion sensors from Aeotec. Devcie forgot everything after attery change. For me it looks like it is a firmware problem on the device. Other same devices with diffferent firmware do not show this.
In another post there is a hint to include in non secure mode. I made this for that specific device and fixed the problem.

yeah, heal has been disabled on my system since forever
To me, it borders on completely senseless (unless nodes get physically moved around) to have a scheduled heal and it has caused problems at times (for other folks) as long as I’ve been using zwave (2018) and hanging out in this forum

1 Like

After seeing how much additional traffic a securely included zwave device generates (if I recall correctly about x4 or x5) my strong advice to folks is only securely include things that require security (such as door locks). I’ve seen systems with a lot of nodes get real slow and re-including everything but door locks in un-secure mode cured the problem.

Well I’ll be darned. I just replaced the battery on this device and it started working again with no fussing. That is the good news. Bad news is the battery had date on it of May this year so 6 months. Funny thing is, 6 months ago when I installed it, it only ever report 60% battery. This time reporting 100%. Same batteries out of same package in the drawer