yeah, please add your +1 here https://github.com/thomasloven/lovelace-template-entity-row/issues/10 and hope Thomas reads this…
I discovered the lack of more-info
as well but decided to convert some of my cards anyway where it wasn’t so important or just not needed.
Yet looking forward to it as a great addition to the very useful card.
Done! Upvoted the feature request and added a comment explaining why I need it.
For anyone interested, here’s the default entity card for a climate entity, tweaked with Custom-UI (black ‘ZZZ’ icon to indicate the system is currently idling).
Here’s how I re-styled it using card-mod and template-entity-row. The icon’s appearance is the same as with Custom-UI plus I changed the data’s placement to suit my preferences.
- The information on the right represents the HVAC system’s current activity and current ambient temperature.
- The information below the entity’s name represents the HVAC system’s operating mode and setpoint temperature.
It now looks and works exactly the way I want it (spartan) but with one enormous showstopper: clicking it doesn’t open the more-info
panel so there’s no way to control the thermostat.
So very close to the desired solution yet unusable (for my needs). Back to the drawing board …
Any chance of seeing the config before you burn it?
You can do what you want with the custom:button-card but it’s a bit more configuration.
EDIT: I’ll share a card that will work later tonight if you are interested.
The template for icon
and style
should probably be nearly identical but I was experimenting so icon
's template is a bit different (and includes a potentially superfluous if-else).
- type: vertical-stack
cards:
- type: entities
title: Climate
show_header_toggle: false
entities:
- type: custom:template-entity-row
entity: climate.thermostat
state: "{{state_attr(config.entity, 'hvac_action') | title}} {{state_attr(config.entity, 'current_temperature')}} °C"
secondary: "{{states(config.entity) | title}} {{state_attr(config.entity, 'temperature')}} °C"
icon: >
{% if is_state(config.entity, 'off') %}
mdi:power-off
{% else %}
{% set ha = state_attr(config.entity, 'hvac_action') %}
{% set icons = { 'heating':'mdi:fire', 'cooling':'mdi:snowflake', 'auto':'mdi:autorenew', 'idle':'mdi:sleep'} %}
{{ icons[ha] if ha in icons.keys() else 'mdi:power-off' }}
{% endif %}
style: |
:host {
--paper-item-icon-color:
{% set ha = state_attr(config.entity, 'hvac_action') %}
{% set colors = { 'off':'gray', 'heating':'red', 'cooling':'blue', 'auto':'green', 'idle':'black'} %}
{{ colors[ha] if ha in colors.keys() else 'cyan' }}
;
}
I’m almost tempted to turn HACS back on so I can browse the list of available custom cards … except I turned it off because I had no need for custom cards (i.e. UI is spartan). Anyway, ‘button-card’ has been added to my task list. Looks like I’m going to have to learn more about the available custom cards than I ever thought I would.
Any examples you are willing to share would be appreciated.
you are aware you can simply put the climate entity in an entities card?
- type: entities
entities:
- entity: climate.kantoor
and of course customize a bit:-)
climate.kantoor:
templates:
icon_color: >
var temp = entity.attributes.current_temperature;
if (temp < -5) return 'rgb(30, 255, 255)';
if (temp < 0) return 'rgb(30, 144, 255)';
if (temp < 10) return 'rgb(255, 255, 0)';
if (temp < 15) return 'rgb(255, 211, 30)';
if (temp < 20) return 'rgb(0, 128, 0)';
if (temp < 25) return 'rgb(255, 165, 0)';
if (temp < 30) return 'rgb(255, 0, 0)';
if (temp < 35) return 'rgb(85, 0, 0)';
return 'rgb(47, 0, 0)';
icon: >
if (entity.attributes.hvac_action == 'heating') return 'mdi:fire';
return 'mdi:pause-circle';
icon_color as you can see based on inside temp.
if you want, color it on action too of course:
That’s what I currently do on my production system which has Custom-UI installed.
climate.thermostat:
templates:
icon: >
if (state === "off") return "mdi:power-off";
if (attributes.hvac_action === "heating") return "mdi:fire";
if (attributes.hvac_action === "cooling") return "mdi:snowflake";
if (attributes.hvac_action === "auto") return "mdi:autorenew";
if (attributes.hvac_action === "idle") return "mdi:sleep";
return "mdi:power-off";
icon_color: >
if (attributes.hvac_action === "off") return "gray";
if (attributes.hvac_action === "heating") return "red";
if (attributes.hvac_action === "cooling") return "blue";
if (attributes.hvac_action === "auto") return "green";
if (attributes.hvac_action === "idle") return "black";
return "gray";
The result is this:
It’s possible to customize an entity using the configuration variables listed in the documentation. What the documentation doesn’t explain is templates
. Because, based on my understanding, that’s an extension provided by Custom-UI.
On my test system, which does not have Custom-UI, this is what I tried:
climate.thermostat:
friendly_name: Thermostatus
templates:
icon: >
if (state === "off") return "mdi:power-off";
if (attributes.hvac_action === "heating") return "mdi:fire";
if (attributes.hvac_action === "cooling") return "mdi:snowflake";
if (attributes.hvac_action === "auto") return "mdi:autorenew";
if (attributes.hvac_action === "idle") return "mdi:sleep";
return "mdi:power-off";
icon_color: >
if (attributes.hvac_action === "off") return "gray";
if (attributes.hvac_action === "heating") return "red";
if (attributes.hvac_action === "cooling") return "blue";
if (attributes.hvac_action === "auto") return "green";
if (attributes.hvac_action === "idle") return "black";
return "gray";
After restarting Home Assistant, the only part of the customization that works is friendly_name
. The templates
section is ignored and the icon displayed is the default one for a climate entity.
yes, icon_color is only available with custom-ui. the customize documentation states what is available in core, and that is without templates…
the rest is in js only in custom-ui (frontend, browser side) or, of course with the template (binary) sensors, in jinja (backend, server side)
===
try
==
just 2 instead of 3
climate.thermostat:
friendly_name: Thermostatus
templates:
icon: >-
if (state == "off") return "mdi:power-off";
if (attributes.hvac_action == "heating") return "mdi:fire";
if (attributes.hvac_action == "cooling") return "mdi:snowflake";
if (attributes.hvac_action == "auto") return "mdi:autorenew";
if (attributes.hvac_action == "idle") return "mdi:sleep";
return "mdi:power-off";
icon_color: >-
if (attributes.hvac_action == "off") return "gray";
if (attributes.hvac_action == "heating") return "red";
if (attributes.hvac_action == "cooling") return "blue";
if (attributes.hvac_action == "auto") return "green";
if (attributes.hvac_action == "idle") return "black";
return "gray";
jut for the fun of it we should really be using mappers, but if you don’t want that, you can also do:
icon: >
var action = entity.attributes.hvac_action;
if (state == 'off') return 'mdi:power-off';
if (action == 'heating') return 'mdi:fire';
if (action == 'cooling') return 'mdi:snowflake';
if (action == 'auto') return 'mdi:autorenew';
return 'mdi:pause-circle';
btw there’s a sublet difference between == and === , in this case the == suffices
update
couldnt resist:
var action = entity.attributes.hvac_action;
var icon = {off:'mdi:power-off',
heating:'mdi:fire',
cooling:'mdi:snowflake',
auto:'mdi:autorenew'}
return icon[action] ? icon[action] : 'mdi:pause-circle';
should do it. Note the states needn’t be quoted, only the icons. Using this in the button-card only requires the enclosing [[[ and ]]]
Sorry, I don’t understand the point of your suggestion. It doesn’t matter if it’s ==
or ===
because the entire template is ignored if Custom-UI is not installed. That’s been the point of this exercise, to eliminate the use of Custom-UI and replace its functionality with custom cards.
In addition, the triple-equal was just something I copy-pasted from an example many, many versions ago and have left it that way ever since. I understand the variable’s type is unlikely to be anything other than string thereby making the use of triple-equals superfluous. Nevertheless, whether double or triple, it’s moot.
Not to mention == vs === is pretty much meaningless with strings that aren’t numbers.
Another vote for button-card from me, the damn thing is so configurable its scary!
It changes icons and their colours, calls appropriate more-info
.
I had to create an internal template sensor to get required state string from generic_thermostat
:
- platform: template
sensors:
thermostat_current_state_and_temp:
value_template: >
{% set state_object = states.climate.thermostat %}
{{ state_object.attributes.hvac_action}} {{state_object.attributes.current_temperature}} °C
and here is the button-card
in entities card
:
type: entities
entities:
- type: 'custom:button-card'
style: |
ha-card {
box-shadow: none
}
entity: sensor.thermostat_current_state_and_temp
tap_action:
action: more-info
entity: climate.thermostat
name: |
[[[
return states["climate.thermostat"].attributes.friendly_name;
]]]
label: |
[[[
return states["climate.thermostat"].state + ' ' + states["climate.thermostat"].attributes.temperature + '°C'
]]]
show_state: true
show_label: true
size: 60%
state:
- operator: template
value: |
[[[
return entity.state.startsWith('off');
]]]
icon: 'mdi:power-off'
color: gray
- operator: template
value: |
[[[
return entity.state.startsWith('idle');
]]]
icon: 'mdi:sleep'
color: black
- operator: template
value: |
[[[
return entity.state.startsWith('heat');
]]]
icon: 'mdi:fire'
color: red
styles:
grid:
- grid-template-areas: '"i n s" "i l s"'
- grid-template-columns: 14% auto auto 10px
card:
- font-size: 14px
name:
- justify-self: start
- text-transform: capitalize
label:
- justify-self: start
- text-transform: capitalize
- color: var(--secondary-text-color)
- font-weight: 300
state:
- justify-self: end
- text-transform: capitalize
That’s my first button-card so obviously it can be done better, I just wanted to see if it’s possible to make a functional one.
All in all it is possible, button-card is a very powerful thing.
I appreciate the example you shared. However, the difference in complexity between what you posted and what I currently do to achieve the same effect, has led me to decide that I will continue using Custom-UI.
Hopefully, by the time I absolutely must discard Custom-UI, there will exist a compact way in Lovelace to achieve my modest requirements.
Agree, I wish it could be easier… on the other hand, I added some new functionality to it (on/off by hold) and it’s literally a couple of strings so that’s the core config that takes the most time and space.
It’s definitely possible to avoid creating additional sensors (using custom_fields) so it looks better but the whole thing is almost 100 lines… that’s the price for flexibility (as it’s really flexible in terms of what is configurable and where we can place it on the card but requires some JS knowledge - grid etc).
for individual buttons this can be a pain, but when you have a set of identical buttons for lights/switches what have you, you can create a button-card-template, or a decluttering template, or even use Lovelace_gen to cut code lines drastically.
Still no replacement for custom-ui, (to get back to topic) but very nice indeed.