Yup, was added to V1.0.13, see the readme !
V 1.0.13 is up with a lot of new customization options, because everybody loves to customize their graphs 
You can now specify colors, line modes, y axis limits and more for specific entities or entire device classes. That works for both graphs predefined in the YAML and for dynamically added graphs. So for example, you could pre-set a blue color with a 0…100% Y axis range for all humidity sensors you may add. Or maybe just for a single specific entity.
Oh and you can now use CSS variables, like the ones from a custom theme, as colors for graphs, states or UI elements in the card.
3 Likes
As @arganto mentioned, there’s an example on how to do this in the readme. It’s pretty well hidden. I should probably make this more explicit in the documentation.
Thank you for this great addition 
I was wondering if it’s possible to plot some chosen entity state attributes instead of just the state? It would be very useful IMO - there are some sensors that store a lot of additional info in the attributes.
1 Like
I got it, thank you so much.
Excellent, thnak you.
Technically yes, practically it would incur a significant performance hit. Attributes are stored in a very strange and inefficient way in the history database (even less efficient than states). To increase performance somewhat, the card only requests a minimal database snapshot which does not include time series attributes. If a graph uses attributes and another doesn’t, the card will have to issue multiple database queries because both can’t be combined due to limitations of the HA database REST API. So that would make the entire card slower, even if you just have a single graph showing an attribute. It would also make the code more complex.
So it’s a question about whether or not that’s worth it. Frenck mentioned in 2020 that time series attributes are being phased out. Time series attributes are the ones that are stored as ongoing data streams at the same rate as the states, not things like last_changed attributes or similar. Would be interesting to hear some more opinions of whether or not supporting attributes is worth it.
Alex, Thanks for your work on this card, it really presents the data well. Are there (or could there be) plans to:
a) add to the available time ranges
b) allow a default time span to be set in the YAML
Which additional time ranges would you like to see ?
Good idea !
4-weeks, 1 year …
Your HA history database stores 1 year worth of data ?! Note that statistics are not yet supported (but might be at some point) and neither are connections to external database engines like influx, which I think would be out of scope for this card (just use Grafana for those).
Not sure, maybe not ( i did switch to MariaDB in the hope I could retain more), but I’d ulimatley like to see temperatures over an extended period. Maybe that’s where ‘statistics’ come in? I am moving sensors to HA and previouly stored them (via a Pi) in a RRD database so am used to the option of seeing longer periods (albeit being RRD, with averaged data). I might need to look at Grafan too.
Thanks for your quick reply
By default the data retention time is 10 days, after that the data is purged. This can be overridden in configuration.yaml using the purge_keep_days key under the recorder component. That’s independent of the database engine (the default SQLite, MariaDb, etc). It’s usually not a good idea to keep more than say 14 days, as the recorder component is quite inefficient.
Statistics is an additional long term storage facility that stores data with reduced temporal resolution over a longer timeframe. It was a bit ‘bolted on’ the current system and works alongside with it. It uses a different database structure and is not directly related to your ‘short term’ history. I might add support for this at some point, but I need to find a way to combine both in a single graph. So if you scroll beyond the normal high resolution history, it would seamlessly switch to long term statistics if available. That’s not as simple as it sounds though 
2 Likes
Having said that, mysql is far more efficient than the default sqlite, and it is feasible to keep data longer with mysql (or postgresql, and probably others too).
Out of interest, what kind of data retention time frames are we talking here ? Is it common to have a month of data or more in the ‘normal’ history DB using alternative backends ? Not including backends that bypass the recorder component, like influxdb.
If so it might make sense that I add these longer time ranges to the card even before I add long term statistics support.
I have 90 days, but really only for one reason, and I could do finer control to just get 90 for the relevant entity.
I guess you could progammatically test the number of days retention on each setup?
2 Likes
Interesting. Wasn’t aware that these kind of time frames where possible with the recorder component. It would definitely make sense to add longer ranges to the card then. I just have to keep an eye on the local cache memory usage, which could go up quite a bit on longer time frames.
Not as far as I know. The API is very limited. I could do a mock db query over a several month period for a single dummy entity and see what comes back. But that’s not very performance efficient. And as far as I know I don’t have access to the recorder component config over the JS interface. I’ll poke around the HA source code a little and see what I can find.
2 Likes
If worse comes to it, do you have access to configuration.yaml?
Nah, the frontend JS sandbox runs locally on the browser and unless HA exposes configuration.yaml to the internal webserver (which would be a vulnerability of catastrophic proportions), the card doesn’t have access to anything on the remote filesystem (unlike an actual custom integration). It does have access to the websocket API and the REST API though. I’ll have to see if I can get something out of those.
That said, I don’t think there would be any real drawbacks just allowing longer time ranges for the user to select, even if the db ends up only storing a few days. It would just come back as empty.
You are really showing my profound ignorance of JS, and in fact web design in general
1 Like