With multiple battery-operated contact and motion sensors, I find it difficult to keep track of which device uses which battery. Currently, I have to Google it every time so I know what battery it's going to need soon once it flags a low battery notification.
Where I realize a drop down to select the battery size would be a nightmare based on likely the sheer number of possibilities I've seen... but, I was thinking even a "notes" field for any device would be helpful in that I could make note of the battery needed (CR2032, CR1650, AA (x2), 123A, whatever).
Would save me a Google search every time I replace a battery...
Wouldn't have to be a huge field... Maybe 64 characters?
I keep a Google Sheet of the date I replaced the battery (or add a device) so I can tell how long a device lasts on it's battery. I simply have a column there to track the battery type. I do this for devices all across the house (Ecobee sensors, garage door remotes, etc), not just ones on Hubitat.
I have NodeRed listening to the log and event sockets and writing those to MariaDB on my NAS. Within that database I have a devices table tracking current battery level, previous level, and longest duration too via trigger.
This allows me to track by device if the battery is getting close to the max number of days its ever lasted. This was important to me because I have 19 ST/Centralite moisture sensors that were stuck on 0% battery for over 6 months and no point in replacing something that doesn't report battery level accurately.
Then in Grafana I expose some columns of this table for easy viewing and also in NodeRed I have a flow query this table twice a day letting me know via Pushover if a device hasn't reported along with the battery levels if one hasn't.
Once you're off your phone and on a computer (really, did this on your phone?!) if there is an option to rename each instance that will help a lot. Or parent-child setup. But very cool, love this generally, can see a lot of uses for it beyond just battery notes!! Is there a length limit?
Very cool. Second instance the note updated on the device as soon as I looked, so there may have been some intermittent delay. Really like this - thank you.
App instance is an easy add, may wait until I get home though. (App isn't needed after the note is added unless you want to update or remove the note.)
I think it's 1024 characters (it's a normal state attribute), but I know it's greater than 1024 because I've exceeded that before, but not sure how much. I'll see if I can find something to verify the actual limit.
There is definitely some initial delay. I tested the app immediately after you posted it. When I added a note on one device, it didn't show up. I was perplexed and added a second device (which gets the same note), and then the note showed up on both devices. When I removed the note it seemed to happen immediately.
FWIW, I think your app should get it's own thread. Very nice concept.
I've thought of asking for something similar. Better than a field would be an attribute so you could use this is rules and such, so you could create a rule that would add the batteries to your shopping list when they are running low.
The ability to add custom attributes would be even better as I have a number of variables that track additional information about devices, and it would be cleaner and more organised to have them as part of the device.
I believe what you are asking for there would have to be handled at the device driver level so that probably won't happen. However you could create an automation that is triggered when any of a list of devices that contain a particular type of battery gets low.
Can't give you attributes, but I've added the capability in the app to allow you to "name" the data element being stored which effectively permits you to store multiple unique data items on the device.
Edit: If you have a use case that needs the data element to be available to RM let me know, I think I could create an app and child device that would allow you to do a command from RM on the child device that the app could fulfill by populating an attribute on the child device utilizing data stored in the device data area.
) that should let you do this:
