Maybe i'm a bit bored (or lazy). but here is my really minor idea...
I have a bunch of battery operated devices.
When the time comes to change batteries i usually change all the sensors of a similar type at the same time. I find it less painful to do it in one go, than everyday go and change batteries. I typically check each device type and orders batteries off amazon.com. To check the device type i usually use google and try to find the installation manual to see the battery type so i order the right thing.
What i would love is that if there is a field for each device type that is pre-populated with battery type. That way i can envision an automation for checking battery levels that also sums up the type and quantities of batteries i should buy.
i would of course like that to have the ability to set a user defined type in case i use that driver for a different hardware than what it was defined as being for.
Perhaps a really minor idea, but i think it would be neat. And perhaps not too time consuming to add an extra field for battery type for battery operated devices.
This does sound like a good idea more generally for the ability to record additional, user-defined information about devices. Others would probably like to record a devices room, etc. I'm not sure of the best way to approach it in terms of a solution. Only option I can think of would be an app, but not sure how you would store or retrieve the information in a useful way....
I don't mind the generalized end-user key:value capability.
...but i really like the idea of the driver identifying the device and having pre-determined value for battery types wherever possible. It will make it much more obvious to generalize in automations if it is a pre-defined field. I can tolerate if its blank and needs to be filled in by the user -but the joy of having defaults is that the names of the battery types will be uniform per type unless the user over rides the default.
That is a fair point, the battery type for commercially available devices isn't going to change, at least for the same model. Having a bank of known device specs such as battery type would be useful, even if it was stored in the cloud, accessed on device creation and then stored locally, perhaps in a tag, with the ability to override / update it manually.
One thing I did discover this morning was the Preference Manager built-in app, allowing you to update preferences for a list of devices in one spot. It could be used as a half-way point for what you are after, if it could be extended or something similar created as part of implementing tags (@gopher.ny) . Updating a "batteryType" tag for all the devices you know to have the same type of battery. Just an idea...
If we had a field for battery type that is a preference type field, yeah then the preference manager would work great. Its one of the reasons why i prefer the key for this field to be predefined as it will make all several types of apps compatible.
