Gauge Card: how to get a gradually changing color?

Configuration Frontend
25

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 %};
    }
26

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

27

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:

Scherm­afbeelding 2023-12-01 om 09.26.58
Scherm­afbeelding 2023-12-01 om 09.26.58980×354 22.9 KB

thanks again for the pointer.

1 Like
28

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

Skærmbillede (252)
Skærmbillede (252)736×854 167 KB

29

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

30

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'
31

Could you post a link to this guy?

32

hmm… dont work here

Skærmbillede (253)
Skærmbillede (253)1018×809 46.8 KB

33

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

34

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.

36

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
37

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?

38

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.

39

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

40

No, this is not correct.
I use “!include” in blueprints, sensors etc

41

a ok, as I said, and please quote me completely:

Glad you pointed me to that, because I could use it too :wink:

ofc I completely forgot about things in the configuration.yaml:

frontend:
  themes: !include_dir_merge_named /config/dashboard/themes

lovelace:
  mode: yaml
  resources: !include /config/dashboard/resources.yaml

aargh, its getting late

and voted for your FR

42

That is why I proposed this FR.
Yes - secrets are convenient to keep shared code. But - this is wrong.

I ended up to move almost all shared code from “secrets” to “include” (btw, nobody advised me to use “secrets” for reused code - and never read about this practice here before myself).
What is only left in “secrets” are one-string definitions like:

xyz: "some string 1"
abc: "some string 2"
def: 123

for which I decided not to create separate files, too many of them…

43
4 Likes
44

Sorry for the long waiting time. I didn’t even know that my website came here.

I added your proposal but I will tempt more information on how exactly it should be formatted. And possibly what headlines should be default.

45

Good job! Really appreciated.