Uhh… May I quote Frenck from this post ?
In general, attributes are something we nowadays try to avoid. Mostly you’ll see them from “older” or custom integration. For new integrations and in our review process, we generally don’t allow for attributes that have value/could have been their own entities.
And you guys propose a convoluted template with Jinja mess that stores everything into attributes as a ‘solution’ to a very basic feature that should be lightweight, easy to use and built into core ? No wonder HA gets more and more resource hungry with every release. And what about the HA for the masses thing ? Where a simple variable requires something like that ? I mean sorry, no offense, but this makes exactly zero sense to me. Of course there are ways and workarounds to achieve this behavior now. That doesn’t mean they’re desirable. I could write a value into a file with a shell command and then retrieve it back into a sensor by polling with another shell command. Will it work ? Sure ! That doesn’t mean it’s a good way to replace this missing feature.
The reason of this WTH (and the other one about variables) is exactly to avoid these kind of hacky workarounds. What we need is a good native implementation that follows current best development practices for HA. Giving the input helpers a read only flag would be an easy first step.