tl;dr
Enhancing and structuring home-assistants entity values with semantic meanings rather than the flat state-attributes-model would provide a solid foundation to ease higher level actions.
e.g. a global battery „datatype" could normalise how to treat different battery level independent from hardware specifics.
Long version:
Home-Assistant has come a long way and went up a steep road to be the great home automation platform it is today.
One great characteristic is, that you can jump in easily to configure your first scripts and write automations with no mentionable effort.
When writing more and more automations over time you begin to recognize patterns and repetitions you have to put in the code as well as inconsistencies in the entity model implementations become more clear.
E.g. if you want to receive a notification if a devices battery runs low, you have to look for the devices specifics to get the battery level.
For Z-Wave devices it may be found in zwave.mydevice attribute named battery-level
For Mifloras platsensor its an own sensor.devicename_battery
And for a third device it can be found in the attributes again but now it’s named battery
You get the idea. It’s always the same kind of information you want to retrieve, but we have to figure out how to gather it for each device individually, which complicates automations making them harder to maintain and also more error prone.
What’s valid for this example can be extrapolated for any kind of information contained in the many platforms you use.
Wouldn’t it be cool to have a battery-level type attribute we could use in our devices to unify access to this kind of information?
You probably already know where this is going. What if every kind of value would have such semantics? Fetching temperatures, brightness levels, humidities, … becomes very easy.
Also the history component would benefit from a meaningful separation of values for example. With semantics the percentage value of relative humidity can be distinguished from the CPU load.
Currently both are expressed with a % symbol which results in shard graph lanes.
If we take the idea even further down the road, we could define meta attributes of a temperature, brightness, …
like unit of measurement, datatype (int, float, string, …), precision, valid minima or maxima, and so on.
I’m not the first one to make this up. Zwave did this a long time ago with a devices supported functional classes and Apple implemented the same semantics in their HomeKit platform.
Which is great. Because if you ask Siri to turn down the lights. It already knows what a light is and that it has a light-level that needs it’s value to be decreased.
Currently a entity is a mixture of a main value (provided through state-attribute) and some kind of helper/additional values provided by an entities attributes.
If we had these characteristics like battery-level, temperature in an own datatype, we could join them in a device. From a users side reading either of these values would be unified. In automations you’d fetch the temperature of a sensor always the same way. No matter if it’s a mqtt sensor, a nest sensor, a knx sensor, …
If it’s Actually it’s something voluptuous is used for. It’s „just" extending it’s scope from component level to a more global scope and using it in automation, scripts, templates and areas I have not thought about at this point.
If you use snips, a already integrated voice control system, you could easier integrate questions like “what’s the indoor temperature?” Because home assistant “knows” what a temperature is.
I think the idea beyond this became quite clear and I’d be happy to discuss it with you. There are already ideas how to extend APIs to benefit from a newly gained awareness of “what” information home assistant can provide.
What do you guys think?
