Gauge Card: how to get a gradually changing color?

I’m also experiencing the same issue

same here, white no gradient.

Try Firefox as your browser.
Googling a little on SVG’s, it seems that Chrome, Edge, Safari may not support this type of linear gradient in SVG’s

That is not the solution of course… :slight_smile:

1 Like

I’ve tried quite a few ways now, including firefox, maybe a HA update patched this CSS behaviour?

I tried implementing the script that I posted to apply green-to-red color gradient icon color, but it only returns a single color. Green-to-red icon color gradient template (battery percentage)

I imagine that something like this might be able to be implemented but it would have to be added to the card’s code. Maybe some sort of “presets” could be defined within the code to allow a user to choose what type of gradient such as red-to-green (for battery), green-to-red (for utilization), blue-to-red (for temperature), color temp.

As others have mentioned, the SVG method only seems to work in Firefox. I also tried Edge, Chrome, Silk and FKB without success.

image
Shown: Firefox (card-mod method) left; red-to-green script via card-mod method right.

Looking at @thomasloven’s FontAwesome integration (GitHub - thomasloven/hass-fontawesome: 🔹 Use icons from fontawesome in home-assistant), he mentions:

IMPORTANT: As the note above implies, SVG can contain CSS and Javascript, and thus shall be considered unsafe. Home Assistant normally protects you from this by unly using a very specific part of the SVG file, but using the #fullcolor suffix circumvents this protection. I have tried adding another layer instead, but as those things go, you’re only safe from the things you know.

In short: Only do this with icons you trust (and preferably have inspected the code for).

Not sure if this is related to the browsers not wanting to display the SVG gradient.

use this tool https://ha.labtool.pl/en.lims?fbclid=IwAR2DG4kpeQjdyp15s2D-hADlHtUXuN6kCQZ0i90IxQAj2eCxiejFLqHpzu4

4 Likes

thats nice indeed, thanks for the link!

would be cool if they added a jinja template too there, to use in our card_mods directly, like:

temp_color:
  style: |
    :host {
      --paper-item-icon-color:
        {% set state = states(config.entity)|int(-5) %}
        {% if state == 'unknown'%} gray
        {% elif state < -20 %} black
        {% elif state < -15 %} navy
        {% elif state < -10 %} darkblue
        {% elif state < -5 %} mediumblue
        {% elif state < 0 %} blue
        {% elif state < 5 %} dodgerblue
        {% elif state < 10 %} lightblue
        {% elif state < 15 %} turquoise
        {% elif state < 20 %} green
        {% elif state < 25 %} darkgreen
        {% elif state < 30 %} orange
        {% elif state < 35 %} crimson
        {% else %} firebrick
        {% endif %};
    }

im casting my dashboard to a google nest hub and that dont work with card-mod… the segments does… that is why i use that

it was merely a suggestion to make the tool itself even more versatile. I didnt mean to suggest you to use that in a card at all.
Always best to keep to the cards own styling options, so I agree completely.

do you know who made this? tried to go to the root page, but no link at all anywhere

btw, I just had an experiment and saved the segments in my secrets.yaml and import that via:

segments: !secret gauge_segments_wifi

on the wifi gauges, works perfectly :wink:

thanks again for the pointer.

1 Like

found it on the fb group “Home Assistant” this dude made it i think

1 Like

Can you show me how you write the segments into secrets.yaml

sure its very easy, just add the complete yaml in your secret, and import it like you would do with a regular !include, only now with !secret:

# in gauge card:

segments: !secret gauge_segments_battery

# in secrets.yaml

gauge_segments_battery:
  - from: 0
    color: '#FF453A'
  - from: 2.5
    color: '#FF4C34'
  - from: 5
    color: '#FF542E'
  - from: 7.5
    color: '#FF5C28'
  - from: 10
    color: '#FF6422'
  - from: 12.5
    color: '#FF6C1D'
  - from: 15
    color: '#FF7317'
  - from: 17.5
    color: '#FF7B11'
  - from: 20
    color: '#FF830B'
  - from: 22.5
    color: '#FF8B05'
  - from: 25
    color: '#FF9300'
  - from: 27.5
    color: '#FF9D00'
  - from: 30
    color: '#FFA700'
  - from: 32.5
    color: '#FFB200'
  - from: 35
    color: '#FFBC00'
  - from: 37.5
    color: '#FFC700'
  - from: 40
    color: '#FFD100'
  - from: 42.5
    color: '#FFDB00'
  - from: 45
    color: '#FFE600'
  - from: 47.5
    color: '#FFF000'
  - from: 50
    color: '#FFFB00'
  - from: 52.5
    color: '#F4F709'
  - from: 55
    color: '#EAF313'
  - from: 57.5
    color: '#DFEF1C'
  - from: 60
    color: '#D5EB26'
  - from: 62.5
    color: '#CAE72F'
  - from: 65
    color: '#C0E339'
  - from: 67.5
    color: '#B5DF42'
  - from: 70
    color: '#ABDB4C'
  - from: 72.5
    color: '#A0D755'
  - from: 75
    color: '#96D35F'
  - from: 77.5
    color: '#8DCD5C'
  - from: 80
    color: '#85C85A'
  - from: 82.5
    color: '#7DC357'
  - from: 85
    color: '#75BE55'
  - from: 87.5
    color: '#6DB953'
  - from: 90
    color: '#64B450'
  - from: 92.5
    color: '#5CAF4E'
  - from: 95
    color: '#54AA4B'
  - from: 97.5
    color: '#4CA549'
  - from: 100
    color: '#44A047'

Could you post a link to this guy?

hmm… dont work here

Only in yaml mode, Ui doesn’t accept the !

In that case, in yaml mode a “normal” include file would make more sense to me then making the colors secret.

Not as easy as the tool in the screenshot above, but if you need color codes for a gradient tools like these can help. You’ll get the hex codes at the bottom of the page.

include vs secret:

  1. Include could be more cumbersome: “!include /config/shared/…/xyz.yaml” vs “!secret xyz”
  2. Include: a separate file for each definition; secret: many definitions in one file.
  3. Blueprints can only accept “include”.
  4. Secrets should not be shared on Github, include - could be.
  5. In general, non-secret definitions should not be kept as secrets.
2 Likes

we all know the secrets.yaml file is not truly secret, and merely there to be able to easily share our configs without sharing that sensitive information in the rest of the config.

we use the secrets file for a lot of other things, like complete rest/comand_line commands, or html embeds

or, as in this case, as a placeholder for strings me use throughout the config.

Also, as far as I recall, secrets.yaml has the advantage we can use in front-end And back-end, where !includes are to be used in Frontend only.

the biggest disadvantage in my opinion as we already described, is the fact !secrets nor !includes can be used in the UI…

anyways, you summed it up quit nicely, each should use the technique they can use best.

why?