no, this is not the case. I was experiencing issues with all of these template running inside the button card configs. frontend having to calculate all of that display continously is a serious task. Though, I suspect if one doesn’t have that many entities, the system might fare well enough.
In this case, using these backend sensors, the buttons only have to show the state, which is much easier… I also think is is of a better architecture tbh, have the backend and the frontend do what they are designed for, makes for a better system performance and reliability.
talking about templates, you might want to check these for the existence of an ‘else’ clause, which is really necessary to catch unforeseen situations/states. Also you could start using the states() notation:
in stead of
Well I didn’t know this either . I did see those docs but only very briefly. I will change my sensors and see what happens . Thanks for taking the time to help out an amateur xd
its very useful to save space and make sub-menu that displays in the same space, specially if you have alot of thing to display in the same area. I use it to diplay devices/ lights, etc withen the floor
Also another suggestion that I have and working so great, instead of using name or friendly names i added all entities to secrets so i can change the names there without having to change them everywhere and i point them when ever i want to use them as !secret name, here is an example of my secrets temps and where i use them
Ah ok, I understood you wrong. However the secrets file to have friendly names? I like the solution, but actually there is already a file specifically for that (customize.yaml). I use that and define most of the names and icons in there.
Though I did think of using the secrets file to put in entities. The problem is that I use categories for lights (e.g. bedroom). I can make it easier to set up if I take out categories and have buttons arrange like Apple’s Homekit does. Though I love the ideas. I will play around with it. Thanks
but, do note this doesnt auto update unfortunately… sorry I forgot about that. Still, adding this small automation does the trick, and makes it much easier than coding all the individual entities.
dont be sorry! be happy, you’re about to embark on a journey about one of the most powerful aspects of HA!
All the frontend niceties in Lovelace are nowhere without great backend templates
You are correct, well it’s just a lot of work haha. Been working on HA for months now and I think my setup looks decent on the frontend. It’s just that I want optimizations on the backend. I’d love backend material to be like my button template. I use a single template for every button (even the ones with the notification badge).
what’s the correction? I’ve made my own group.all_lights_only group because in the group.all_lights (not group.alights) group (which is soon to be deprecated…) also light groups are included.
btw, the whole idea behind my suggestion to @jimz011 was because he mentioned including and excluding specific entities for his sensors.
Adding only the desired entities to a group, is what this is all about, and makes it so flexible. Of course we can also use the default all_* groups (for now)
Was the automation trigger without the event_data? because i tried to make it trigger without success, so I added the event_data and took off the condition and worked fine. I’ve just used the Ha group , but i believe it should work for any group.
this wont work, because the trigger now is set to the group, and that wont change state when one of its entities changes, unless they go all off or on, or change from that state.
thats why the whole effort is done to use the condition, in which you set when the state change trigger is actually passed (evaluated to true) and then fires the action.
condition:
condition: template
value_template: >
{{ trigger.event.data.entity_id in state_attr('group.all_lights_only','entity_id') }}
is therefor necessary, if you want to check for items of that group, sing the state_changed trigger
if you want a bit of fun, and have more groups you want to monitor…:
- alias: 'State changed (all)'
id: 'State changed (all)'
initial_state: 'off'
trigger:
platform: event
event_type: state_changed
condition:
condition: template
value_template: >
{% for x in
['family',
'hubs_binary_pinged',
'critical_devices_state',
'media_player_media',
'device_tracker_media',
'all_lights_only',
'iungo_switch_switches_template',
'iungo_switch_appliances_template',
'binary_sensors_active_template']
if trigger.event.data.entity_id in state_attr('group.'+x,'entity_id') %} true
{% else %} false
{% endfor %}
action:
- xxxxx
as said, I run my counters using python scripts, and the above automation calls a python script to do so
I’ve tried the automation I changed and tested when turning lights on/off and the counter changes counting how many lights on!. and I agree with mine it will count only lights in this case( since my group is only lights), but also can use en event_data a series of entities too if needed to make them all as one set of ON devices.
could be different the automation when you are calling python script? don’t know the true, but it’s good to know.
it’s just what I’m using and worked for me, please if you can add the sensor and automation i have and check if they works too, just to make sure i works
Thank you for clarifying.
First i must say that i’m never had any experience with code at all.
i love your view, and i’m learning slowly,
i watched you last video, and i need your help with the following :
in the video at 1:59 seconds you are demonstrating the light group, when you press it shows the lights that currently on. when you click on it, i can see that all background is transparent and only the glance card shown in gray color that matched your entire theme, i tired look at your examples ant got lost totally , my bad i’m total noob.
. I did see those docs but only very briefly. I will change my sensors and see what happens 
. Thanks for taking the time to help out an amateur xd
, my bad i’m total noob.
