I agree with pretty much everything that’s been said in this thread… the battery drain pattern and “battery needs replacing” notification will be different for different devices… but it also seems like the sort of thing that could be tracked/learned/stored over time. Basically, there could be a “wizard” for setting up a new device with battery-related values:
- What type of battery does this item take?
- What % battery level do you want an “early notification”? (Who should receive this notification, notification text, etc.)
- Duration of “radio silence” before we consider the battery dead?
- Notification settings after battery is dead? (Who should receive this notification, notification text, etc.)
And there could also be a “learned battery usage pattern” on a per-device basis, which could be used to show a “historical battery pattern” for each device, and could allow the user to see a graphical representation of battery usage that could be used when re-running the wizard, so that you could adjust the various timings/messages based on empirical data for how that specific device uses batteries. (I’m imagining a graph that starts with “device came online for first time with 100% battery” and ends with “device stopped responding, battery presumed dead”, and shows all the various levels which were reported in between with their relative timings.)
Additionally, this could allow for things like, “your window sensor is still reporting 100% battery, but is approaching 6 months on this battery, so based on historical data, we’ll send the user a warning that this battery may need replacing in the next X weeks”. Basically allow for a “calculated battery life remaining” to be used for the “early notification” setting, so that the user could have a chance at receiving a usefully-timed alert on those devices which do a poor job of reporting remaining battery life on their own.
Yes, in theory each user could create their own separate set of automations for each individual device for battery notifications, but there are also only a handful of relevant configuration values that relate to battery usage, so creating a standardized system for this still makes sense. Furthermore, the real power for this sort of thing would be tracking/storing the usage patterns on a per-device basis, which involves a decent amount of “architectural overhead” that’s likely beyond the average user (especially since “doing it right” would involve a development life cycle spanning many months to monitor actual battery draining, and lots of different devices).