Could You confirm that the only possibility for templating sensor value is to create another sensor?
If so, what is the cause? We are trying to tune-up our setups by minimizing database records and at the other hand, to modify displaying value we need to create the duplicated sensor.
Most probably there is a reason why we can not use templates in customizing existing entity or better, customizing just the displaying value directly in the card. But what cause that limitation?
It’s just the way each integration is written. Some of them support value templates.
You can do templates directly in cards with domething like this. If it is only about the value being displayed you don’t need additional sensors and ibstead have the tenplate directly in the card.
I take it you have sensors from one or more integrations that you cannot adjust - which is the way the integration developer planned it (otherwise, chaos may ensue). For example, when I add a TP-Link WiFi switch, I then have an entity for the switch called switch.xxx. I can’t do anything with this, but I do create other sensors that can take advantage of it. For example, one of them is a power-monitoring switch (the new KP-115 from TP-Link). It has attributes for power, current, voltage, etc - but I wanted a sensor that directly displayed the power. So this is how I do that (this is under my sensor section):
- platform: template
sensors:
smart_plug_vaporizor_main:
friendly_name_template: "{{ state_attr('switch.main_floor_vaporizer','friendly_name')}} Current Consumption"
value_template: "{{ state_attr('switch.main_floor_vaporizer','current_power_w') | float | round(1) }}"
unit_of_measurement: 'W'
I do not hesitate to create additional sensors that are more tailored to what I need. I’ve found that it’s much easier to create the sensor and then use it as opposed to a bunch of templating in automations or cards.
You can keep different entities from being added to the database. For example, I exclude all input_boolean entities from my database by using this in my configuration.yaml file under the recorder section:
recorder:
purge_keep_days: 180
db_url: mysql://xxxxxxx:[email protected]:1116/hassrepository?charset=utf8
exclude:
domains:
- automation
- updater
- input_boolean
- group
entities:
- light.mbr_main
- switch.dryer
- sensor.smart_plug_dryer_amps
- sensor.no_laundry_room_motion
- sensor.no_master_bedroom_motion
- sensor.no_training_room_motion
- and many more...
I exclude complete domains (automation, updater, input_boolean, and group`) because I don’t care about the history of those. Then I exclude specific entities, too.
Hope this helps explain how to do what you want to accomplish! Let me know if I misunderstand what you are working to accomplish.
@Burningstone is spot-on - just adding another custom card that I use a lot - it let’s you do almost anything you want within the card: GitHub - custom-cards/button-card: Lovelace button-card for home assistant. You can set up templates and then re-use them. I tried several others, but this is the most flexible one that I can find - you can add templated information via JavaScript. Here’s an example of how I display a timer using the custom button card. First I set up a template that I can re-use:
timer_status:
template: name_bold_label_gray <---- This is another template...
color_type: icon
icon: 'mdi:'
show_state: true
state:
- color: 'rgb(0, 102, 204)' <---- customize the color depending on the `state` of the entity
value: 'idle'
icon: 'mdi:timer-off' <----- Custom icon for an idle state
- color: 'rgb(255, 153, 51)'
value: 'active'
icon: 'mdi:timer' <----- Different icon for an active state value
Note that it also uses another template that I set up (name_bold_label_gray). That one is:
# This sets formatting for the name, label, and state displays on the card so
# that the look of my interface is somewhat consistent throughout
name_bold_label_gray:
styles:
name:
- text-transform: uppercase
- color: black
- justify-self: center
- font-weight: bold
- font-size: 12px
label:
- color: gray
- font-size: 12px
- justify-self: center
- padding: 0px 5px 0px 5px
- font-weight: bold
state:
- font-size: 10px
- justify-self: center
- padding: 0px 0px 0px 0px
Between the two of these, I’ve now described a ton of features that will display on the card. Then here’s an example of how I use those to actually display three timers with very little code (because most of it is in the templates above):
- cards:
- type: 'custom:button-card'
template: timer_status <--- This says to use all the formatting, etc, from the template
entity: timer.mbr_vaporizer_startup_timer
name: Startup Timer
- type: 'custom:button-card'
template: timer_status
entity: timer.mbr_vaporizer_run_timer
name: Run Timer
- type: 'custom:button-card'
template: timer_status
entity: timer.mbr_vaporizer_pause_timer
name: Pause Timer
type: horizontal-stack
The display looks like this:
You can do other things, too, like this - showing how to use the JavaScript feature under the tap_action section:
- type: 'custom:button-card'
template: light_name_bright
entity: switch.inovelli_unknown_type_c000_id_c001_switch
name: Wreath
icon: 'mdi:lightbulb'
tap_action:
action: >
[[[ return (states['binary_sensor.christmas_lights'].state == 'on' ? 'toggle': 'more-info'); ]]]
The GitHub page has a ton of examples.
Can you provide an example of what you tried to do but discovered the only way to achieve it was by creating a Template Sensor?
@tom_l, @Burningstone
I do not know any native card in which You can customize values. But, if custom cards can, that means it is not technically impossible.
@KSC
Thanks for a lot of great, detailed examples. But it does not answer the question - why we waste memory for duplicating information? Why it is not possible natively in all cards and/or customize.yaml?
Great that duplicating is possible to make additional sensors for unusual purpose but first choice, IMO, should be “use existing info, just display it in desired way”. It does also applies to attributes.
Tailoring recorder in that case looks like a work-around. Again - great it is possible but how strange is to duplicate sensor valute to delete then then the origin one.
@123
Let say I have sensor.temp which value format is x.xx, and I would like to display it as an x in, gauge card because completely do not care about decimals.
I can not understand that, when we all do care about database size and its records frequency, I can not simply use:
sensor.power:
value_template: "{{ states('sensor.temp') | float | round(0) }}"
or
type: gauge
entity: "{{ states('sensor.temp') | float | round(0) }}"
and in another card
entity: "{{ states('sensor.temp') | float | round(1) }}"
(because I need here 1 decimal place) instead of making another sensor?
I wasn’t talking about Lovelace cards. I was talking about integrations, because you asked “why”. It’s just the way each dev implemented them.
123 has given you the answer you need. The templates are in javascript not jinja. So lookup how you round numbers in that.
I do agree, Lovelace needs a number formatting option. Using templates just to round numbers is like cracking a walnut with a sledgehammer.
That was in response your comment:
I think it’s good practice to keep the exclude list tuned up. Otherwise there’s a lot of wasted space and write activity.
As @tom_l pointed out, there are a number of places we can use templates. The developers have been, I noticed, adding to the list of where templates can be used. Suggest you might submit this as a feature request.
I think what you really want is the custom:button_card I recommended above. There’s a bit of a learning curve, but once you get it going, it’s very straight forward. Don’t forget, these all use JavaScript for templating, not Jinja.
I meant that we (You, me, others) are (already) put an effort for tuning our systems, including database recorders. And duplicating information and database entries is something opposite.
I was curious is that technically possible. If it does, why HA do not implement this for the sake of system performance and user experience. As I heard, @balloob can have the answer but that is only the rumour.
That is great, potential full solution. Thank You I didn’t know that. But, I am afraid, it do not solve rounding problem in gauge card;)
Great to hear that! Crossing fingers.
Please don’t tag people like that. See point 16: How to help us help you - or How to ask a good question
Oh, terribly sorry. I have no other intentions that clearly identicate the person. Writing “balloob”, of course for lot, but maybe not for everybody, is unequivocally.
Can you please try rephrasing that in English?
I have no idea what it means.