Understood. Thought and assumed, that there is a setting in the framework (here chartjs), after which time of dragging the chart is redrawn, so not every millisecond or mm of dragging, because I think this is the problem here. Or to switcih of (optionally) the re-drawing while dragging until release (same as it is happening when I drag the other chart, then the above is only redrawn, if I release the dragging on the one below).
The dragging isn’t done by chartjs, which doesn’t really support these kind of realtime operations. It’s done by the card itself and I kinda hacked support into chartjs for it. The redrawing is not done on a fixed time delta but every time you drag over a certain distance. Increasing the distance will reduce the amount of redraws but at the same time decrease fps. Which will in turn make it choppy on higher performance systems, while not necessarily making it much better on low end ones. The only really good ways is to either push more on the GPU (WebGL) or to reduce the data set to be drawn (more aggressive decimation). Javascript is not a good language for these kind of low level data driven optimizations. If this were C++, there would be a ton of things we could do to make it faster. But not on JS.
If you switch off the redrawing while you drag, you don’t know where you’re dragging to 
Thought about only the graph, not the grid or x-axis. But if all this is not in the framework, I understand, that it is hard to improve.
The problem is, that the whole browser/app is really getting stuck and only a shut down and restart of it solves the issue, until the next dragging. Perhaps if I would wait for 10 minutes or so. So I wonder, what the chartjs guys think on this problems with webkit (but of course than this is not your problem). An iPad pro should have enough power, so I think it is more webkit problem, than the device.
Anyway, thanks for the help.
I still wonder, why it is happening in Safari with this big issues. Even if I try to drag really fast and release directly, it gets stuck where I thought it would only draw perhaps 2 times. It seems that webkit still draws every intermediate position and then only showed the last at the end.
I suggest you open an issue about this on Github and we can do some more tests and see why that happens on Webkit/iOS. On Safari OSX (both BigSur and Monterey) things are really smooth, so it’s probably an iOS thing.
Excellent work, thank you so much for this card.
One simple question at this point: Is possible to change the card title from “History explorer” to something else?
I love this card. I mainly use it to track humidity in my home.
Is it possible to chose the range of the value on the y-axis? Sometimes my sensors drop out of my zigbee network and are recorded as 0, so the y-axis range goes from -20% to 100% and im really only interested in the range of 40% to 90% as this covers the values 99.9% of the time.
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