Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: legend indicators respect entity attribute configuration #1115

Merged
merged 1 commit into from
Jul 24, 2024

Conversation

arychj
Copy link

@arychj arychj commented Jul 24, 2024

When using attributes for entity states, the line picks up the new state location and respects the color thresholds, however the legend indicators do not.

Current behaivour

entities:
  - entity: sensor.sensor_1
    attribute: attribute_1
    name: ' '
  - entity: sensor.sensor_2
    attribute: attribute_1
    name: ' '
# ...
image

New behaviour

This updates the renderIndicator() function to use the existing getEntityState() which checks if an attribute has been configured, otherwise it falls back to the entity state.

image

@akloeckner akloeckner changed the title BUGFIX: Legend indicators respect entity attribute configuration fix: legend indicators respect entity attribute configuration Jul 24, 2024
@akloeckner
Copy link
Collaborator

Thanks! This looks like a very pointy fix.

@ildar170975, I don't use colour thresholds: Is this how it's supposed to work?

@ildar170975
Copy link
Collaborator

ildar170975 commented Jul 24, 2024

Hmmm, here it is said "attribute configuration".
I do not think I have recorded entities with numerical attributes, cannot test right now.
But there are issues with colored states, not attributes.
So let's start with a simpler case - state, not attribute.

  1. No color thresholds:
type: custom:mini-graph-card
entities:
  - entity: sensor.xiaomi_cg_1_co2
    show_state: true
    state_adaptive_color: true
  - entity: sensor.xiaomi_cg_2_co2
    show_state: true
    state_adaptive_color: true
name: CO2
hours_to_show: 24
points_per_hour: 60
lower_bound: ~400

Here state labels & legend parts have correct colors:
изображение

  1. Added color_thresholds:
color_thresholds:
  - value: 450
    color: orange
  - value: 550
    color: green
  - value: 650
    color: magenta
color_thresholds_transition: hard

Here both entities are "pink" - state labels & legend parts - since both entities are > 650:
изображение

  1. A bit different color_thresholds - 2nd entity is supposed to be below last threshold:
color_thresholds:
  - value: 450
    color: orange
  - value: 550
    color: green
  - value: 665    #!!!!!!!
    color: magenta

And here state labels have correct colors, but a legend part for the 2nd entity is black (WRONG):
изображение

So, imho in both cases - showing a state or an attribute - a legend parts should have colors dependently on their current value.
Note that for a state label a color is set dependently on a state_adaptive_color option; but for a legend part a color should be set always.


Test for attributes: (graphs are not displayed since entities are not recorded)

  1. No thresholds:
type: custom:mini-graph-card
entities:
  - entity: sensor.xiaomi_cg_1
    attribute: co2
    show_state: true
    state_adaptive_color: true
  - entity: sensor.xiaomi_cg_2
    attribute: co2
    show_state: true
    state_adaptive_color: true
name: CO2
hours_to_show: 24
points_per_hour: 60
lower_bound: ~400

Colors are OK for state labels & legend parts:
изображение

  1. With thresholds:
color_thresholds:
  - value: 450
    color: orange
  - value: 550
    color: green
  - value: 650
    color: magenta
color_thresholds_transition: hard

Here state labels are OK (pink), but legend parts are both wrong:
изображение

@akloeckner
Copy link
Collaborator

So, imho in both cases - showing a state or an attribute - a legend parts should have colors dependently on their current value.

Thanks, that was what I was looking for. From your tests, it seems we still have some other issues. But this PR moves us in the right direction. 👍

I'm going to merge it then.

@akloeckner akloeckner merged commit 5fe01d1 into kalkih:dev Jul 24, 2024
5 checks passed
@ildar170975
Copy link
Collaborator

I'm going to merge it then.

At least we'll be able to test it then )))

@ildar170975
Copy link
Collaborator

@akloeckner
please tell me where to find a compiled js file

@akloeckner
Copy link
Collaborator

I'll publish a pre-release in a few minutes.

Also, I believe one of the actions creates a compiled js as an artifact. 🤔

github-actions bot pushed a commit that referenced this pull request Jul 24, 2024
## [0.12.2-dev.1](v0.12.1...v0.12.2-dev.1) (2024-07-24)

### Bug Fixes

* indicator style for the 1st state ([#1105](#1105)) ([c0ad333](c0ad333))
* legend indicators respect entity attribute configuration ([#1115](#1115)) ([5fe01d1](5fe01d1))
Copy link

🎉 This PR is included in version 0.12.2-dev.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

@akloeckner
Copy link
Collaborator

Also, I believe one of the actions creates a compiled js as an artifact. 🤔

There should be one here:

  • Click on "Checks" for the PR
  • Select "CI"
  • Scroll down to "Artifacts"
  • Download one of the zips
  • It should contain the compiled .js

@ildar170975
Copy link
Collaborator

ildar170975 commented Jul 24, 2024

After PR merged - became better, but a black indicator still shown: #1116
i.e. the old bug is still there

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants