Because people want it… again that’s how voting works 
. Contrary to what you believe, there is no crazy conspiracy behind the development here.
3 Likes
You obviously don’t want to understand what I’m saying. It’s not about conspiracy. It’s about the fact that work on HA is voluntary. so devs are allowed to chose what they will work on. if it somehow correlates with voting results - great. But it’s their decision, not guaranteed rule.
It’s enough to look at FR subforum (not even speaking about wth) to see that there are delivered features with lower number of votes, while others with more votes are still waiting for better times.
1 Like
Exactly.
This is why Petro’s statement is not true. Maybe because it’s oversimplified. But not true.
Sorry to interject here (and call me lazy for not researching the answer1) but is this referring to the recent template trigger feature that couldn’t be used in packages? Are you saying that has now changed and they can?
Sorry if I’m barking up the wrong tree. (But I really hope not!)
1If it was announced somewhere I certainly missed it.
No. They are still unable to be used in packages. And will most probably remain that way.
1 Like
ya, Petro got me there too. Although you say template: will probably never be supported in packages, I still hope they will… too bad we can not revote or have a crying heart here in the forum…
Frenck said earlier on it can be done, but is rather complex. Dont recall the exact wording. So, maybe, if we keep on presenting good examples and reasoning, the dev’s will decide to make the effort.
I’m sure Klogg doesn’t like what you say, though the heart would give one that impression
I wouldn’t say that. It’s been brought up many times and iirc there have been changes to refactor that code to make it manageable. Also there is no maintainer, so it’ll just take some time before we see anything.
Ok. Apologies for the misinformation. I got that impression from discussions on Discord weeks ago, but things move quickly around here.
What I said is how it works for the main team. It doesn’t include the volunteers.
Actually. some of the main team are employed by Nabu Casa to work on HA full time, if I recall correctly.
2 Likes
Well, I think this is not only the question of skills, but also problem with the way that specific functionality is implemented. In case of these charts we are talking about library developped by external to HA developers, that maintain its functionality and debugging separately. Obviously it should be possible to modify this library before including it into HA to support custom colors, but then every time library is updated by original developers, same customization would need to be reapplied before updating HA, to keep consistent behaviour across versions. Not easy, especially when some major changes in the library are made and it need to be investigated over and over how to customize…
Said that, I would love to see custom colors being implemented 
tbh this history page doesn’t meet todays standards user experience wise. It’s ugly and functionally limited. It stands out comparing to other parts of HA.
Maybe it’s time to consider replacing the library. Or write own. Instead of investing time to something which seems to be obsolete. From this point of view I understand why devs are not prone to work on this.
I’d love to hear what other home automation packages offer for graphing, seeing that home assistant isn’t up to today’s standards.
2 Likes
SmartThings → None…
You get graphs for Temperature, Humidity, Power usage, all the built in ones. No option to change anything, 3 views each, Minutes, Hours, Days. No customisation option at all.
But you can push your data with custom SmartApps to your own Influx DB and then plot for yourself outside the app in Grafana.
1 Like
I believe many openHAB people use Grafana although there is some graphing capability in the latest versions.
I’m not saying HA is not up to date, but this particular page, the way how it’s organized and what features provides renders it almost useless for most needs which would require looking at such a page.
replacing it with grafana components seems to be great idea. However I don’t know is possible/feasible.
I’m using Home Assistant → TimescaleDB (via the LTSS component) → Grafana.
TimescaleDB + Grafana is absolutely the way to go, one hundred percent. The reason for this is two-fold:
-
TimeScaleDB has native support for time dimensional slicing (per day, per week, per month, per year, per hour, etc) and Grafana can utilize this natively. It enables you to create useful insights with relative ease.
-
TimeScaleDB has a very good implementation of materialized views. It enables light-weight dashboarding, while at the same time the data is always accurate up to the very last second. Incredible.
My vote would go to a supervisor addon that incorporates LTSS, TimescaleDB and Grafana in one package. Plus a GUI configuration to setup the materialized views. Setting this up by hand was not so easy.
The History page has all the non graphable elements at the top. Those lines of colour telling me that all my automations have been on for the entire time the graph is showing are, frankly, bordering on pointless.
I’d rather see interesting stuff like temperatures and humidity near the top.
The point I was trying to make is that this quote
is a baseless claim because no other home automation package provides a solution that does what this phrase eludes to. All other home automation packages require the user to write there own plugin or use graphana.
TBH, it’s nice that home assistant has a history out of the box without any extra configuration. But if you want to go the extra mile, then you should use the community graphana addon.
1 Like
Yep, no contest there!!