first of all: I’ve googled and also searched here, but I couldn’t find a solution. If one of you finds a link to a topic where this problem has been solved, please post it.
Second: I’m a beginner, so please don’t kill me if it’s kind of a simple thing for you pro’s.
I run a Ubuntu 20.04 system with OpenHAB3 (not openhabian).
Z-Wave Bindings are installed.
Z-wave Controller is the Z-wave.eu Dongle UZB* and included as Thing.
I have several z-wave battery devices such as Popp solar outdoor siren II, and two Abus smoke sensors.
These devices are also included as things and online and the most channels (included as item) are working (switch to turn on siren / status of smokesensor).
The problem is, that the battery levels show only 100% (Siren) or NULL(smoke sensors) and are not changing even if the solar siren runs out of power.
Interesting enough
There are also Philips hue sensors with battery where I discover the same issue. And hue is not a z-wave but a special zigbee standard.
If tried to link an item to the channels as number, as number with dimension (energy, voltage, you name it) even as point and some others. Nothing seems to work.
My conclusion is, that I’ve done something basically wrong as both systems do not show correct values.
It would be great to get a step by step how to.
If you need screenshots or protocols or something please tell me also where I can find for example the protocols. Keep in mind, I’m new to this stuff.
I can help myself a bit with linux shell (ubuntu terminal).
Sorry - I’ve not seen this report previously (this was reported when I moved to NZ from the UK so I guess I missed this). It is working ok here so please can you provide a log and also advise what sensors this is a problem with.
Ah ok, I will collect some logging tomorrow, with any specific log level?
I use 3x the indoor Philips Hue Motion sensor. All 3 of them reporting 100% battery levels what can’t be true because 1 for sure is running over 1 year already.
I tried it by making the battery item in a .items file and also via the gui but both act the same, constant 100% level without any change.
I missed the reference to Philips Hue here and just noted the ZWave issue. Really - these are two separate bindings, so there can’t really be a single bug here. My guess is there is something else going on if you have issues on different devices with different bindings - or there are at least multiple problems.
I still have the same problem.
I need to add, that I have these issues not only with z-wave devices but also with Philips Hue.
I discovered that when re-implementing a z-wave device, sometimes I get a battery level that is different to 100% and sometimes, I don’t. When I get a smaaler percentage to 100% it stays like this for EVER and never changes.
But as z-wave is far from beeing reliable and is not developed or updated in a userfriendly way, you need to accept… it seems.
My way to find out a low battery level: If I don’t get any numbers from my temp sensor anymore, that bat seems to be empty!
Same for my fire sensors! If the flames are bursting through my bedroom and I haven’t been warned, I will have to change battery!
Sometimes it is soooo simple!
Related to the 100% observation: I’m not a battery expert, but lithium-ion batteries hold their voltage then die very quickly. (and voltage is what the 100% refers- not some measure of remaining ions). I had one device recently that was at 100% for a long time, then in one day 70% and the next 20% and dead. My battery tools also (drill, etc.) also exhibit this behavior.
What I have set up (and there are other ways to do this) is to link a date-time item (timestamp on update) to the battery channel and then have a page with the batteries % and date so I know the reading (100%) is recent;
Related to the NULL observation I can only relay my zwave experiences, in that NULL means the device is not fully initialized. (could also be that a “heal” is not complete or OH3 was recented restarted. Polling (i.e. getting the battery level via a binding request during a wakeup period) doesn’t happen if the device is not fully initialized. The quick check for a zwave device is if “reinitialize device” is one of the five lines on the UI page for the device.
That may, or may no be correct. A device may implement a direct reading of voltage to percent, but it doesn’t need to, and many devices these days use “proper” fuel gauging - so they account for the amount of power consumed.
It is also possible to use the battery voltage graph and reasonably accurately correlate this to percent since it does drop reasonably linearly through a large part of the discharge (just not at the beginning and end). In the commercial devices I build, I use a lookup table that removes any non-linearity and does a reasonable job of translating voltage to percent remaining.
Of course, it’s also completely possible to make a hash of this, and read 100% until it goes to 0% - it’s dependant on the implementation. I just wanted to say that it isn’t necessarily the battery voltage that is used - in zigbee at least there is a completely separate attribute used to read voltage, and the percent attribute is clearly stated as being “battery life”.
I’ll defer to your expertise, but I do see Li-ion batteries provide power (maybe the device voltage calculation is not precise to show a capacity decline?) until they suddenly don’t. On the other hand my alkaline device (3xAA) is all over the map. This is reported by the device in September on a single set of alkaline batteries.
Again, anything can be implemented badly, and there are for sure plenty of bad implementations out there, so I’m not arguing with you there .
My point was just your statement that “voltage is what the 100% refers- not some measure of remaining ions” - and this is not necessarily correct. Devices should, and many do, implement something that is a close analog of the “remaining ions” (or energy) stored in the battery.
Unless a device uses a real “fuel gauge” that measures the amount of energy taken out of (and potentially put in to) a battery, and provides a percentage remaining based on this, it will likely use voltage. This can be reasonably good, but voltage does vary with things like load current and temperature, so you will see a reflection of these in the capacity in this case.
I probably should not have made the voltage statement so definitive sounding since I really do not know how the devices are internally programmed. Also I never put a voltage meter on the battery to correlate with the reported percentage. My devices just seemed to behave that way.
Going back to the posting topic, from my own experience I do not find it unusual that a device reports 100% for a long time then dies. That is why I track the datetime of the update to make sure I’m looking at a recent value and not a stale one.
Hi, did you manage to ever find a solution to this problem? I have several Hue motion sensors reporting battery level ok, like 72%, but all my Hue wall switch modules reports battery level as 100% - even after a long time in operation (1-2 years)
If they also show 100% in the Hue app then I don’t think there is a solution. If the device reports 100% until it stops reporting then there’s nothing we can do other than look for the time of the last update as Bob mentioned above. If an abnormally long period of time has passed since the last battery level update then the device has probably stopped reporting.
I don’t really use the Hue app for anything else than adding new devices, but after upgrading to the latest version I noticed that battery “health” isn’t shown at all for the wall switch module while it’s shown for the motion sensors.
.