Thanks. I’ll be gleaning over the links you listed and working with the Template tab a lot to see what else I can do with templating as opposed to simple automation. In every Home Automation system I’ve worked with before there was always a hard line between what you could do and what you couldn’t do because you weren’t in charge of the interface. The thing I like about HA is that this isn’t the case. The only caveat is the learning curve. As long as I stick to the line that I’ll do things when I can figure out how instead of artificially wanting it done now, I’ll be OK. (It’s already miles ahead of my old system.)
1 Like
Here’s what I ended up with:
sensor:
- platform: template
sensors:
family_sensor:
value_template: >-
{% set items = states.person %}
{% set all = items|length %}
{% set home = items|map(attribute="state")|select("equalto","home")|list|length %}
{{ "none home" if home == 0 else "all home" if home == all else "some home" }}
icon_template: >-
{% if is_state('family_sensor', 'none') %}
mdi:home-outline
{% else %}
mdi:home
{% endif %}
I’m really liking the power of templating. The one downside is that it requires a reboot to reload configuration.yaml when I change something.
I haven’t moved the coloration yet. I’m thinking it’s better to have that in the Card Configuration anyway.
I’m thinking I might move the device templates to a template.yaml file to keep my configuration.yaml cleaner and I see myself adding a lot more of those clever templates over time.
1 Like
No need to reboot if you’re on core 0.117.x (or maybe 0.116.x; I forget when they added it) you can use the “Reload Template Entities” link on the Configuration => Server Controls page.
I have my configuration.yaml split into multiple files. It’s nice to have smaller files to work with and easier to find what I’m looking for. I have enough entity configurations that I have a folder for each type (sensors, switches, etc.) and a file for each device (some files have more than one entity, but they are usually coming from same device source). I got some inspiration of how to organize my configs from frenck’s config repo, which is really comprehensive. This video that he did with Dr. ZZS is worth watching for great yaml organization tips.
I also recently started managing my dashboards as yaml files too, so that I can share content across different dashboards. My custom button card templates in total are over 1000 lines and it was getting to be annoying making changes in one dashboard and then having to copy-paste the whole set of templates to another dashboard via the raw configuration editor. Plus I was having to copy-paste a bunch of my dashboard cards between views and dashboards any time I changed one of them. Maintenance headache for sure. By taking manual control of the dashboards as files I am able to organize everything as separate files and use !include to insert them into any dashboard. The tradeoff is not being able to edit them in the UI, but I can edit the files and choose the “Refresh” menu option to reload the changes. The “Refresh” option appears in the same place as the “Edit” option in the UI, in the triple-dot menu.
Regarding my previous comment about not being able to edit yaml file dashboards in the UI, I found a workaround for at least experimenting in the UI on a yaml file dashboard. You can’t save changes in the UI, but you can experiment with different settings and then copy the revised yaml to your appropriate file.
1 Like
Thanks for both of these tips. It’ll speed up my tinkering process a fair bit.
I’m especially enthused by the the idea of sharing content across multiple dashboards. I do a lot of copy/pasting and I was wondering about a way to not have to duplicate so much code. One of the areas where that happens a lot is in my presence sensors since all three of us have some zones in common. Currently those are all in the same file, but I could fork them and use common includes… 
I’m very glad I took the time to split out my dashboard configs as files. It was a little challenging to decide on an organization scheme, but I finally settled on one that works for me.
It’s probably worth catching up on the video I linked to in prior comment before diving into the rest of this comment
I created a dashboards folder in the config folder to organize all the dashboard files. In that folder I have a dashboards.yaml file that defines what all the dashboards are, a separate folder for each dashboard, and a common folder where I put things that are shared between dashboards.
In the common folder I have 3 folders:
button-card-templates: 1 file for each template; name of the file is the name of the templatecards: 1 file for each top-level card that I want to use in multiple places- most cards are self-contained, but I have one card that is a composite of many other cards, so I have a subfolder of the card name containing a file for each child element
- cards can
!includeother cards in this folder if you want to have a shared card and a shared composite card containing that card at the same time
panels: 1 file for each card that I use inpanelmode on my tablets- these are technically just more cards, but they only look good in panel mode so I organize them separately
In each dashboard’s folder I have at a minimum a dashboard yaml file. For my dashboards that only use shared panels, that’s all I really need. All of my dashboard files point to the ../common/button-card-templates folder and defines any views they need.
For dashboards that have more involved config, I have subfolders to organize things:
views: 1 file for each viewcards: 1 folder to contain cards for each view; named same as the view file
All that works well for my normal dashboards. I have a special experiments dashboard that has one additional organization technique. It needs to use the same common button-card-template files, but I also need to experiment with those templates without disrupting other dashboards. What I did was add another folder to the experimental dashboard’s folder called button-card-templates and created a linking file for each template file in the common/button-card-templates folder. What these linking files allow me to do is get all the same templates by default, but if I want to tinker with one I comment out the !include line and paste in a copy of the corresponding common template yaml and do my tinkering safely. When ready to deploy the template change to all of my dashboards I copy the yaml back to the common template file and delete it from my linking file (and re-enable the !include line).
Here is how things are linked together:
Tip:
!includepaths are relative to the file containing the!include, but thefilenamevalue indashboards.yamlis relative to theconfigfolder regardless of where thedashboards.yamlfile is.
# configuration.yaml
lovelace:
mode: storage
dashboards: !include dashboards/dashboards.yaml
# dashboards/dashboards.yaml
#NOTE: changes in this file require restart, but changes in dashboards
# can be refreshed with the UI triple-dot menu option "Refresh"
dash-homeowners:
mode: yaml
title: Homeowners
show_in_sidebar: true
require_admin: true
#note: this path is relative to config folder, not folder where this file is
filename: dashboards/dash-homeowners/dash-homeowners.yaml
dash-experiments:
#...more config...
dash-lounge:
#...more config...
#...more dashboards...
# dashboards/dash-homeowners/dash-homeowners.yaml
title: Example
button_card_templates: !include_dir_named ../common/button-card-templates
views:
- title: Main
path: main
panel: true
cards:
- !include ../common/panels/lounge.yaml
# dashboards/dash-experiments/dash-experiments.yaml
title: Experiments
button_card_templates: !include_dir_named ./button-card-templates
views: !include_dir_list ./views
# dashboards/dash-experiments/button-card-templates/standard.yaml
# To safely experiment on a template without disrupting other dashboards,
# comment the line below and copy the template into this file.
!include ../../common/button-card-templates/standard.yaml
# dashboards/dash-experiments/views/pool-ui.yaml
title: Pool UI
path: pool-ui
cards: !include_dir_list ../cards/pool-ui
# dashboards/dash-experiments/cards/pool-ui/0.todo.yaml
# Tip: naming views and cards with a number prefix helps put them in a
# specific order in the UI. You don't need to do that if you don't
# care about the order.
# I put a copy of this card in every view's card folder for the experiments
# dashboard for convenience. It has the gui-sandbox card and a TODO list to
# help me remember what I was doing when I come back to it later.
type: vertical-stack
cards:
- type: custom:gui-sandbox
- type: markdown
title: TODO
content: |-
* some task I was thinking of...
* another task...
* a related thought...
4 Likes
Excellent. My system is considerably smaller so my organizational needs are much less tiered but the dashboards.yaml separation that allows you to change the dashboards themselves and then just refresh sounds like a very good thing indeed.
I’m definitely past the point were doing things in the UI makes any sense. (I had been spending so much time in the Raw Configuration Editor anyway.)
Since my last comment, I’ve been organizing my yaml files and did end up using a dir_merge_list for automations so far. That went fabulously well. I haven’t split up my dashboard just yet though.
What I did have trouble on (and basically gave up on) was trying to create a “person_button” template that would work for all three of my people and show various locations properly. Here’s the current coding:
type: 'custom:button-card'
template: container
color: dimgrey
name: Indicators
custom_fields:
buttons:
card:
type: horizontal-stack
cards:
- entity: person.russell_smith
name: Russ
template: standard-button
type: 'custom:button-card'
aspect_ratio: 1/1.1
styles:
name:
- font-size: 0.47em
variables:
background_color_on: darkgrey
background_color_off: darkgrey
text_color_on: yellow
state:
- value: home
id: value_on
name: Russ home
icon: 'mdi:home'
- value: not_home
id: value_off
name: Russ away
icon: 'mdi:home-outline'
- value: ICC
name: Russ ICC
icon: 'mdi:office-building'
styles:
card:
- background-color: darkgrey
name:
- color: slateblue
icon:
- color: slateblue
- value: ACC
name: Russ ACC
icon: 'mdi:church'
styles:
card:
- background-color: darkgrey
name:
- color: purple
icon:
- color: purple
- value: Linwood CC
name: Russ Linwood
icon: 'mdi:church'
styles:
card:
- background-color: darkgrey
name:
- color: purple
icon:
- color: purple
- value: 2ndHelpings
name: Russ 2ndHelp
icon: 'mdi:pot-steam'
styles:
card:
- background-color: darkgrey
name:
- color: brown
icon:
- color: brown
- value: Kalalas
name: Russ Kalalas
icon: 'mdi:human-male-boy'
styles:
card:
- background-color: darkgrey
name:
- color: saddlebrown
icon:
- color: saddlebrown
- value: Malumbas
name: Russ Malumbas
icon: 'mdi:human-female-boy'
styles:
card:
- background-color: darkgrey
name:
- color: saddlebrown
icon:
- color: saddlebrown
and then repeat all that for each other person. It’s repeated exactly because today my wife visited at the ICC and her icon turned grey and unspecified, so I figured I’ll have to have all my zones implemented for each person.
What I’d love to do is create a “person-button” with all the state coding so it can be edited once and not duplicated over three people. I tried setting up another variable (person_name), but every attempt at using it would either show up literally: {person_name} home or as a blank. My efforts at following the use of variables in the code that already used the existing variables was for naught. Clearly I’m missing something.
It definitely should work. When you used the variable, were you putting it in a javascript template and using a return statement to return the desired string? For example:
name: '[[[ return variables.name + " home" ]]]'
I was close. I didn’t quite have it like you put it there. I’ll give that a shot…
…and it works! I just had to remember to put in the id: value_on and id: value_off items under the first two states.
Thanks one more time for your help.
1 Like
Hello… @ktownsend-personal Thank you Keith for having “summarized” the possibilities of button-card. I am using button-card features with templates a lot, it is very powerful… My dashboard is full of button cards (resuming nearly on one view what I have in 15 others), this is giving me back a lot of information for the two locations where I am using HA (alarm status, elements on or off, if some elements have automations and the status of these automations: on or off, problems, availability HA upgrades, status of connections on the network, electrical power consumption/production, AirCo/heaters status… I started to use button-cards a few months ago and I am still working on it to put more information in this dashboard…Here is a print screen of my dashboard… Wish you a lot of fun and satisfactions with button-cards.
5 Likes
My climate button is the most intricate use of the custom button-card I have done so far. The possibilities are endless 
Hello, dumb question from nub. i bookmarked all your creation here and so far my lovelace looks great than before. but my question is can this button combined with fan control entity row to show a compact graphical control row for 3 speed fans ? thanks
Do you mean something like what I have at the bottom of the picture in the original post? It can be done with 5 custom button cards. One as a container for the other four. Check out the “Multi-option Button” section in the original post.
oh sorry, i didnt see there is fan option already at original post 
will working out fan button next. thank you for inspiring, this is my result so far
That example is using show_label: true to activate the 2nd line of text. You can put different text there by specifying label: whatever text you want, or in their case they are using show_last_changed: true to get that value from the entity.
That’s what I needed. I’m going to have to dig in deeper to the code to see if there are other activators I missed.
Thanks again.
Thanks for the great write-up. The more I use Home Assistant, the more I find out what I didn’t know I could do. I have used the custom button card for a while, but never took the time to learn the power of it. Thanks for posting your templates. Do you have one that can be used to replace the built in badges? I use the badges for a quick glance at different sensors. The custom button, looks like it would work better.
I’m using my ‘alerter’ template for some of my sensors. You may find some inspiration there. I’m doing a flash animation when doors are open. I haven’t ever used the built in badges because they don’t look good to me.