Looks like that has the same functionality as ChartJS which is what HA uses.
Last I checked (Probably 2 years ago) OpenHAB didn’t have anything built in.
LOL You left OH the same time I left HA for OH. They have changed a LOT since then and not necessarily for the benefit of the users…
It was likely new for 3.0 or 3.1 which was released recently. They have a completely different front end based on Framework 7.
1 Like
look through the window. software world doesn’t end on HA, OH and Demoticz. I’m not comparing to those ones. There are thousands of areas which incorporate requirement of analyzying value changes in the function of time. And HA simply doesn’t provide satisfying built-in solution for that.
Indeed, everyone can install Grafana. But do you still remember? Obviously users would like to see more satisfying built-in solution. Claiming “other home automation systems are not any better” is far from progressive thinking.
3 Likes
I understand it doesn’t. But comparing home assistant to packages dedicated to graphing is unrealistic and unfair. You’ve been nothing but hyper critical about this software while not even lifting a single finger for a single development contribution. You continuously think that it can be done better, claim you are a developer, and trash the software left and right. I’m just fed up with your attitude to be honest. How about you contribute with your development skills to help instead of being an armchair developer?
3 Likes
How about to not attack everyone who says there is room for improvement?
Again you read something else than it’s written. I’m comparing to other software systems which provides built-in solution as tool for debugging. All what I suggest is to consider replacing current library being used for history with something more flexible.
Don’t get why it hurts you so much? Because it could work?
1 Like
I never said that it couldn’t be improved. In fact, I said that someone should write up a feature request. That wasn’t good enough for you, do you remember that? That conversation wasn’t too long ago.
I will continue to respond to your petty remarks because they are largely not true. You can try to take the highroad here but your post history (and admin history) shows that all you do is complain about HA, badger volunteer developers to make changes you want, and trash talk the main developers. So no, I’m not attacking everyone. I’m just responding to you.
Let me quote myself from above:
If you googling the package, you’d see that it has all sorts of functionality and could be updated to incorporate changes. There’s no reason to change the package because it can be done with ChartJS. So circling back to my original comment: Create a feature request, get the word out and get people to vote for it. If the feature request gets enough attention, changes will happen.
1 Like
I’d love to hear what other home automation packages offer for graphing, seeing that home assistant isn’t up to today’s standards.
I came from homeseer and the graphing was inferior to HA (IMHO). I ended up writing perl scripts to process data and gnuplot to create the image. The data was written to a .csv which the perl script processed and cleaned data (duration and remove duplicates). I controlled through cron to update the graphs for display.
1 Like
IMHO, focusing on graphing capabilities while the history management of the DB is rather inflexible, to say the least, is probably premature.
Go Vote! 
2 Likes
I’d almost call it a bug at this point…while it was annoying before, there was usually good contrast. Now its pastel colors with low contrast at least in the app…the light-purple on light-teal it picked is AWFUL.
2 Likes
Then write up an issue to have it return to the original colors. I never said that wouldn’t get changed. It’s a feature request in regards to users configuring the colors to what they want. There’s a difference.
Secondly, my post was about how unreasonable people were acting over it ‘Not being in the change logs’ and 'why would they change this, no one wanted it" when they didn’t have the full story.
TLDR:
Write up an issue to have it go back to the original colors. Or wait for the feature request to be implemented to configure your own colors.
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
2 Likes
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
1 Like
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?
1 Like
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
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.