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.
I’ll start playing with it . I liked using the badges as they are small and give information at a glance. My first go at the custom button card was much bigger, and harder to place where I wanted it on my page.
I created a template yaml.file that gets loaded via the “package”. No errors when I check the config, but when I reference the template I get Button-card template ‘standard’ is missing! I tried different ones of yours, some others from other people and the lovelace button card never finds the template name. Obviously I am not understanding something and I have configured something incorrectly. Any idea on what?
@bschatzow, It’s not working because the custom button card templates don’t get loaded via “package”. They need to go in your raw dashboard config, typically at the top. If you use the UI to design your dashboards, first get into edit mode in the UI, then click the same 3-dot menu icon again and choose Raw configuration editor. I usually put it right below the title property. Just add a new property button_card_templates: and below it you define your named templates.
For detailed info on how to define templates, there is a good section about it in the documentation for the custom button card here . In general, you define the template the same as you would if you were using the element in your dashboard, but you leave out the settings that would change (like entity). Then, when you use a custom button card in your dashboard you simply refer to your template by name in the template setting and add the unique settings for that button.
I don’t have anything in my config.yaml file except different includes, package etc. Not understand why this doesn’t work the same as other sensors I load via template yaml files.