The Aeon Labs Multisensor 6 (ZW100) has a configuration parameter (#39) labeled low battery report.
Is it possible in openHAB to receive these reports to trigger a rule? I don’t see any relevant channel in the device properties in paperUI. It would be great to have a rule that sent a notification when the battery level threshold is reached. I realise I could use the battery level channel and create a rule, but it seems like it would make for less code to write and maintain if a low battery warning from the device itself could be detected.
Stupid question, have you clicked ‘show more’ on the Paper UI thing page of the sensor? (I’ve spent many an hour scratching my head as to why a channel I know should be there isn’t for this very reason)
If it’s not listed as a channel I doubt it can be added as a channel. If it is in there and you can link it then it’s just an item so won’t alert you, you’ll just have to write a very quick rule for if batterylevel < 10% then do xyz…
There should be a battery level channel - if not, the database is incorrectly configured. This channel carries the low battery - it’s the same thing, and it is represented as 0%.
You probably want to do that for all of your battery devices so just created one rule to work on a group of battery devices ?
Oh, and the ZW100 eats batteries like hell. If there’s a chance to, put it on mains power.
Really? So if I have parameter 39 set to 20, as the battery discharges it will go 22%, 21%, 0% and I can just write a rule based on hitting 0%? Will the battery level stay at 0% until the battery is replaced? The reason I ask is that I have noticed the battery level tends to fluctuate up and down by a few percent (perhaps due to temperature changes?) so a simple rule tends to trigger repeatedly when the battery level approaches that threshold. Is this feature documented anywhere? I can’t find it in the manual or the technical reference information.
Yeah I’ve got a bunch of them so I will be writing a group-based rule. I know how to do that thanks to this forum.
I’ve had these sensors for a while and I don’t find them too bad on battery life. I usually get 4-6 months off a pair of batteries. I’d love to get mains power to them but that would be a fairly big expense (very old house with lath/plaster walls and limited access). I will be renovating in the future and hopefully will be able to get a low voltage circuit installed that I can tap into easily to power devices like this.
Some newer devices may also provide an ALARM channel for low battery, but that’s not linked to this channel. If it is provided by a device, then it can be supported separately as an ALARM.
These sort of questions are ones that only the supplier can answer. Battery monitors in these sort of devices are notoriously bad - they will change with load, and temperature for starters.
What feature exactly do you mean? The fact that battery level will show 0% in alarm? This is not currently exported from the database so I will add it. If you mean something else, please let me know.
I’ve got a whole batch of fresh batteries in all of my sensors so it will be a few months until I can document what happens. I’ll try to set up some logging so I can give a definitive answer to this.
I have finally gotten around to looking at this properly, and have observed an interesting behaviour in these sensors around low battery warnings.
I have set up persistence using Mariadb and these are the changes seen in the battery levels over a few days when the battery is running out. I haven’t yet captured data over the complete life of a set of batteries. This is the data from an item linked to the battery-level channel of a Multisensor.
This sensor has parameter 39 (low battery report) set to 20.
A few things stand out;
The battery level doesn’t fall smoothly over time. For example, there is a big jump from 59% to 28%.
When the battery level is low the device begins reporting the battery level on the channel, followed very soon after by a zero. The warnings actually begin at a battery level slightly higher than 20% for some reason.
This leads to an alternating pattern of decreasing numbers and zeroes. So a simple rule to send out a warning on the battery level changing to zero will be triggered repeatedly and could get annoying very quickly. A rule would have to be written to take this into account.
The battery was installed long before this data was recorded, so it seems that the reported battery level stays high for most of the batteries’ life and then falls fairly quickly.
Hopefully this information is of use to someone else using these devices.
This is very common with low cost devices - they often use battery voltage as a battery level indicator. This is only a first approximation of battery level - voltage will change with load and temperature and is non-linear (as you see).
This is the way the binding interprets the information. A device doesn’t have a separate flag for low battery - there is only one battery reading, and to flag low battery the device reports 0xFF. Since some devices will only report this, the binding sets the % to 0 since it doesn’t have any other way to know what it is. Since this device seems to send alternating reports, you see this manifest as 0, then a number.
There is no such thing as a ‘low battery alarm’ from the point of the Z-Wave Specification, there it is called ‘battery warning’ - probably to avoid confusion with the deprecated COMMAND_CLASS_ALARM.
The ZW100 doesn’t support the deprecated COMMAND_CLASS_ALARM, but does support the COMMAND_CLASS_NOTIFICATION. The manual lists the Notification Types supported by the ZW100 (COMMAND_CLASS_NOTIFICATION):
The Z-Wave Binding maps the COMMAND_CLASS_NOTIFICATION to COMMAND_CLASS_ALARM V3, which doesn’t exist from the perspective of the Z-Wave specification (only COMMAND_CLASS_ALARM V1 and V2 are defined).
