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

Different zones in History have same color #14705

Open
3 tasks done
ildar170975 opened this issue Dec 12, 2022 · 31 comments
Open
3 tasks done

Different zones in History have same color #14705

ildar170975 opened this issue Dec 12, 2022 · 31 comments
Assignees

Comments

@ildar170975
Copy link
Contributor

ildar170975 commented Dec 12, 2022

Checklist

  • I have updated to the latest available Home Assistant version.
  • I have cleared the cache of my browser.
  • I have tried a different browser to see if it is related to my browser.

Describe the issue you are experiencing

Earlier different zones in History have different colors when displaying a history for person or device_tracker entities.
Since 2022.12 all zones have SAME color which makes graphs not easy to analyse.

Describe the behavior you expected

  1. Different zones must have different colors.
  2. Same zone must have same color on graph.
  3. If possible - same zone must have same color on all graphs.

Steps to reproduce the issue

as above

What version of Home Assistant Core has the issue?

2022.12.1

What was the last working version of Home Assistant Core?

No response

In which browser are you experiencing the issue with?

Chrome 108.0.5359.99

Which operating system are you using to run this browser?

No response

State of relevant entities

No response

Problem-relevant frontend configuration

No response

Javascript errors shown in your browser console/inspector

No response

Additional information

No response

@ildar170975
Copy link
Contributor Author

Let me demonstrate an importance of this issue.

In an ideal scenario a person entity graph looks like:
image
where a length of each part corresponds to a duration of the person's presence at Home or in some Zone.

But in a real life:

  • device_tracker may not be updated in time -> a length of some part is longer / shorter than an actual duration;
  • even some part may be missed - like "Home -> Zone 1, w/o Away":

image

Also a zone's name may not be displayed if this part is short:
image

Imagine that a user wants to estimate where his child was today.
Surely a Logbook card with displaying time may be used etc.
But also this graph may be used:
image
where the orange part is clearly seen as a separate zone.
Then the user may hover a mouse, see that this is a "Zone 1" in a baloon etc.

@midcode
Copy link

midcode commented Dec 13, 2022

An even better solution would be if you could define specific colors for zones (like the icon you can already define)

@ildar170975
Copy link
Contributor Author

@midcode
Like that:
if zone = "church" -> --history-zone-church-color
if zone = "mom" -> --history-zone-mom-color
...

@prof7bit
Copy link

prof7bit commented Dec 13, 2022

+1 for the above suggestion.

The frontend code already does dynamically construct variable names from entity attributes, you can find code like this

--rgb-state-${domainColor}-color

for constructing the appropriate variable name for a certain domain. There is nothing stopping you from bringing this to the next level and also construct names like this

--rgb-state-${domainColor}-$(entityId)-color

with higher precedence than the more generic domain color, look up whether it is defined and if it is undefined then fall back to the more generic color for all entities of that domain.

This would than also allow stuff like

--rgb-state-binary-sensor-garagedoor-color: 'red'
--rgb-zone-golfclub-color: 'lightGreen'
--rgb-zone-color: 'blue' #all other zones

And as a bonus, to make all the complaints about wrong colors disappear, make it so that

  • if the color for a specific entity is undefined then fall back to the domain color
  • if the domain color is undefined then fall back to the theme accent color
  • remove many of the new default colors (so it will always fall back to active=yellow from the old theme everywhere) and let users color whatever they want/need IF they want/need.

@alexeyzel
Copy link

I have the same problem in version 2022.12.4 with binary sensors in the History Graph Card. Both zones (on and off) have the same colour:
image
The same behaviour is on history tab too.
image

@alexeyzel
Copy link

Just updated to 2022.12.5 and my problem with binary sensors in the History Graph Card is fixed.

@ildar170975
Copy link
Contributor Author

@alexeyzel
Your issue is not related to Zones, it is about "for binary_sensors, same colors are used for on & off", and this is supposed to be fixed in 2022.12.5.

Ваше замечание не относится к теме данного тикета про раскраску Зон.
Ваше замечание касается бага "для binary_sensor используются одинаковые цвета для on & off в History" (можно найти соотв. тикет среди закрытых), данный баг должен был быть исправлен в 2022.12.5.

@ApriliaEdd
Copy link

An even better solution would be if you could define specific colors for zones (like the icon you can already define)

This would be a nice solution if the person entity cards and badges also use this colour. for example my wife works at multiple different sites i could make all these zones purple so easily see at a glance she is at work by the colour of the badge and the location text of the badge would show which site she was working at.

@ildar170975
Copy link
Contributor Author

Selecting a color for icons, buttons and badges dependingly on a current zone is already possible:

  1. In a custom theme create your own variables:
user-zone-church-color: green
user-zone-school-color: red
  1. For an icon, badge or button - use card-mod to define a color like:
color: var(—user-zone-{{states(config.entity)}}-color); 

This code is untested, just to explain the idea.

But this approach is not possible now for History.
That is why it was suggested to add a functionality to draw a History using individual variables for each zone.
Not to mention a fact that many users do not use card-mod and expect to color icons, buttons and badges automatically.

@piitaya
Copy link
Member

piitaya commented Dec 16, 2022

Home Assistant must work without theme. Adding variables is not a solution for many users. We can not say to the user : "add this variable to your theme to fix the history issue".

@ApriliaEdd
Copy link

Selecting a color for icons, buttons and badges dependingly on a current zone is already possible:

  1. In a custom theme create your own variables:
user-zone-church-color: green
user-zone-school-color: red
  1. For an icon, badge or button - use card-mod to define a color like:
color: var(—user-zone-{{states(config.entity)}}-color); 

This code is untested, just to explain the idea.

But this approach is not possible now for History. That is why it was suggested to add a functionality to draw a History using individual variables for each zone. Not to mention a fact that many users do not use card-mod and expect to color icons, buttons and badges automatically.

i currently use card mod to achieve this but it would be nice to have in core/default without mods so it will not be broken in future updates.

@ApriliaEdd
Copy link

Home Assistant must work without theme. Adding variables is not a solution for many users. We can not say to the user : "add this variable to your theme to fix the history issue".

I agree entirely with this, it would be a nice solution to select a colour for the zone when you create it just as you choose the icon ui and then have that colour match the history graph. I know nothing of programming so this may or may not be achievable now or in the future

@prof7bit
Copy link

prof7bit commented Dec 16, 2022

Home Assistant must work without theme.

These variables would be optional: If it doesn't find a variable that explicitly defines the color for zone 'foo' it would then use the mechanism that colors zones in some automatic or default way. The same could be done even for each individual entity, not only zones.

With a consistent and predictable naming scheme it would be possible (and relatively easy) for advanced users to add variables for coloring individual entities, individual zones, etc. and when the user does not define such variables it would just do it automatically in some reasonable way.

@ildar170975
Copy link
Contributor Author

ildar170975 commented Dec 16, 2022

Home Assistant must work without theme. Adding variables is not a solution for many users. We can not say to the user : "add this variable to your theme to fix the history issue".

@piitaya
Nobody advised here to use a custom theme as proper solution.
It was advised to provide automatically variables for each zone - and then users may re-define these variables as they like in their custom themes.

Update: surely , there could be another ways; the main points are:
-- different zones in History must be colored differently by default;
-- users must have a possibility to define a custom color for each zone.

@ildar170975
Copy link
Contributor Author

i currently use card mod to achieve this

@ApriliaEdd
In part of styling icons, buttons, badges etc - but not for History, I think.

@jareau
Copy link

jareau commented Jan 27, 2023

An even better solution would be if you could define specific colors for zones (like the icon you can already define)

I like this suggestion.

@marcelodavanzo
Copy link

Just came across this issue and it still exists in 2023.2. History graph for device_tracker is made illegible due to the same color being applied to all non home/away zones.

The previous behaviour of random colors for individual zones was a much better approach and made the history graph actually meaningful at a glance given that the purpose of the frontend is to present data in a visually useful manner.

I'm not sure what coloring all non home/away zones the same is achieving but it certainly isn't making the graph any better than it was.

Would really like to see the previous behaviour back even if as a prop when creating device_trackers. I think providing customizeable variables for each zone is a bit overkill and would rather have HA handle this out of the box as piitaya said

@github-actions
Copy link

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label May 24, 2023
@ildar170975
Copy link
Contributor Author

up

@prof7bit
Copy link

prof7bit commented May 24, 2023

It seems the different theme variables for different zones are working now. I found this out by reading through some very long threads in the forum and doing some experimentation on my own.

It would have been nice if the devs who are assigned to this (and similar) issues would have commented about the current state of affairs instead of just silently implementing something, leaving the issues open and uncommented and and not telling anybody anything about it.

@github-actions github-actions bot removed the stale label May 24, 2023
@piitaya
Copy link
Member

piitaya commented May 24, 2023

Hello 👋

One effect of the new state colors introduced with 2023.2 is that you are able to customize the color for each zone.

For example you can define state-person-my_office-color or state-device_tracker-my_office-color if you have a zone named My Office. You can noticed that the zone name is slugified in the css variable (lower case and space replaced by _.
There is currently no way to customize it from the UI.

@ildar170975
Copy link
Contributor Author

ildar170975 commented May 24, 2023

if you have a zone named My Office

If a user lives in not-english country - then probably he will have a zone.parents with a name in a local language ("Eltern").
Then these user-defined theme variables should be called state-person-eltern-color, right?
And what about Korean language? Cyrillic letters?
I do not think that non-latin letters may be used in variables.


A possibility to define a custom color for a zone in a theme is a useful addition.
Thanks a lot for this (although it may work in latin-letters countries only).
But in a history-graph each zone should be colored differently BY DEFAULT.

Imagine a user who never dealt (or does not want to deal) with custom themes.
Or a user with 20 zones.

So, an ideal solution could be:

  1. Use different colors by default for different zones:
  • zone.home has SAME color in every graph;
  • zone.xyz may have different colors on different graphs - but same color in a graph.
  1. A user may define special colors for some zones in a custom theme.

@piitaya
Copy link
Member

piitaya commented May 24, 2023

If a user lives in not-english country - then probably he will have a zone.parents with a name in a local language ("Eltern"). Then these user-defined theme variables should be called state-person-eltern-color, right? And what about Korean language? Cyrillic letters? I do not think that non-latin letters may be used in variables.

We didn't added the state color variables to fix this issue.

Person entities uses the friendly name as a state, not the entity_id so the state will be used. For information, it uses this function to slugify the state : https://github.com/home-assistant/frontend/blob/dev/src/common/string/slugify.ts

A possibility to define a custom color for a zone in a theme is a useful addition. Thanks a lot for this (although it may work in latin-letters countries only). But in a history-graph each zone should be colored differently BY DEFAULT.

Imagine a user who never dealt (or does not want to deal) with custom themes. Or a user with 20 zones.

So, an ideal solution could be:

  1. Use different colors by default for different zones:
  • zone.home has SAME color in every graph;
  • zone.xyz may have different colors on different graphs - but same color in a graph.
  1. A user may define special colors for some zones in a custom theme.

I really think we need to better solution for this issue. I only provide the current state as @prof7bit asked an update. For now, I don't have a perfect solution for this.

@ildar170975
Copy link
Contributor Author

ildar170975 commented May 24, 2023

We didn't added the state color variables to fix this issue.

Correct, and I wrote about user-defined variables based on this approach.

Person entities uses the friendly name as a state, not the entity_id so the state will be used

This is exactly what I wrote. And if friendly names are in Korean or Cyrillic (for instance) - then that approach cannot be used.
For example:
zone.village has a friendly name Деревня in Russian.
And a user cannot use a variable --state-person-деревня-color.

@Mariusthvdb
Copy link
Contributor

Mariusthvdb commented May 25, 2023

state-person-my_office-color or state-device_tracker-my_office-color

would there be an easy way out of this scenario?:

home: green
not_home: gray (same as not in a zone, and not home, so traveling)
in a zone (have a lot of zones, so a generic 'zone' color would be nice): orange

ideally this would be in core somehow (might already be, so please forgive me if the case), or be added to it as minimum requirement?

currently using:

    state-person-home-color: green
    state-person-not-home-color: '#636B75'
    state-person-zone-color: mediumslateblue

    badge-person-home-color: green
    badge-person-not-home-color: '#636B75'
    badge-person-zone-color: mediumslateblue

but not sure if this is what your saying we can do already, or that you want to diverge from that

@github-actions
Copy link

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Aug 23, 2023
@ildar170975
Copy link
Contributor Author

Up

@github-actions github-actions bot removed the stale label Aug 23, 2023
Copy link

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.
Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍
This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.

@github-actions github-actions bot added the stale label Nov 21, 2023
@ildar170975
Copy link
Contributor Author

up

@github-actions github-actions bot removed the stale label Nov 23, 2023
@weber8thomas
Copy link

up

1 similar comment
@Chacsam
Copy link

Chacsam commented Feb 24, 2024

up

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

No branches or pull requests