The device is battery powered. Have you manually woken it up so that it can complete initialization?
1 Like
No, it’s dc powered so it’s not about wake up
If that is a device that can be powered either way, it must be dc powered when included into the Z-Wave network. Otherwise it behaves as if battery powered,
If it is normally battery powered & you connected it to a DC power source, it will still behave as a battery powered device.
2 Likes
… and the fact that you have a Channel named Battery Level (from the pic) is a definite sign that there is a battery!
2 Likes
the sensor can be powered OR via battery OR via dc. i only use dc, both during network inclusion and normal operation. other devices allow this: aeotec multisensor 6, for instance. when inclusion is made, battery channel appear even if device is dc powered, it’s default behaviour. Also: the same device (FGFS-001) but with 3.2 firmware version works perfectly, and it has battery+dc too. i’m sure it’s about firmware. next week i’ll get a new aeotec z-stick+ , i hope something will change but i don’t think so
If it is firmware on the device a new stick would not help. 
don’t know what to do. I k is you’re right because if I use zwave2mqtt to manage the network, device is recognised correctly.
That is either openzwave ot Home Assistant based off openzwave. A totally different system.
ok. on next monday i’ll try to investigate if fibaro can help us
Given that the binding is retrieving the manufacturer information, and given that this information is in the database, it seems likely that you are running an old binding. I appreciate that you’ve said above that you’re running the latest, but please double check this as it is by far the most likely explanation.
Double check in the console that you only have 1 zwave binding running, and it is the absolute latest version.
The manufacturer will clearly not be able to help you here.
hi Chris! i’m absolutely sure about the binding version. i’m performing these test on two different OH2.5.10, one of them started from scratch + a testing OH3M5. tested also with 2 different aeotec zstick.
To be absolutely sure you should check karaf:
openhab> list -s | grep zwave
271 x Active x 80 x 2.5.11.202012091800 x org.openhab.binding.zwave
1 Like
i’ll do it on next monday 
So you are not using the latest snapshot then? I’m not sure if it matters, but at least we understand what version you have.
no, no. for production i use stable release, no snapshot. i mentioned oh3 only for testing purpouses
So I have confirmed that if you are using 2.5.10, then it will not work as it was not in the database. Please ensure you are using the latest snapshot version.
1 Like
Ok, then sorry, but it will not work for you. You will need to use the 2.5.11-SNAPSHOT version.
ok, so i will try with that version. so i’ll stop OH -> put the jar into the addons -> check owner -> clean-cache -> start OH. Right?
The best thing is to use the script -:
Otherwise you need to uninstall the existing binding and make sure it is really removed, then install the snapshot and start it.
1 Like
Finally i did it!
- this morning openhab updated from 2.5.10 to 2.5.11 via apt-get
- uninstalled zwave from paperui
- uninstalled openhab2-addons
- used the script linked by Chris. it didn’t worked: downloaded org.apache.servicemix.bundles.xstream-1.4.7_1 + zwave addons version 2.5.12 shapshot but (after cleaning cache and restart oh 2 times) no zwave addon installed (no serial transport feature installed)
- removed org.apache.servicemix.bundles.xstream-1.4.7_1
- from karaf -> feature:install openhab-transport-serial
- openhab correctly installed zwave 2.5.12 snapshot
- removed and added again my thing (flood sensor) from paperui
- FINALLY DEVICE COMMUNICATES CORRECTLY!!!
- tried to uninstall snapshot addon and install 2.5.11 release addon
- removed and added again my thing (flood sensor) from paperui
- devices continue to work correctly
Thank you all so much!!!