Lovelace: Flexible Horseshoe Card (Donut graph, flexible layout, multiple entities, actions & animations), including next-gen experimental examples

Lovelace: Flexible Horseshoe Card

Flexible looks-like-a-horseshoe card for Home Assistant Lovelace UI

The Lovelace view of the above examples is in the repository in the examples folder.

So you can see how these layouts are done


Introduction

The flexible horseshoe card can display data from entities and attributes from the sensor and other domains. It displays the current state and for the primary entity it fills the horseshoe with a color depending on the min and max values of the state and the configured color stops and styling.

The main perk of this card is itā€™s flexibility. It is able to position a number of things where YOU want it using a layout specification for each object you want on the card:

Feature Description
Any number of entities For each entity, the attribute, units, icon, name, area and tap action can be specified.

There is currently no limit imposed on the number of entities in this card. Iā€™m using max. 3 entities in the examples, but there is no problem using more.
Any number of circles, horizontal and vertical lines To function as a divider between values or background for values.
The layout of the card You can specify each object with a relative position on the card
Animations, dynamic behaviour You can specify what happens if an entity changes state like change color, or execute a CSS animation. There are predefined animations.
Several ways to color the horseshoe From single, fixed color, to a gradient depending on a list of colorstops
Actions Handle click actions per entity to for instance switch a light on/off

Notes

This is my first card ever.
Visit the Github repository for installation and usage instructions. I did my best to describe all the options, and provide 12 examples which include the Lovelace View I used to test this card.

Iā€™m pretty curious what other people can make with this flexible card!

Iā€™m currently on holiday, so I wonā€™t be visiting the forum every hour :smile:

39 Likes

Amazing! Something to play on the coming weekend! :slightly_smiling_face:

Excellent documentation too. Great examples.

Looks great. Going to try it out. The animation looks like fun to. :+1:

Absolutely agreedā€¦
And thanks for including the resources at the end. There are some gems in there.

Excellent ! Great job man, we want more like this :100:

This looks amazing! Definitely giving this a go when I get home!

This is quite the complex card. If I may make one suggestion for the github page - considering the large number of required fields, it would be extremely helpful if one of the YAML examples included the entire required structure of the horseshoe declaration without optional settings. This way, everyone has a starting point that not only will work (assuming the requirements have been properly met) but will also serve as a starting point for customization.

That is a good point. I realized that when I finished the documentation :blush:

My idea is to make such an example AND show some decluttering templates. The idea is that you make several decluttering templates where you define the layout (and thus the number of sensors that the layout supports, including animations and such) and options. Then in your view, you only enter the entities and the scale.

The first card in the example is already a very simple card with one entity. If you look at this card, you see this definition:

- type: 'custom:flex-horseshoe-card'
  entities:
    - entity: weather.dark_sky
      attribute: temperature
      decimals: 1
      name: '1: Ut Weer'
      area: De Maan
      unit: 'Ā°C'

  layout:
    states:
      - id: 0
        entity_index: 0
        xpos: 50
        ypos: 60
        styles:
          - font-size: 3.5em;
    areas:
      - id: 0
        entity_index: 0
        xpos: 50
        ypos: 35
        styles:
          - font-size: 1.5em;
          - opacity: 0.8;

  horseshoe_scale:
    min: -10
    max: 40
  color_stops:
    10: '#ff0000'
    15: '#008000'
    18: '#0000FF'
  style: |
    ha-card {
      box-shadow: var(--theme-card-box-shadow);
    }

If Iā€™m right, but I have to check this, if this would be defined in a decluttering template, the layout and colors would go to the template, leaving only the following definition for this card:

- type: 'custom:flex-horseshoe-card'
  entities:
    - entity: weather.dark_sky
      attribute: temperature
      decimals: 1
      name: '1: Ut Weer'
      area: De Maan
      unit: 'Ā°C'
  horseshoe_scale:
    min: -10
    max: 40

Converting this to a decluttering-card would give you the following definition (decimals set to 1 in the template too):

- type: custom:decluttering-card
  template: flex_horseshoe_template_layout1
    variables:
      - entities:
          - entity: weather.dark_sky
            attribute: temperature
            name: '1: Ut Weer'
            area: De Maan
            unit: 'Ā°C'
      - horseshoe_scale:
          min: -10
          max: 40

And if this wouldnā€™t be an attribute, but a sensor, the attribute and unit would go out also. And if you would use the friendly_name and not use the area attribute, it would look like this:

- type: custom:decluttering-card
  template: flex_horseshoe_template_layout1_1entity
    variables:
      - entities:
          - entity: sensor.hall_temperature
      - horseshoe_scale:
          min: -10
          max: 40

So, that would be the simplest form using a decluttering template.

I think that would answer your question?

@daphatty, I have added the below part in the Github documentation. The rest - yaml definitions with only the required structure will follow.

Maybe I should move the 12 examples to the top of the documentation and the description of all the options after the examplesā€¦


Main Card required, defaulted and pure optional sections

The Card Options are divided into Sections. To give a clear overview of which of the sheer number of sections are required, optional with defaults and optional, the following table is made.

The examples section shows 12 examples of card definitions, from basic to using all available options!

Note: The examples will get decluttering templates as an example too, to show how you can better manage and maintain the all the card layouts without loosing overview in the Lovelace views.

Each section might have itā€™s own required, defaulted and optional properties.

Name Required Optional /w
defaults
Optional Since Description
type v0.8.0 custom:flex-horseshoe-card.
entities v0.8.0 One or more sensor entities in a list. See entities section for requirements.
layout v0.8.0 You MUST of course specify where each item is positioned on the card. See available layout options for requirements.
horseshoe_scale some v0.8.0 Specifies the scale configuration, like min, max, width and color of the scale. See horseshoe scale for requirements.
color_stops v0.8.0 Set thresholds for horseshoe gradients and colormapping. See color stops for requirements.
horseshoe_state v0.8.0 Specifies the horseshoe width, and fixed color. See horseshoe state for requirements.
show v0.8.0 Determines what is shown, like the scale and the horseshoe style. See available show options for requirements.
card_filter v0.8.0
entities tap_action v0.8.0 How to respond to a mouse-click or tap. See available tap actions for requirements.
animations v0.8.0 You can specify animations / dynamic behaviour depending on the state of an entity. Circles, lines and icons can be controlled depending on the state of a given entity. See available animation options for requirements.

Looks greatā€¦
I follow the examples and the results

Ah! Thanks for reminding me to remove theme dependencies!
You now have white text on an white background :smile:

Will fix that after dinner!

@vipk31 I have uploaded a new view. I replaced specific extended theme colors with fixed values. If you can check once again if this is really fixed?

1 Like

I am also experiencing the white text on the white background. Did you update the HACS version number ?

@AmoebeLabs - Can I just say that I LOVE your layout implementation? It took me a while to understand how to use it, but once I understood I found myself wishing ALL cards worked this way. Any chance we can get a version of this card without the horseshoe? Iā€™d LOVE to be able to simply lay out attributes on a card using only YAML and X/Y coordinates. (I hate CSS with a passion.) You could call it flex-card. :smiley:

Great work! This some inspirational stuff here!

Oh yes, I thought that it was only a problem with the examples, but some css in the card itself was also causing this problem. Should be fixed now. Have tested with 5 themes, including the default hass theme.

image

New version 0.8.1 is seen by HACS as you can see.

You must download a new examples view also!

That is great to hear. I wonder what you are creating with this card!

When I started this card - with the horseshoe - I couldnā€™t decide which layout I preferred, so I decided to make it flexible, ie a configurable layout with all sorts of entities, attributes and some graphics (lines, circles). Then someone in the System monitoring - How does your look? thread asked for the possibility to create actions, ie switch lights or an appliance.
And while making those work, the animations where added too, including pre-defined animations.

In the beginning I could indeed disable the horseshoe, but what is a horseshoe card without a horseshoe I thought :thinking:

That would look silly :laughing:

image

I can release this version of course by changing two lines of code. But then you still have to fill in the requirements for the horseshoe (scale, colors) but it is invisible and you could ā€˜abuseā€™ the card for you own goals.

Releasing just a flex card might be a nice ideaā€¦

Thanx! It was fun making this card. And I truly wonder what kind of layouts others will create.

1 Like

I think the easiest way to describe the usefulness of Flex card without the horseshoe is to use an example from the excellent button-card.

When @RomRider took over development of button-card, an amazing thing occurred quite organically. A card that was originally meant to serve as a button was also being used to display at-a-glance information using several attributes.

An example from button-cardā€™s github page.

image

For anyone who was familiar with CSS Layout Grids, this was a godsend. For those of us who are less CSS inclined, however, it has been a serious learning curve.

This is where your coordinates-based layout method comes in. It enables those of us who are less inclined to working with CSS Grids to tweak layouts to our hearts content using concepts that everyone with an understanding of basic algebra can understand.

I implemented this card for my humidity management area. I was wondering what are you thoughts on the icon automation. For example, I have a switch with a tap-action which can toggle the switch. But this would change the state of the switch. The icon automation only sees what the state was with the card was initially displayed. After I have toggled the switch the icon automation does not get toggled. Was this the plan?

If I refresh the page the card works great since it relooks at the state of the switch in my case.

Nevermind. Mystery solved and it had nothing to do with this card.

Thanx for the explanation! I understand it now :slight_smile:
As I said, I can release a version of the horseshoe where you can disable displaying the horseshoe. You still have to define the colorstops and scale. But if you do that in a decluttering template, your view wonā€™t notice those dummy requirements.

In a later stadium I could release a card without the horseshoe.

As you can see in the light button examples (11 and 12), the icons change color according to the state of the light. So I think you have a mismatch with the animation_idā€™s or entity index of some kind.

The animation_id in the layout should match the one in the animations section for that icon state. AND the entity in the animations section (entity.1 in example 11) should match the index in your entity list.

From example 11:

The state second entity (index 1), the light, is used for animation triggers

         entities:
            - entity: sensor.memory_use_percent
            - entity: light.1st_floor_hall_light              // is entity.1 in the animations section

In the animations section, you see the processing of a state change for entity.1.
What you also see is that it is linked to animation_id: 0. This should match the id in the layout.

          animations:
            entity.1:
              - state: 'on'
                icons:
                  - animation_id: 0
                    styles:
                      - fill: white;
              - state: 'off'
                icons:
                  - animation_id: 0
                    styles:
                      - fill: var(--primary-text-color);

The layout of this icon refers to animation_id: 0

  layout:
    icons:
      - id: 0
        animation_id: 0

Hope this helps!