color_thresholds property doesn't work correctly

[giacomocarrozzo]

I'm using the last version and I have the following configuration:

• type: 'custom:mini-graph-card' entities:
• entity: sensor.temperature_158d0002270b83 name: Inside
• entity: sensor.meteo_temperature name: Outside animate: false color_thresholds:
• color: '#f39c12' value: 10
• color: '#d35400' value: 15
• color: '#c0392b' value: 19 font_size: 50 hours_to_show: 48 line_width: 5 name: Temperature show: labels: true

But I don't see the color correctly to the thresholds I defined inside my configuration.

How can I fix that issue?

Thanks

[kalkih]

Umm yeah... seems like the new threshold change doesn't work very well in multi sensor setups. I'll try to fix this asap.

[kalkih]

https://github.com/kalkih/mini-graph-card/commit/0af8a6b4021a39d303d317dd6b0db98be54dee1d should resolve these issues, expect a new release with the fix tomorrow. Thanks!

[kalkih]

Hey, new release should fix these issues.

[Guyohms]

I'm having similar issue even with 4.1.2

The values are ranging from about 11 to 16 and I get this :

[kalkih]

Try clearing your cache after updating, and what browser are you running? It's kinda hard to tell what's going wrong in your example since I don't know the real line value. I tried your config and it seems to work in both chrome & safari for me.

Note that the fill will not show the gradient, decided against it since it in my opinion looked weird. The fill.

[giacomocarrozzo]

I tried the last version but I have the same issue. Moreover I conferm that if at least one value defined inside "color_thresholds" is out of a range then it is not working at all (the same result like @TorqueDelight ) I've test with Chrome, Chrome for Android and Firefox. Thank a lot for your support @kalkih !

[kalkih]

@giacomocarrozzo Thanks for the information.

I've found the issue with out of bound thresholds, and that should be fixed with https://github.com/kalkih/mini-graph-card/commit/ff94b9b91f31016ee11f143b0cc04a014977b492. I've also found the reason behind the other issue you both are seeing, and it has to do with the way I compute the gradient along the y-axis. Working on fix for that as well.

[kalkih]

Hey, new pre-release available, should fix the issues discussed here, would appreciate your feedback! https://github.com/kalkih/mini-graph-card/releases/tag/v0.4.3-beta

[giacomocarrozzo]

Thanks again @kalkih I tried the new version. It look a bit better but I still get a strange visualization.

• animate: false color_thresholds:
• color: green value: 10
• color: blue value: 15
• color: red value: 20 entities:
• entity: sensor.temperature_158d0002270b83 name: Interno
• entity: sensor.meteo_temperature name: Esterno font_size: 50 hours_to_show: 48 line_width: 5 name: Temperatura

With mouse hover i see the points with right colors.

[kalkih]

@giacomocarrozzo Try clearing cache, looks like you are still loading the previous release.

[Hypfer]

Using 0.4.3-beta seems to improve the situation but not solve it.

Temperature Thresholds:

    color_thresholds:
      - value: 26
        color: '#eb4d54'
      - value: 22
        color: '#1db954'
      - value: 18
        color: '#3a8df7'

[kalkih]

Quoting myself from the other issue discussing this

Yep, that's a caveat of the new way we render thresholds. It can however be circumvented by adding an additional threshold, and that way the transition "smoothness" could also be adjusted. This would also work for values out of bounds of the rendered graph.

- type: custom:mini-graph-card
  entities:
    - sensor.example
  name: Soft
  color_thresholds:
    - value: 10
      color: "#81ecec" # TEAL
    - value: 20
      color: "#e74c3c" # RED

- type: custom:mini-graph-card
  entities:
    - sensor.example
  name: Hard
  color_thresholds:
    - value: 10
      color: "#81ecec" # TEAL
    - value: 19.9
      color: "#81ecec" # TEAL
    - value: 20
      color: "#e74c3c" # RED

I can see the current behaviour being useful if you don't really care about values and just want a gradient effect, low -> high.

We could solve the issue programmatically but would then lose the ability to have smooth transitions, and would also make the use case stated above unachievable. But yeah, it's the "out of bounds" thresholds that's the main issue.

If you can think of another solution, I would love to hear it.

[kalkih]

Also, "The threshold at where the color should apply if state is above." is no longer the case, the threshold value is now the y-axis stop for that color. The old behaviour can still be achieved with the method in my earlier post.

Out of bound thresholds is still an issue though, if you want to preserve the gradient effect.

[tomlut]

So if I have 4 levels does that mean I now need to define 8 levels to get the correct line color?

I might just stick with v0.3.3.

[kalkih]

@tomlut https://github.com/kalkih/mini-graph-card/commit/114d7e310c38c4e7456ec575eca69c03e9d57209 Should solve the issue with invalid color rendered by out of bound thresholds.

But yes, if you dislike the gradient effect and want a hard transition that's what you would have to do, at least right now. I could see an option being added to set the transition strength hard/soft.

[Guyohms]

Thanks for the work. It works fine for me now.

[bratanon]

I could see an option being added to set the transition strength hard/soft.

+1 on that

[tomlut]

Or perhaps a value (e.g. 0-255 or 0-10 etc...) on how hard the transition should be?

I like the transition I just think it's too wide at the moment as it completely swamps some of my intermediate levels.

[kalkih]

Yeah, that would be optimal but could be tricky to implement, mostly when it comes to out of bound thresholds (thresholds outside of the visible scale).

I'm thinking hard/soft initially and then potential for a hardness/softness scale in the future.

[bratanon]

Im not sure what it really does, but as it is right now the standard behavior is broken as I see it. The line colors does not represent the value.

The "old" way this worked was perfect. The whole line changed color depending on the value.

[kalkih]

What do you mean by broken? What are your results and what do you expect?

The old way was long from perfect, it didn't really work for low res graphs, especially noticeable if the graph spiked.

Latest beta release should resolve the issue with incorrect colors when there are thresholds outside of the visible scale https://github.com/kalkih/mini-graph-card/commit/114d7e310c38c4e7456ec575eca69c03e9d57209.

[bratanon]

All lines turned black with beta2

show:
  fill: false
  labels: false
line_width: 8
hour24: true
more_info: false
color_thresholds:
  - value: 0
    color: var(--google-green-400)
  - value: 60
    color: var(--google-orange-400)
  - value: 80
    color: var(--google-red-400)

[kalkih]

In order to interpolate edge colors correctly you'll now have to specify colors in hex format. Other formats will work as long as they aren't outside of the visible graph boundaries, so you should be able to use any color format if you utilize static lower/upper bounds.

BREAKING CHANGE

color_thresholds now only support colors specified by hex format

[bratanon]

So we break things just to get a fade effect. :(

I liked the old way much better when the whole line changed color based on the latest state. This was easy to understand and easy to configure, and I think it was quite easy for you to maintain aswell.

This new fuzzy fade will only create a massive load of issues about it as its kind of hard to configure it correctly.

[bratanon]

Also with beta2 this spams the logs.

Error: attribute offset: Expected number or percentage, "-Infinity%".

[kalkih]

To be honest, I originally didn't think there would be so many issues with the new method and it shouldn't have been released that early totally my bad. It's hard to test every possible configuration / graph data without any sort of automated tests implemented.

But as I said, the old solution didn't work properly for low res graphs, which was/is meant to be the main use case of this card.

Most of the issues with the new method should now be ironed out, still missing the transition hard/smooth option. And until it's there it should literally take no more than ~30 sec to add the additional thresholds in order to get rid of the gradient transition.

And yeah, if you don't agree with my decisions you could always fork the card and modify it as you like or use an older version. Youc could also submit a PR with any proposed changes.

[kalkih]

Also with beta2 this spams the logs.

Error: attribute offset: Expected number or percentage, "-Infinity%".

Would be great if you could send me the configuration of the card where you get these errors.

[bratanon]

And until it's there it should literally take no more than ~30 sec to add the additional thresholds in order to get rid of the gradient transition.

Are you talking about the _lowerbound and _upperbound properties or what do you mean?

[kalkih]

No, by adding another threshold for each color as described earlier in the comments. https://github.com/kalkih/mini-graph-card/issues/91#issuecomment-494543055

[Guyohms]

Slightly off-topic... Is there a way to apply different color thresholds to a multiple line graph ?

[kalkih]

Nope, not at the moment, right now they share the same thresholds. Would be pretty easy to implement now though, thanks to latest changes made to thresholds.

[Guyohms]

Cool! If it's easy to do, I think it would be a nice addition !

[tomlut]

Hi kalkih, has there been any movement on the ability to set the scale of the smooth transition?

[kalkih]

No, not yet, feel free to open another issue with that request, I'm gonna close this one now.