Good write up. Let me try to add a few points from how ST and the DTH’s work with some devices. If you have a Z-Wave device as per the specs it defines two alerts before the battery dies. First one is low battery and other one is critical battery (depends on type of device). Now comes the tricky part:
- The specs don’t define what is low battery and what is critical battery. Some devices report low battery as 30% others as 10%. Same for critical battery. So what ST does is by default in most handlers when it receives a low or critical battery it sets the level to 1%. So if you see a device showing 1% it’s not because the battery is at 1% it’s because it sent a low or critical battery alert and the DTH set it to 1%. If you have custom DTH then those may do a better job of defining how it handle those alert level and appropriately report the battery levels. So while it may report low battery which for the device may indicate 30% battery remaining but the DTH reports it as 1% it continue working for another few weeks or even months! On the flip side Schlage connect locks doesn’t report a low battery alert until it gets down but the lock itself shuts down when the battery gets lower than 50% due to a sudden drop in voltage when the deadbolt motor is used and the batteries can’t provide the juice needed. This has caught many people unaware because the battery level is 50% and the lock is dead ie no more updates.
- Not all devices report these two alerts. Some only report critical. Other report both. Some don’t report any either by bad design or like I mentioned Schlage above it doesn’t get a chance to reach the operating voltage level (again poor design).
- As for why ST doesn’t report when a device does go offline using its Health Reporting System, it’s complex because some sleepy devices don’t send updates for as much as 72 hours. Since ST doesn’t make customized DTH’s it has to take the worst case scenario in mind and then determine when to report a device offline. Plus to make it worse with sleepy devices there no way to poll and see if the device is active so it’s a waiting game and the waiting period is determined by the longest wait time of the device in that class as ST DTH’s aren’t customized. So here some the case for why not have custom DTHs do a better job for reporting device is offline, that’s because ST doesn’t encourage the use of device health in custom DTH due to an internal bug in their system for years now. But this is the best case scenario is to have custom DTH’s handle device offline reports.
I hope this helps shed some light on the complexity of the issue.