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.
1 Like
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
Shameless plug: history explorer card 
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
I havenât used this (yet) but that video makes it look ridiculously good.
That should be built into core. Also, if you want more hits, you should look into getting that into HACS. Very nice card.
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 
Hi,
I know this is an old thread, but it is essentially my problem: is there a way to change the colors of the histroy graph?
I tried theming as in the github CR but it does not seem to work anymore.
graph-color-1: "#00ddff"
graph-color-2: "#0000ff"
graph-color-3: "#ffdd33"
graph-color-4: "#ff00ff"
Is there a new way?