Dashboard Card Blueprints

Feature Requests
, ,
1

As a user building various similar dashboards for a number of other users, I would like to have reusable dashboard cards. This is conceptually similar to React’s component structure.

I am suggesting that we allow the creation of reusable custom cards that consist of other existing cards via Blueprints. This is not a duplicate of 272211, as this is not solved by custom strategies. Custom strategies allow reusable dashboards. I am suggesting reusable cards.

In effect, this is the same as importing custom front-end components from HACS, except that the cards consist entirely of other cards and are managed in the Blueprints page.

One further clarification: I would like the blueprint to mirror other blueprints in that certain values can be templated and others can be defined by the user. The outcome would be a new card when building dashboards that can be used across many dashboards while still being maintained in one location.

EXAMPLE:
If I were to create a horizontal stack with various badges that conditionally show various alerts to the user (battery replacement, moisture sensors, security alerts, etc), I would be able to group that into a single card with only a few input values (a list of entities or areas that I care to be notified about), and then reuse it on several different personalized dashboards. Make note of the fact that the new card does not introduce new JavaScript, but rather uses the existing cards, namely, the horizontal stack, the conditional card, and badges.

EDIT: Additional Example:
As seen here, a “Person Card” was created that contained a button-card and tons of styling modifications. The only information needed to create a new card was a person entity with an associated device. This feature would allow simplifying all of the YAML into a new card with the only field being “person entity”. Any modification to the blueprint applies to all cards.

EDIT 2:
Here is a custom component that does something similar. The difference is that this feature would be on a global scale, whereas the custom component is local to a dashboard only.

2

I am going through the pain of this right now as I am reusing many components across dedicated dashboards for various devices… Upvoted

5 Likes
3

I would love to see this implemented. This will make dashboard so modular

1 Like
4

The decluttering card which you have also linked above does already 90% of the job. What prevents this card from being modular across dashboards is the missing feature of being able to include the decluttering templates in regular dashboards.

See here. But this solution using an !include pattern in a dashboard config currently works only for dashboards which are defined in yaml files, but not in all dashboards which are created via the regular Home Assistant UI.

5

Because “include” may work in yaml files only.

6

my ‘take’ on what these could be…

Dashboard Card Blueprints (DCBs) are a ‘light weight’ integration like Automation Blueprints.

The UI and creation method would be the same allowing for the same ‘fill in the blank’ style UI.

DCBs would also allow for auto install and modification of scripts, automations, scenes when they need to accompany the Dashboard Card. Thus, install, config and (when needed) removal would automatically handle these also.

If Dashboard Card Blueprints (DCBs) were implemented just like Automation Blueprints (visual user interface) they’d be used at least as much as Automation Blueprints… which I think are critical to HA, and are a great way to help everyone (new and experienced users).

Creating and using DCBs, in most cases, would be less effort vs automation blueprints.
… Dashboard cards typically have fewer options/variables than automations (YAML code is far smaller than complex automations).
… Dashboard cards are ~95% visual format/layout (which could all be pre-set in the DCB or have some easy options if the author chooses) and the remaining 5% is sometimes logic (conditional show/hide, string substitutions, etc). So the main user input would be to select the entity, or set of.

This results in providing plug-in-play for the hardest part of making dashboard cards… finding which integrations to use, and how to combine one or more (custom) integrations syntax variations and/or templating, and the visuals which card be difficult due to syntax and/or idiosyncrasies in CSS/Markdown/HTML and card-mod… including that some integrations do no support some/many things that others do … and all the variables/combinations of these together can be extremely challenging.

Example one card I just created that I would make into a blueprint which combines multiple HA elements (Helpers, Automations, Dashboard card)…

7

I just made a card with mushroom template, then copied it 4 times changing the names of the entities. DCBs would be perfect for this situation :ballot_box::heavy_plus_sign::one:

8

Currently it can be achieved by a custom decluttering-card in most cases (unless you need a “blueprint” for a whole dashboard or a view).

9

Well Feature requests in this forum are dead. No longer used. These should be set to read only TBH.
If you want to see something like this add a request or vote up a existing request here: home-assistant · Discussions · GitHub

10

I didn’t think decluttering_templates would work as I don’t use yaml, but editing the whole dashboard raw allowed me to define my template and it worked :slight_smile:

This monstrosity is pretty much the same as the person tile, but uses the bermuda location
to show which room a person is in when they are home. Two levels of templating in one go is a bit of mess though.

decluttering_templates:
  person_card:
    default:
      - person_entity
      - bermuda_entity
    card:
      type: custom:mushroom-template-card
      icon: mdi:mushroom
      picture: '{{state_attr("[[person_entity]]","entity_picture")}}'
      primary: '{{state_attr("[[person_entity]]","friendly_name")}}'
      secondary: >-
        {% if states('[[person_entity]]')=='home' %} 
          Home
        {% if states('[[bermuda_entity]]') != 'unknown' %}
          {{"/ "+states('[[bermuda_entity]]')}}
        {% endif %}
        {% elif states('[[person_entity]]')=='not_home' %}
          Away 
        {% else %}
        states('[[person_entity]]')
        {% endif %}
        {% if states('[[person_entity]]')!='home' %} 
          ({{time_since(states.[[person_entity]].last_changed) }} ago)
        {% endif %}
      badge_icon: >-
        {%- if states('[[person_entity]]')=='home' %}
          mdi:home
        {%- elif states('[[person_entity]]')!='not_home' %} mdi:map-marker
        {%- else %}
          mdi:crosshairs-question
        {% endif %}
      badge_color: >-
        {%- if states('[[person_entity]]')=='home' %}
          green
        {%- elif states('[[person_entity]]')!='not_home' %}
          blue 
        {%- else %}
           grey 
        {% endif %}
      tap_action:
        action: navigate
        navigation_path: /lovelace/map
      icon_tap_action:
        action: navigate
        navigation_path: /lovelace/map
      card_mod:
        style: |
          ha-card { 
            background: 
              {% if is_state('[[person_entity]]', 'home') %}
                rgba(0,255,0,0.1)
              {% elif states('[[person_entity]]') != 'not_home' %}
                rgba(0,0,255,0.2)
              {% endif %} !important; 
          }
11

Just discovered that GitHub - brunosabot/streamline-card: Streamline your Lovelace configuration with with a card template system. is where its at, thankfully the migration from decluttering was as easy as changing the name :slight_smile: