bug(color_thresholds): defaults to black instead of closest out-of-bounds color

[alnavasa]

I have a graph meant to graph wind speed in different colors as you can see in the code. Though I find myself with an issue, if the color threshold value its not reached, the color it uses is black until (if it ever does) reaches the next value, In the image below you can see that in never reached purple color value, and therefore it started graphing towards black, if it ever reached the purple value, then the graph would be render towards that color.

How can I fix this?

Am I doing something wrong or is this an issue with the card

  - type: custom:mini-graph-card
    entities:
      - entity: sensor.aemet_wind_speed_kts
      - entity: sensor.aemet_wind_bearing
        show_state: true
        y_axis: secondary
        color: var(--accent-color)
    name: Viento 7d
    icon: mdi:weather-windy
    line_width: 1
    font_size: 70
    animate: true
    color_thresholds:
      - value: 5
        color: '#0095a6'
      - value: 10
        color: green
      - value: 16
        color: orange
      - value: 24
        color: red
      - value: 30
        color: purple
    hours_to_show: 168
    points_per_hour: 0.2
    lower_bound_secondary: 0
    upper_bound_secondary: 360
    show:
      average: true
      legend: false
      extrema: true

[StormyKnight17]

I noticed this too, it seems that color names don't always work. If I use '#######' it does render correctly for me.

[alnavasa]

I noticed this too, it seems that color names don't always work. If I use '#######' it does render correctly for me.

That did the trick, but it needs to get solved.

[scyto]

ahh, i was wondering why all my color threshold names suddenly stopped working +1 on issue here (i am using red / yellow / blue and only getting a black line)

[jlsjonas]

it seems that color names don't always work

Could you please add information about which cases the "text colors" no longer work; not always is sadly enough a bit too vague to fix ;)

[Fillius]

I have just encountered this issue. I have a temperature sensor which in the past 24 hours had recorded 10.1 as its lowest value. I tried setting a colour threshold of "blue" that started at 0 and ended at 15 but it showed as black. I tried changing the colour to "red", "green", "orange" etc. none of which worked. Changing the value to 11 (higher than the 10.1 minimum recorded value) fixed it. After seeing this issue, I changed it to use hex codes which has fixed it.

[kate-shine]

it seems that color names don't always work

Could you please add information about which cases the "text colors" no longer work; not always is sadly enough a bit too vague to fix ;)

It doesn't work for me as well. Basically, until the threshold value is reached - threshold value becomes part of the graph, the graph color stays black. Example: My setting for CO2:

type: custom:mini-graph-card
entities:
  - sensor.co2_air_quality
color_thresholds:
  - value: 600
    color: green
  - value: 1000
    color: orange
  - value: 1500
    color: red

Until my CO2 value reaches 1500, upper values fade to black.

It can be worked around by forcing graph to always contain those values (setting upper and lower bound), but it's really just a workaround.

Screenshots before and after setting the 600-2000 bounds

[ildar170975]

My case:

type: custom:mini-graph-card
entities:
  - sensor.xiaomi_cg_1_co2
points_per_hour: 120
hours_to_show: 1
line_width: 1
show:
  points: false
  labels: true
color_thresholds_transition: hard
color_thresholds:
  - value: 575
    color: green
  - value: 582
    color: orange
  - value: 592
    color: red

First - when I lower bound (568) is LESS than the 1st threshold (575):

Everything seems OK.

A bit later - a lower bound (577) is MORE than the 1st threshold (575):

The lower part of the graph is of BLACK color.

Next, lets fix a lower_bound & increase a value of the last threshold:

color_thresholds:
  ...
  - value: 600
    color: red
lower_bound: 570

Here last threshold (600) is more than the upper bound (598). The top part of the graph is of BLACK color.

Observations: -- if the 1st threshold is LESS than the current lower bound, then the lower part is BLACK; -- if the last threshold is MORE than the current upper bound, then the top part is BLACK.

[StormyKnight17]

Yes, hex rgb is not as user friendly 😊

Cheers Richard

Sent from my iPhone

On 21 Mar 2022, at 04:58, alnavasa @.***> wrote:

 I noticed this too, it seems that color names don't always work. If I use '#######' it does render correctly for me.

That did the trick, but it needs to get solved.

— Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications on the go with GitHub Mobile for iOS or Android. You are receiving this because you commented.

[jlsjonas]

Sadly enough I'm having a hard time reproducing the issue...

Could someone try to reproduce it on a demo instance of HA? Attempted with several iterations of the following config:

      - type: custom:mini-graph-card
        hours_to_show: 1
        points_per_hour: 120
        lower_bound: 0
        upper_bound: 1000
        smoothing: false
        height: 600
        show:
          extrema: true
        entities:
          - entity: sensor.random_0_1000
            name: log(150 - 1000) Simple
            aggregate_func: last
        color_thresholds:
          - value: 0
            color: green
          - value: 200
            color: red
          - value: 1000
            color: blue

ended up with:

[NickdeK]

Also ran into this issue. It seems it has to do with the threshold value somehow. If I set the 1500 value to anything below 1060 it seems to change a bit.

type: custom:mini-graph-card
name: CO2
icon: mdi:molecule-co2
hour24: true
hours_to_show: 12
decimals: 0
show:
  legend: false
entities:
  - entity: sensor.awair_element_74851_carbon_dioxide
    show_state: true
    state_adaptive_color: true
color_thresholds:
  - value: 0
    color: var(--success-color)
  - value: 600
    color: var(--warning-color)
  - value: 1500
    color: var(--error-color)

type: custom:mini-graph-card
name: CO2
icon: mdi:molecule-co2
hour24: true
hours_to_show: 12
decimals: 0
show:
  legend: false
entities:
  - entity: sensor.awair_element_74851_carbon_dioxide
    show_state: true
    state_adaptive_color: true
color_thresholds:
  - value: 0
    color: var(--success-color)
  - value: 600
    color: var(--warning-color)
  - value: 1059
    color: var(--error-color)

Setting a hex code seems to work indeed.

I also don't have this issues with other graphs that don't have such high values like PM2.5 and temperature.

[ildar170975]

@NickdeK Please do not place a code inside "details" tag - it seems to be not properly formatted. Removed "details" tags.

[Mariusthvdb]

had to mention this post in https://community.home-assistant.io/t/lovelace-mini-graph-card/71385/2302 because of a terrible time I had in just a single mini-graph-card config out of many I have that use color names and not hex colors.

Even though the docs state we can only use those hex colors, I just had not given that a thought, and never saw issues using color names. Until the one linked above, on processor % usage. Ive tried all options in the config , as documented in the community. In the end: color names didnt work without outer boundaries set (all black) and with those out boundaries (0-100) I did see colors, but they were odd. Color adaptive state was correct btw.

Conclusion:

• docs are right, we should only use hex colors in the thresholds (fixed colors fork flawlessly with color names)
• a FR is in order to ask dev team to have a look, and fix that (would be breaking new feature, it would sooner be a bug fix....)

hope this is feasible.

[parautenbach]

I figured out a workaround for when you use named colours or variables: Set a lower and upper bound on the primary y-axis (lower_bound and upper_bound). Unfortunately, this might not be a feasible workaround for every scenario, but luckily for all my charts I have deterministic lower and upper bounds (or, they're just very unlikely to exceed those numbers).