Many battery-powered " sleepy" devices reports battery levels in tiers. The exact tiers will vary by device.
For most contact sensors, the tier that is reported as “88%” really means “above 87% and below 100%”
So as soon as battery level drops below 100%, even to 99%, it will likely be reported by SmartThings as 88%, although the exact buckets vary by DTH/Edge Driver.
What you need to watch is the trend. If it drops 10% in one day. That was probably just a tier drop. You can even bounce back-and-forth by 10% because it’s right at the threshold of a tier.
But if it’s dropping 10% every week, that’s a different problem.
If you’ve had any device off-line for a while, it’s really common for it to come back in the next lower tier, which looks like a 10% drop but might’ve been a drop of half a percent. Or might just mean it hadn’t reported for a while previously.
Also note that lithium batteries do not have the same drain pattern, which throws reporting off. They commonly look about the same as other batteries down to about 50%, and then drop very rapidly after that. For this reason, most lock manufacturers recommend not using lithium batteries, as you may not get a low battery warning in time to replace the batteries.
Also some devices only report noncritical battery levels once a week unless specifically polled. Again, that’s to make the batteries last longer. This can also result in apparent sharp drops.
Interesting! All my Z-Wave reporting battery levels, a mixture of many ST devices, two Kwikset locks, several aeon repeaters, etc, are degrading at random numeric levels from what I can observe. If there is logic to the reporting battery levels, I not seeing it as well defined numeric tiers.
I find battery level reports pretty meaningless. My Schlage door lock was still showing 75% in SmartThings when its low battery indicator went off. The batteries were on their last leg, measuring 1.1V.
@JDRoberts Thanks! That makes sense. The OTA will eat a little more energy than normal operation due to flash writes etc, and was enough to drop my devices out of the 100% tier.
Seems odd that the discrete steps for the tier are oddball numbers. Maybe it’s not all that odd if the number means >89 and the tiers are: …, 70-79,80-89,90-99,100+
I’m surprised to hear that manufacturers are using a read and report model based presumably on voltage alone. I would expect a more sophisticated model that uses the voltage as a corrective baseline, but provides a more accurate estimation of life based on a power model for the device and battery chemistry.
Regardless, I’ll keep an eye on it. I was mostly concerned that turning on OTA would take a chunk out of my batteries for each update. Sounds like I’m safe there.
One year later and I have devices that still says 100%… Check the logs and there is never any battery updates sent.
Looks like ST defaults a lot of devices to standard ST device handlers when installed/included, thus ST has the default interval set to “checkInterval: 28920” which is equivalent to check the batteries every 3.3+ years or is that interval in seconds which would be much less? Thus, after the initial battery percentage is taken at setup, the battery will basically never report it strength again, because it will die before it ever reaches the 3.3+ year mark to report any changes.
Further looking at ST IDE, I see all my sensors that are non-ST branded (moisture, motion, door) are all set to this ridiculous 3.3+ years. Strangely enough, the ST branded moisture sensor is set to (checkInterval: 720) a convenient 30 days and is thus keeps you up to date on the status.
Not a big deal with a motion sensor that will just quit, put a new battery in and all is good. How about a moisture sensor which is monitoring your sump pump area, you may never get an indication of a low battery and thus never get that emergency notification you thought you would get… This happened to me, lucky it was just a test to check the system. Battery was reported at 100%, ran the test to only find nothing happen. Read out battery open voltage to be 0.9 volts (dead), ST still reporting 100%, put new batts in and all good, 100% and tigers alarms. Here we put all this time and money into peace at mind to only find out it may all be a waste…
Why am I not getting regular battery status updates on non-ST z-wave devices? Why is there no options to change the update rates on certified ST gear?
I would LOVE and update on this as well. I just had 2 Multisensors drop that control lights when a door opens and it took me alot longer to troubleshoot then it should have if I would have just known the batteries were dead. Deleting and recreating rules deleting and re-adding the devices etc.
As you probably guessed, checkInterval is measured in seconds. 28920 seconds is just a few minutes over 8 hours.
As you are discovering, battery reporting on ST is all over the map. In my experience I find that Lowe’s Iris devices to be fairly accurate in their reporting, while SmartThings devices not so much. I see a similar spread on devices by other manufacturers too. For example, my lone Zooz 4-in-1 sensor will report 1% battery for close to a month before it stops working, yet I have several FirstAlert ZSmoke/Combo’s that will begin to chirp even though battery life is well in the mid-70% range.
If it’s seconds, then why am I not seeing any battery reporting, it’s not the devices. I contacted each’s support team (Ecolink & Fortezz), they both said the controller/hub via the device handler must make the proper requests/changes to interval. Since ST appears to dump 95% of their competitors to a generic device handler, it appears they leave out the proper specific code to adjust/configure each brand device properly (since there seems to be no real standards on reporting).
If it is seconds, then the ST Moisture Sensor set to 720 would be reporting battery life every 12 mins, not the case either, last time was about 3 days ago, and all the other devices set to 28920 have never reported batt life since install.
Since their sleep interval is so long, this also blocks them from getting possible wireless firmware updates, cause they would simply never wake up unless an alarm condition was set, not good for critical devices such as moisture sensors which you may have a false sense of security are protecting you, but are actually dead and never even report or connecting to the hub. The ST Hub seems to flag normal switches when the stop communicating, but these battery devices never get such.
I only noticed this when the moisture sensor under the base deep sink was flooded by the kids, it never trigger an alarm, battery reports 100%, after some time of messing around, finally changed the batt and all good. Checked logs, nothing listed at all, these sensors seem to never talk unless there is an alarm and ST don;t seem to manage them or care.
The First Alert has its’ own ST DH and seems to respond properly, it report batt life on what seems to be a daily basis, and the those batts seem to drop a consistant value every month, you actually seem the numbers drop in the logs, they last about a year, not bad for 2 AA reporting every day and monitoring, at least I feel safe with them.
Considering taking the standard DH for a Moisture or Motion sensor and modify it to check regularly and force a device to use it.
One of my Iris motion detectors (with battery on month 15 of operation) began reporting 1% battery life left, yet continued to report motion events normally (though the green LED had stopped flashing). I finally changed the battery after two weeks of battery alerts (via Simple Device Viewer) just on general principles. But another Iris motion detector (same type) reporting 67% battery life, began missing motion events and soon quit reporting them altogether.
