Please allow defining additional attributes for template sensors with UI
Current state:
Why not additional “Attributes template” there?
Do not forget to vote for your own proposition…
I don’t think that feature parity is necessarily the goal for Template Helpers.
Adding attributes to the UI would be contrary to 2 stated goal from the arch discussion
- Prevent the UI from becoming overwhelming for users at all levels, especially new users, and preventing it from ending up with excessive configuration options that hurts UX.
- The long-term goal of moving attributes (especially dynamic ones) into their own sensors so that users aren’t forced to create template sensors to break them out; and to prevent the DB bloat that they can incur.
My use case for template sensor attributes would be to have “alternative names” for states. For example, I have a “Days until watering day” template. Its state is a number which says how many days remain. I would love for it to have attributes, for example “nice name” which would say “In 4 days” or “Tomorrow”. I can imagine other ways to represent the same data, which attributes would be useful for.
Without attributes I’d have to create a template sensors for each type, which feels hacky and becomes cluttered.
sure, but we already have switch for that, right?
This is a way to hide somewhat optional (unused) options on the add-on configuration panel.
I understand we don’t want to scare people with options. So show mandatory fields and hide optional behind a “advanced options” switch
That seems like something you’d want to do in the frontend, not the backend?
The backend is great for data that should be stored, used for automations, plotted, or analyzed.
If you want to make a more user-friendly easily-readable version of a sensor, there is no reason to have the backend calculate and store that text string every time it is updated. Have the frontend do that only when someone is looking at it.
In other words, use a card on a dashboard that supports templates.
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:
- 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.
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).