Anybody noticed that sometimes two different states are drawn with the same color by history-graph (2021.8.1), like here:
“idle” and “cooling” are both drawn in light blue. Could this be a configuration issue? any pointer on ways to influence color selection for history-graph would be awesome
So, for everyone complaining about the colors (I am not one of them), it appears that they were not “changed”, so much that chartjs was not using them before, but it is now.
I found out from the dom where the colors were being loaded from, which does not appear to be chartjs at all, then I went looking for those specific combinations of colors on github. It looks like the search is broken, because…
0 results I get. BUT it was trivial to actually find the constants being loaded, and they appear to have not been changed since they were added in may 2020 as part of this PR for the calendar panel:
So now with the new chartjs, this is the color list, looks like it starts pulling at index 2 instead of 0 for some reason. Though I have not tried changing the constants file, or finding for the frontend code that pulls it (since that search didnt work), I would assume that one can modify it to their liking for custom colors.
If I could find were it is read, a configuration may be able to be added to the user prefs
It looks like that constant file is perhaps the “original” file, and with cjs3 it is now pulling from src/common/color/colors.ts
That means simply that the first 2 colors were deleted from the list, resulting in charts now starting with the third. I am going to change some files and see if I can get not just a return to the original colors, but a better order
Would it be then possible to change the library so it is pointing not to specific palette inside its own code (src/common/color/colors.ts) and specific colours within the palette but to use palette defined in HA themes?
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.
The frontend code is compiled, so that change would need to be made in the source code before compilation
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.
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.
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.
It should be in the same place for hassos but he’d need portainer to get to that loc.
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.
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:
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
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
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”
and this is “cooling”
there seems to be something wrong
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
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.
Just went chasing down a specific history graph for troubleshooting…this is nuts. How does it pick this nonsense?
cyan-vs-cyan?! Come on!
What did happen to the issue you were asked to write up?
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.
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
