2022.12 Color states are broken/unusable

Actually, I meant graphs for sensors w/o UoM.
Currently for 2022.12.1 we have this:

1.The sensor was created at ~00:20, the graph show “empty” (i.e. “transparent”) line for the period when this sensor did not exist.
2.After some time the sensor became “unavailable”; currently it is same color as for “off” - so let’s imagine that it will be “transparent” in the next HA release.

3.HA was rebooted between 00:25…00:26.
At that time the sensor became “unknown”:


Note that currently “unknown” is also using the same color as “off” & “unavailable” (hope this will be fixed).

4.Then the sensor was deleted.
Then the sensor was added again - so we see “unknown” in the graph:


Actually, I am expecting a “gap” here since there is no sensor exist at this period - but this is another issue.

Currently this picture seems rather logical (if not talking about same color for “unavailable”, “unknown” & “off” and that “gap with unknown”).
Because of your changes now we will see no differences between “unavailable” & “does not exist” states.

Will it be SAME color as “off”?

Wrong, if you mean history-graph.
Here is a screenshot of some previous untouched HA version:
image

1 Like

I am generally fine with the color changes as implemented. I do, however, have “alert” entities that when “idle” are appearing as red. No idea what colors appear when “on” or “off”. I only see two variables in the theme styles with alert in the name (–rgb-state-alert-color: var(–rgb-red-color), --rgb-state-binary-sensor-alerting-color: var(–rgb-red-color); )

Just curious if I’m missing something here, or have something misconfigured somewhere, or if this needs to be adjusted in the actual HA code – but it seems like an “idle” alert shouldn’t be default red?

Example:

alert:
  smoke_basement:
    name: Smoke Alert in Basement
    entity_id: sensor.basement_smoke_co_status
    state: 'smoke'
    repeat:
      - 5
      - 10
      - 130
    skip_first: false
    notifiers:
      - hass_text

  co_basement:
    name: CO Alert in Basement
    entity_id: sensor.basement_smoke_co_status
    state: 'CO'
    repeat:
      - 5
      - 10
      - 130
    skip_first: false
    notifiers:
      - hass_text

That is being discussed here already: State color of thermostat entity based on wrong attribute. · Issue #14608 · home-assistant/frontend · GitHub

2 Likes

Is it a binary sensor of some particular class?
Could you give an example?

hugely appreciate the lengths the frontend team now seems to adjust some color oddities in the original 2022.12 effort.

Must confess I am a bit underwhelmed by PR #14710 on the unavailable color to be transparent. To me transparent looks like a rendering bug. As if the graph is broken.

There is not even a state named in that screenshot, so it doesn’t indicate with text what is the matter. We have nu clue at all.

I can not understand this design decision, was there was a nice example by Paul how these unavailable/off/on colors were set to very light grey/grey/active color (cant find the screenshot right now)

there is not a single other situation in HA where ‘transparent’ indicates anything, other than a bug/issue.

How would this be sane design, are we sure this isnt a fluke?
(checking the PR now)

and yes, unfortunately this appears not to be a fluke. Though I see the exact same wording written in doubts I used above…

now even read:

o dear.where is this going?
How have you established this ‘appears to be a better solution’?? In the last 3 days that is, where you said:

Inactive and unavailable state will be two different colors on the dashboard, more-info, logbook, history. It will be 2 shades of grey and will be configurable with themes.

At least indicate ‘unavailable’, but preferably bring back the light greyed background to that. Seems universal, so why be purposely different here.

--rgb-state-unavailable-color: var(--rgb-light-grey-color);

please.

1 Like

At least two vars should be added - for unavailable & unknown in history-graph.

4 Likes

I guess we have to agree there, because now, as it is intended, ‘off’ will be the same as ‘unknown’.

Which ofc is so not what the backend team states at any opportunity. Check the latest changes made to the binary entities, that have those 4 states now… And that was explicitly and purposely done, because being ‘unknown’ is not off/on. It’s a pain, but hey, it kind of is true.

And now our frontend tells another story: never mind the entity is unknown, we’ll show it as off. It is plain incorrect.

2 Likes

I would really use a very light grey color for unavailable entities - such as: #F8F8F8 rgb(248,248,248) for example…

Or, at least, keep the text based information “Unavailable” - so that the gap does make any sense at all… :slight_smile:

1 Like

What I find really really good is the option to modify name, area and icon in the UI for an entity if it has an unique id. It’s so easy and user friendly that I don’t understand that this functionality can’t be used to set up the colours for the entity as well. In general there are no more then 4 states (on, off, unavailable, unknown). I hope our Devs read this :pray:. That would be for me the ultimate solution. The (custom) themes set the global colours and you modify the entity colours to your liking to suit your dashboard.

I am still on 2022.11.5 because the updates after I still a small disaster to me.

1 Like

Just want to also say thanks to the frontend team reacting to this, sometimes a bit too frank, feedback. Just report the facts everyone as the saying goes “Play the ball not the man”

1 Like

Once again about different colors for Zones in History - please consider these scenarios.

1 Like

I wonder if an option for addressing non-contrasting adjacent ‘not_home’ zones might be as simple as

state-person-zone-odd-color
state-person-zone-even-color

Maybe a colour could be defined for each zone when the zone is created either in Yaml or in the UI?

2 Likes

2022.12.4
History for a sensor which is unavailable now:


Transparent graph…

P.S. Added this post, then deleted it - to recheck to be sure.
Restored it later.


Update:

Sigh. Can we have green back for this please?

Screenshot 2022-12-13 at 12-23-58 Overview – Home Assistant

5 Likes

I still haven’t forgiven them for shrinking the keypad - and that was a few releases back.

2022.12.4
binary_sensor, device_class=cold
unknown, on, off

Was described in this issue, I just was not able to reproduce it, now got in 2022.12.4:

Beat me to it. I just noticed that. :+1:

What I cannot understand is, why did they release the .4 when they know it injects this bug? Surely it is not a human decision that history graphs for binary sensors changes to yellow on yellow making them unusable. Totally unusable. Only transparent on transparent would be a worse combination.

1 Like

Somehow I feel the title of this filtered away thread is not even adequate anymore.
not only is this thread now only populated by the good people trying to keep the HA Frontend meaningful, and spend hours and hours providing serious feedback. Added to that, we are being confronted by changes that make things even worse…

last 3 4 true new errors listed:

  • transparent for unavailable (and obvious incorrect decision to show unknown as off)
  • non listed state for unavailable
  • non changing colors for binary sensors
  • incorrect colors for some: see alarm button disarmed

and as can be seen here Color of states Off and Unavailable are the same in History graph card in release 2022.12 · Issue #14619 · home-assistant/frontend · GitHub, and here The color of binary sensors never changes (regardless of state) · Issue #14701 · home-assistant/frontend · GitHub there is no such thing as a generic color for any state, it all depends on the class (if available).

In my company, I’d call the decision to escalate, and have a serious talk. Can’t do that here probably. If we out the slightest emotion, we would simply be moderated away. And no way to talk to the manager…

Ive started my findings/comments/suggestions already in the last beta. Some things were fixed. In the process other changes were added and made the experience worse. And they are piling up.

I am starting to feel completely let down. One day we are answered this and that is decided (very/light grey). Within 2 lines of chat on a PR, that is decision is abandoned. And some wild experiment is thrown at us, because someone ‘likes’ it?

Come on good people.

at least test your own PR’s before releasing them into the wild…

8 Likes