That needs to be a separate sensor. Attributes should rarely (if ever) change. Otherwise they can cause the database to become bloated. Every time your attribute changes both it and the state are stored - even if the state did not change.
Do not use attributes for values that change often.
Hope it will be still possible to create attributes…
Sometimes it is needed to create “attributes that change often” as a part of a template sensor: consider a case when it is needed to create a set of parameters after a complex calculation; a result is stored in a complex structure like a dictionary or a list - as an attribute.
Then, to avoid “bloating a DB”, this template sensor is excluded from recorder & additional template sensors are created to keep a history of a particular parameter inside that complex attribute.
To me this will be perfect as it will let me setup and icon for the entity based on it’s value. My idea was to create WTH for icon templates to each of the UI template but maybe this idea is better.
When one calculation creates a set of parameters - not possible to create separate sensors for each parameter. An abstract example to demonstrate “never say ‘never’”.
Assume some “foo” function returns a set “a,b,c” results.
For sensor “A” use the “a” result, for sensor “B” - “b”, and so on.
Now we have separate sensors “A”, “B”, “C”.
The “state” part of each sensor contains same code (only the last line is different). And maintaining 3 parts is more complex than maintaining one. And the same code is executed 3 times instead of one.
Sorry, what do you mean?
If you mean “DB has to store lots of changes of this sensor” - agree, that is why i exclude the sensor from recorder))).
These attrs are then used to create dedicated sensors (for which CPU time is spent - but it could be much less than a time of 3 same calculations) which are stored in DB.
Ofc I agree with this statement
“Attributes should rarely (if ever) change. Otherwise they can cause the database to become bloated. Every time your attribute changes both it and the state are stored - even if the state did not change.”
in case the entity is stored in DB, absolutely agree - the “state_attributes” table keeps every variation of attributes like
1,0,0
1,1,0
1,1,1
along with attribute names!
I guess I said several times that these “massive frequently updated” entities should be excluded from DB to avoid this “bloating” (or use separated sensors from the beginning if possible, as you suggested).
@tom_l, as much as I understand your advice on this, I cannot agree with overall solution. My view goes like this:
Entities can have attributes - this is a fact.
Some form of advanced UI for template entities should allow to define any attributes, text as this WTH and probably others, like dynamic icons. This advanced UI should allow this because it’s already possible with yaml manipulation but it’s very old style configuration.
Your point about attributes storage is very real. But this is a separate issue: data model should allow storage of attributes without cluttering db sensors history. And since nobody expects attributes to have history stats, I think it would be totally acceptable to store them separately with upsert instead of insert with every new attribute value.
If one needs attribute history, make attributes a separate sensors - totally agree.
So, to sum this up, excluding attributes from sensor definition (like it’s done right now) does not resolves a problem with data model in the database. And this WTH is about attributes definition in the UI on par with advanced yaml config and nothing more.
Hope we can settle with cause and effect separation here.
Hm… but for example “media_player…” entity has quite some attributes which do change often, like volume, or even worse: current played song title in DAB radio’s entity (which i have) - this attribute is change every couple of minutes… ?