You can set up a rule to send a notification when a device battery drops below a threshold if that is what you are looking for. I use the user app device watchdog to tell me if a device has not had activity within 24 hours, so I know to change the battery. Most sensor battery levels are not accurate btw due to them not being calibrated and the way lithium battery voltage drops off.
as @bpspiller said, you can monitor battery levels and do it in HSM... You can also add device watchdog to see if anything dropped off the network
?????
For clarity for @david9723 , I believe HPM usually refers to Hubitat Package Manager, which I do not believe has any battery reporting capabilities (you can use HPM to search for and download Device Manager). @rlithgow1 is very knowledgeable and so may be referring to another program that I am not aware of (if so, my apologies for the above statement).
Like many others, I also use Device Manager to check for device activity on my Zigbee and Z-Wave devices and have set up RM rules to notify me if any of my devices drop off (which MAY indicate loss of battery power, OR just loss of RF connection). I also keep my battery type and battery install dates on @thebearmay’s Custom Device Note app for each battery powered device and consolidate this data on tiles for display on a dashboard in his Device Data Display app for quick reference.
Some device drivers also report battery level depending of course on the device firmware (not the HE driver) allowing this. My Ecolink Firefighter for example reports battery level. However, Z-wave devices seem to tie up the mesh more than Zigbee devices with regards to polling for this information (at least on my network) so frequent polling of Z-wave devices is probably not recommended.
As previously alluded to, unlike the relatively gradual voltage drop-off with alkaline batteries, with lithium battery powered devices, the drop off in voltage is rather precipitous, which doesn’t always give you much warning prior to battery failure. For this reason, it is hit or miss in trying to set up a “critical” battery level threshold to indicate when you must replace the battery (and it can vary quite a bit between devices).
For all the reasons above, that is why I decided to go with Device Manager (in combination with Custom Device Note, etc). I rely on Device Manager more for reporting whether the device remains connected rather than relying on it reporting an usefully accurate battery level (it can report both if the battery level appears as an attribute in your device driver) to send me notifications and to trigger an alert tile on my dashboard. Hope this helps.
Here is an example of the simple Rule to notify you of batteries that are going. If you are using Lithium batteries, they drop to dead suddenly when they get below about 40%. Note that this Rule notifies me when any battery is less than 45%. Although I might be changing batteries a bit sooner than actually required, I have not had a device die since I implemented this Rule.
1 Like
The difficulty with setting a particular battery level threshold for all devices (in my limited experience with HE) is that not only is there variability between the discharge rates (and the non-linear discharge voltage characteristics) amongst various lithium batteries, but there are also variations between the accuracy and validity of battery level reporting depending upon the device driver. In addition, each device may vary as to their tolerance for minimal operating voltages.
I suppose that the only way to establish a “dependable” threshold voltage would be to: 1) run a device until device failure, while 2) recording the last voltage level reported by that device’s driver, then 3) setting the reporting threshold above that level to whatever you feel comfortable with as to this “safety margin”. Unfortunately, I’m not sure how practical it would be to do this with each of your devices.
A more practical approach is to just guess and set the threshold trigger to whatever level you feel comfortable with through you individual experience. For example, you can try to keep lowering your threshold until you fail to detect a battery failure, then set your threshold slightly above that level (again, with whatever safety margin you feel comfortable with).
For your most critical devices, you may wish to set your safety margin higher than usual to make sure that your device remains powered, at the cost of having to replace batteries more often.
To “automate” determining what these threshold levels should be (I must emphasize that I have not done this but suppose it can easily be done), a RM rule could probably be written so that the last battery level that is reported just prior to the device going “off line” is recorded and used as a guideline for your low/replace battery threshold. I may have to try this!
1 Like
Battery reporting is done at certain ranges to preserve the battery by not requesting the device to report too often, which drains the battery faster. When a device reaches 35, it's time to think about replacing it. When it drops below the minimum range, it will remain at that range, in your case 20% (the range varies by device and protocol).
Bonus: If your batteries drain faster than expected, you may want to look into strengthening the mesh.
2 Likes
While I agree with most devices I would still say this depends on the device. SmartThings/Centralite moisture sensors will report 0% for months.
Per my previous suggestion, I agree with @ritchierich’s observation 100%. Battery monitoring of devices within HE can be quite variable in its accuracy and thus also in its usefulness.
IMHO, most reliable way to get the most out of all your battery dollars is to have some spares on hand, make sure to get notifications if device goes offline, and replace battery immediately. Of course, if you miss a critical event, then that can cost you way more than the cost of the battery. . . so in lieu of the above, just accept that your battery cost will be greater than ideal and just replace them even when they have more useful life to them (especially for more critical devices such as safety and security devices, or at least those that might have a negative effect on the WAF, lol).
It's not Zigbee, it's not Z-Wave...
but just for some reference of what CAN BE DONE when a vendor is making a product (albeit all proprietary) to sell into the wireless alarm system market where reliability is seen as paramount.
I leave the following excerpts from just one of Visonic's Instructions & Spec sheets, doesn't matter what device you choose, they all have this level of interaction with the panel.
No customer configuration required to get this to work. It's a built in feature to deliver the level of reliability necessary.
Everybody jump up and defend the current state of Home Automation all you want on this point, but HA needs to get there. This is "old hat" stuff in the Wireless Security Market. And yeah, maybe devices would cost more if this were a part of their feature set and all the protocols were in place accordingly. But that's fine by me...as the topology of my HA expands I am already fed up of this battery stuff...and I don't even have a fraction of what some folks in this forum have installed.
==============Excerpts from Visonic device instructions & specs===============
Features
....
Fully supervised PowerG detector
Long battery life
Low battery supervision <<<<<<<<<<<<<<<<<<<<<
....
Link quality indication <<<<<<<<<<<<<<<<<<<<<<<<
- LOCAL DIAGNOSTICS TEST
Before testing, separate the base from the cover (see Figure 2).
A. Press the tamper switch once and release it.
B. After 2 seconds the LED blinks 3 times.
The following table indicates received signal strength indication.
LED response Reception
Green LED blinks Strong
Orange LED blinks Good
Red LED blinks Poor
No blinks No communication
IMPORTANT! Reliable reception must be assured. Therefore, "poor" signal strength is not acceptable. If you receive a "poor" signal from the
device, re-locate it and re-test until a "good" or "strong" signal strength is received.
Battery type 3 V Lithium battery, CR123, Panasonic, Sanyo or GP only
Battery Life Expectancy 7 years (for typical use)
Low Battery Threshold 2.2 V
Starting my stopwatch to see how long it takes before someone flags this as OFF TOPIC...yeah, right.
Battery reporting is as good as the device says the level is. Some are better than others at reporting accurately.
Yes, that is what I meant. HE can of course only report what the device and driver can report. This was not a knock on HE, just the variability of how the device reports it. Please do not take offense as I think HE is fantastic and goes far beyond my expectations given near 40 years experience with other home automation platforms.
2 Likes
I agree that is the way to get the most out of your battery dollars. But I find the cost of batteries to be tiny compared to other costs in my home automation system. I am more interested in getting the most out of my home automation system and system reliability (no dead batteries) than I am in saving money on batteries.
1 Like
Agree 100% as I previously stated!
That's a good idea for new parameter setting individually per device.. Either on driver or App level.
I’m pretty sure this is dependent on the device firmware.
I corrected it, I meant HSM (hubitat safety monitor) which you can set to monitor any battery device for levels and be notified when one hits a certain threshold)
Yes, different devices will have different critical low battery levels.
Actually, there is no need to add new parameters - similar types of battery devices can be grouped into a common group in the community app "Device Activity Check", respectively the low battery alarms can be sent for different low level settings:
2 Likes
I use it too...
But it doesn't make up for the improvements that should be apart of the fundamental construct for managing device communication/signal quality and battery life across the whole spectrum of "best-in-class" Home Automation devices and hubs (backed by all the bells & whistles necessary for handling such in the Zigbee & Z-Wave protocols).
I wish we had a tool to advise on signal strength, instead of having to use xbees or some other device, instead of just relying on last hop LQI
2 Likes
