WTH UI templates don't have "Attributes template" option

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.

Each parameter should be a separate sensor.

As I said - sometimes they need to be defined as a result of one calculation.

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.

In template sensors, icons are defined not as “attributes”, they are defined separately:

template;
  - sensor:
      - name: ...
        ...
        icon: ....
        attributes:
          ...

Also, there is this WTH about templated icons in UI for helpers (hope it is what you need).

1 Like

Then you should be able to easily copy and paste the calculation into new sensors.

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’”.

That is not true. All the copies of the template will update at practically the same time yielding the same results.

I see, what I can do is:

  1. Assume some “foo” function returns a set “a,b,c” results.
  2. For sensor “A” use the “a” result, for sensor “B” - “b”, and so on.
  3. Now we have separate sensors “A”, “B”, “C”.
  4. 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.

And your database use is halved.

1 Like

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.

And we loop back to what I wrote originally:

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).

Yes, sorry I missed this bit:

That would be fine.

1 Like

@tom_l, as much as I understand your advice on this, I cannot agree with overall solution. My view goes like this:

  1. Entities can have attributes - this is a fact.
  2. 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.
  3. 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.
  4. 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.

1 Like

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… ?

I think you wrote exactly what I was thinking:

My view of this WTH (at least the reason I voted for it) is to be capable to define easily a sensor template with some basic attributes.

My personal exemple would be to try to get rid of mushroom template card:

  • create an entity with state controlled by template
  • manage also icon and color through template
  • use a simple Tile card to display it.

This is for the time being not feasible though UI.

Not for much longer :slight_smile:

1 Like

Oh? Is there any change planned? That would be great… i had to create a bunch of template sensors to be able to use these attributes.