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… 
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.
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
#fullcolorsuffix 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 
thanks again for the pointer.
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?
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:
- Include could be more cumbersome: “!include /config/shared/…/xyz.yaml” vs “!secret xyz”
- Include: a separate file for each definition; secret: many definitions in one file.
- Blueprints can only accept “include”.
- Secrets should not be shared on Github, include - could be.
- 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?
You use we a lot in your post, but who is we? Not me.
I use secrets.yaml for, well, you know, what the name implies. What is in there is also in my password locker. I do version control on the Home Assistant configuration on github, and secrets.yaml is not there. So part of the relevant configuration is not in version control if you put it in secrets.yaml. And I’m not going to put color gradients in my password vault.
Generally I think it is bad practice to reuse something that is meant for something else just because it is convenient. It is bad for maintainability. People should know what is in a file (and what isn’t) by looking at the name.
fine by me, do as you like.
we as in the community.
If you are not aware the secrets file is not a secret, you really should read up on that. There are many posts on the matter.
we should go back to the subject of this thread, we are getting rather off topic