2021.7 History graph color changes

Configuration Frontend
47

So that worked great. Though in doing so I can absolutely see WHY it was changed. I did not use the history graphs page much… mostly because it is disorganized and not easily readable, but for different reasons than the colors.

The original was red green blue etc, I changed it to blue red green etc, so the blue was the first selected color just like the new color palette. It made it easier to compare the same HA instance in another browser that was not cache invalidated.

The first 2 colors of the original palette are red and green, which look to be now used exclusively for on/off states of the various binary sensor device classes. Now the looped (is it?) color palette for other states will not include those 2 colors at all. That can make it easier to see what entities have binary states.

HOWEVER, that is not the real takeaway, both the alphanumeric state history graph as well as line graphs for numeric states use the same palette, which is why all the single entity numeric line graphs changed from red to blue. After a visual comparison of the history graphs, including the line graphs, I do not think they should have the same palette, and it would also be optimal if the palette for light and dark themes are different. The medium grey is also used for unavailable states, and thus is not used for line graphs at all.

That means 4 palettes instead of 1, which honestly would not be nearly as much work as making the palette user customizable, but should make a noticeable improvement to the user experience. Having really bright pastel colors like #ffed6f on a line graph with a white background sucks. Then you have #fecddf and #fccde5 which look almost identical, and #cbe8ff and #c4eaff too. None of those should exist on a white background line graph from a usability standpoint, and having colors that are almost identical does not help much on the state graph (not a big deal though), but are abysmal on a line graph if they overlap or have similar values.

The list is long, something like 60 colors. I do not think combined line graphs will need that many, but the state graphs might. If there are any UX people in the thread that can go through the list of 60 or so colors and figure out which ones should be eliminated from both light and dark themes that would be a good start. Filtering the line graph colors will be far easier.

Does anybody have an opinion on whether this is a good intermediate step towards full customization? I know if it was customizable, I would want the line graphs and the state graphs to have different palettes, and having the backend work for them to be different in advance would make it easier to implement.

2 Likes
48

The frontend code is compiled, so that change would need to be made in the source code before compilation

49

Hi @richieframe, I apologise for the n00bishness of this request, but I am a bear of very little brain.

Would you mind writing up a step-by-step guide for how you achieved this? I’m partially colourblind, and at the moment I am trying to use the History Graph card to map solar power produced against total power usage, and my eyes can’t see the difference between the used colours, making it hard to parse the data being displayed.

If you have time, I’d really appreciate the help.

1 Like
50

Pretty sure you won’t be able to perform these changes if you’re running hassos. It would require you to use a custom version of the front end and that would require CLI to get running, which you don’t have access to.

51

I am using a docker install so I can do stuff like shell into docker, install a text editor, and manually edit the specific file I found loading the color array in the DOM inspector. And that is what I did, a restart of HA and the colors are live.

I could have also copied the file to my config dir, then bound that file in place of the original, but this was a test so I did not do that. If I update HA the file and its name are likely to change and revert to my unedited state, but I am ok with that. Either way this is the file I modified:

/usr/local/lib/python3.9/site-packages/hass_frontend/frontend_latest/f1bda580.js

The array is right there on the first line, const i. I know this really isnt a step by step guide, but there are multiple installation methods, and they all use a different set of steps, the only thing consistent is that in 2021.8.6, in the python packages folder, the latest hass frontend file f1bda580.js needs to be modified.

The colors are used sequentially, but I do not know quite how. In line graphs, each graph starts at the first entity/color then continues, the first is drawn over the second, and so on, so a “noisy” line should be under a smooth line or the smooth line can be invisible if they mostly overlap. In other graphs, I think there must be some list of text states, and the colors loop through, since different graphs seem to have the same color for the same text state.

52

It should be in the same place for hassos but he’d need portainer to get to that loc.

53

Hi @richieframe, thanks for writing all of that out. I actually might have been able to follow it, but unfortunately @petro is quite right: I can’t access that location because I’m running HassOS. I appreciate your help nonetheless.

54

I could log in into the container and this is the color array (first part)

["#377eb8","#984ea3","#00d2d5","#ff7f00","#af8d00","#7f80cd","#b3e900","#c42e60","#a65628","#f781bf","#8dd3c7","#bebada","#fb8072","#80b1d3","#fdb462","#fccde5","#bc80bd","#ffed6f","#c4eaff","

I have one history graph that is using the SAME color, #377eb8, for two states, as can be seen here:

image

I confirmed this using a color picker, both idle and cooling are using #377eb8.
I checked the entire array and there is no repetition of the first #377eb8 entry, so I am guessing this could be a bug in HA. Has anybody ran into this issue? This wasn’t a problem with prior 2021.6 and older versions, as far as I recall. I could clearly see idle and cooling states in the graph, with different colors

55

One of those states is blue, the other is the pink one, there might actually an open bug report about how the states text is represented unclearly, but you can mouse over the color in the graph and it will list the state

56

The pink state is “Fan”, the “Idle” state and the “cooling” state are both blue, it’s weird

This is the mouse over of “idle”

image

and this is “cooling”

image

there seems to be something wrong

57

Interesting, that must confirm my suspicious that:

A: it just loops the colors when there are enough states to need them
B: there is no obvious logic to which text states get which color, my guess is a first come first server enumeration, and something like a camera got idle first in line for blue

58

I thought this was fixed for a bit…but I just went to look at my heating graphs and see its unreadable again grey vs grey-purple for idle/heating (options “idle/heating/aux-heating/cooling”)

Similarly the fan “idle/running” is dark-red vs brown and very hard to see.

Here’s a screenshot on desktop, its far worse on mobile app.

image
image1628×299 44.4 KB

59

Just went chasing down a specific history graph for troubleshooting…this is nuts. How does it pick this nonsense?

cyan-vs-cyan?! Come on!

image
image1652×200 16.3 KB

60

What did happen to the issue you were asked to write up?

61

No one created the feature request or issue. All I found was this

and this from 2016

Probably don’t need to create anything, just vote on the second one from 2016.

62

There was another bug written up that appeared to be the same thing already too, though I haven’t found documentation about it in things I’ve read thru so far if the pull request that could work around it was actually brought in already.

And referenced in a pull request it looks like

63

Shameless plug: history explorer card :stuck_out_tongue: Solves the visibility problem, makes the history colors themeable and much more.

What do you suggest they should do ? Currently they use a fixed pool of predefined colors they sequentially assign to states as they come along. This is a reasonable way to do it. It will guarantee that same states across different entities will receive the same color and it will reduce the risk of collision between two similar colors. It will however not guarantee continuity. If the order of entities or states displayed in entities change, then the color assignments for a certain state will change.

There’s not 100 million ways of doing this. You can’t know the states you’re going to encounter and you don’t know in which entities they’re going to show up. You don’t know which of the states (that you don’t know) are going to end up side by side in which entity. The code isn’t psychic, it can’t read your mind.

In my history explorer card I linked to above I used a different approach. I used MD5 hashes of entity state names to generate colors for them. This solves the continuity problem (a certain state will always retain the same color regardless of order), but it can generate similar colors on a same entity timeline for adjacent states. There’s always advantages and drawbacks, there’s no perfect system for automatically determining colors.

Or just assign manual colors to the states you care most about.

1 Like
64

I haven’t used this (yet) but that video makes it look ridiculously good.

65

That should be built into core. Also, if you want more hits, you should look into getting that into HACS. Very nice card.

66

Thanks, I actually did apply for HACS inclusion a while ago, but last I checked there were over 20 applications waiting to be reviewed. I guess Ludeeus is still working on the backlog that built up over the holidays. Gotta be patient :slight_smile: