Yeah, as arganto mentioned, FR stands for feature request. Just create an issue on the github repository and summarize your ideas. No need to code anything (but you’re certainly welcome to do if you want 
)
Looks like the cards code was corrupted. Maybe a cache thing. (1000L per hour 
)
haha, no the number was correct… was refilling my pond… 
BREAKING CHANGE WARNING, PLEASE UPDATE IF USING HA 2023.5
A breaking change in the recorder component in HA 2023.5 broke the recordedEntitiesOnly setting. An error message will be displayed in the entry field and the dropdown list will remain empty. Please update the card to V1.0.46 if you use HA 2023.5 or later.
This will also fix a translation / localization problem with state names, due to a breaking change in HA 2023.4.
This is now available in V1.0.46:
legendVisible: false
Thanks a lot! Already installed update and will test it during the weekend!
EDIT: checked and it works perfectly! Thanks so much!
hello! please could someone help me to understand a strange behaviour of my history explorer card?
If i use zoom option e click on the right side of my timeline (to view in detail the last hour) tha bar goes 1 year before… and then… if i reset with double click on the date and reuse the zoon the timeline works.
thanks a lot.
best regards
francesco
Don’t just click when zoom is active. Click, keep the mouse button down and drag to select the zoom area you are interested in (or tap, keep the finger on the graph and move it to select the area). See the video on the github repo on how to use it.
If you just click / tap once, you are basically asking for an infinitely small area and the card does indeed react strangely. I’m going to change the code to ignore single clicks without dragging.
Any idea why on Firefox the entire browser stops/hangs and on edge not when using this card?
Perfect! Thanks a lot!!!
Just for fun… Can I change the date format (view screenshot) with dd/mm/YY - hh:mm:ss
Thanks a lot
Date and time format are dependent on your current locale / language.
I have some problems with automatic scaling on y-axis. Here is the code I use for chart:
- type: custom:history-explorer-card
refresh:
interval: 5
defaultTimeRange: 5m
showUnavailable: false
uimode: dark
uiColors:
gridlines: '#444856'
labels: '#A4A7B4'
buttons: '#2C2E3C'
selector: '#2C2E3C'
closeButton: '#0000001f'
labelAreaWidth: 50
labelsVisible: false
uiLayout:
selector: hide
toolbar: hide
header: hide
graphs:
- type: line
entities:
- entity: sensor.internet_speed_in1
color: '#F5A624'
fill: '#F5A62422'
name: DOWNLOAD
scale: 1
- entity: sensor.internet_speed_out1
color: '#6A34E0'
fill: '#6A34E022'
name: UPLOAD
scale: -1
and here is chart looks after refreshing the view:
As you can see vertical scaling effectively hides details that should be visible in this view. So my expectation with automatic scaling would be to see something like that:
Clearly seems like the issue are very high spikes in data, that are present in history, but are outside of visible chart area. If I zoom (or scroll back) out to longer period of time, these are clearly visible and in line with scaling for default view:
Seems like while drawing the series, chart is actually retrieving much more data from the past that is actually used fo draw the chart and taking this data into account while calculating the scaling. Or I’m missing something fundamental in my configuration?
Usually it not visible for chart that are showing more uniform/consistant data, but this chart is somehow extreme case as for most of the time througput of access point is close to zero/very minimal, but the there are spikes for relatively short period of time, when lots of data is being transferred…
Bonus question; one of the features of this card that I love is that you can have one card, but multiple sets of data series. So effectively it looks like few charts, but display parameters are linked, so any scrolling or zooming on data is applicated for all charts in group, allowing for bvetter corelation analysis. But this work only in vertical layout. So would it be possible to have few separate cards, grouped functionally together (by name?), so similar zoomin/panning can be applied to all of them at once… e.g charts in horizontal stack, or to extreme to charts placed anywhere in the dashboard per rules applied by lovelace (masonry layout)?
Correct. That’s done on purpose. It’s usually ±12h from the edges of the visible area, but can vary a bit depending where you scroll. The reason this was added is simple : not having the graphs jump around like crazy while you scroll. If that filter is absent, every time you scroll and the moment you release the mouse button (or lift your finger), the auto scale will completely change the shape of the graph by zooming in and out. That’s extremely confusing, rendering the card borderline unusable, because you lose the continuity of signal. I tried to replace it by a time delayed animation, so that the brain could visually follow the refit without losing continuity of signal, but that was super weird too and waaay to slow for my excessive own fast-scrolling habits
Maybe a manual ‘refit to visible’ function can be added to the existing lock icon. Maybe by double clicking it (and it would automatically lock this refit). Another option (which has been requested as an FR for a while now) is to add support for a log-scale on the Y axis. This could be useful for data like this, avoiding the huge spikes and making it more uniform.
On another note, since I don’t see that in your code, If you often have huge singular spikes in your graph, you might want to switch decimation to the accurate mode. Otherwise the spikes could get lost when you zoom out.
Because it’s a single card with multiple graphs. The instance of the code has easy control over all the graphs within its own card. And since they’re guaranteed to be aligned, both visually and conceptually, it makes perfect sense to sync them.
Technically yes. It would require to link cards by name/ID and remotely control them from another card. Normally, individual instances of the card are tightly isolated from each other (and from other cards), so this feature would need a clean way to break out of this isolation. Not entirely sure about the general use case for such a feature though. Feel free to file an FR and we can discuss !
I’ll test decimation option, but as I understand how it works, it might not help. On the first screenshot the spike is just ouf of view, so I do not think this would change how visible part of the graph look like. ±12h window effectively means that is is not posible toachieve proper scaling for 5 minutes window with low bandwidth consumption, as it always be some spike within this window. Perhaps instead of fixed time window it would be possible to have something like ±10 times graph_span timeframe to be preloaded?
For the second question; frankly speaking I’m not so much sure about actual use case. The reason I asked is that most of my system monitoring dashboards have 2 mpodes implemented, one for desktop (and then chard cards are aligned horizontally) and one for mobile (then these are aligned vertically). In second scenario would be nice to have their scales aligned, but for now these are separate cards differently placed within grid card, not one vertical. So very specific case and I’m not sure if this is worth effort to implement… was just asking, perhaps this would be another one line of code 
Maybe, but it’s not going to entirely solve this problem. It’s enough to have one big spike just outside of the visible area. The only real way to handle this is to turn off the time range filter entirely. But then scrolling becomes unusable.
In the end it depends on the use case I think. If the use case is to have a permanent graph that always shows the last hour or something, with automatic updates and scrolling on state refresh. Then this could force an auto-scale limited to the visible part only, but the longer range auto-scale would kick in as soon as you start scrolling around. If on the other hand your use case is to always have a perfectly tight fit auto-scale wherever you scroll, then a manual rescale by double clicking the lock icon would be more appropriate I think.
Quite a bit more than a single line of code I’m afraid
Is it somehow possible to use combineSameUnits: true only for some graphs or a single graph in one card and not for the whole card?
I have this working to replace the history chart in all HA cards
type: custom:history-explorer-card
infoPanel:
defaultTimeRange: 5d
uimode: dark
showUnavailable: true
header: hide
lineMode: curves
entityOptions:
sensor:
color: '#F5A624'
fill: '#F5A62422'
Works fine on my laptop but it’s not working on a tablet running Fully Kiosk. Any ideas why that would be?
It is a per device setting. You have to activate it there as well. Guess you missed this step?
Looks like I did, don’t recall reading that anywhere in the docs but I must have missed it. Thanks.
I have a page setup that shows some stuff related to my bluetooth trackers. It contains a couple of line graphs and a timeline graph. I’m trying to get the line graphs to not show data when the sensors are unavailable, but I’m either doing some wrong or don’t understand the settings. Here’s the YAML for that entire page:
type: custom:history-explorer-card
card_mod:
style: |
ha-card {
--ha-card-border-width: 0px;
}
cardName: presence_history
header: Presence History
defaultTimeRange: 12h
refresh:
automatic: true
showUnavailable: false
stateColors:
main_bedroom: coral
greatroom: darkseagreen
study: lightblue
uiLayout:
selector: hide
graphs:
- type: line
entities:
- entity: sensor.sp_distance_from_bedroom
color: coral
- entity: sensor.sp_distance_from_greatroom
color: darkseagreen
- entity: sensor.sp_distance_from_study
color: lightblue
- type: timeline
entities:
- entity: sensor.espresence_shannon_iphone
name: SP
- entity: sensor.espresence_kyle_applewatch
name: KW
- type: line
entities:
- entity: sensor.kw_distance_from_bedroom
color: coral
- entity: sensor.kw_distance_from_greatroom
color: darkseagreen
- entity: sensor.kw_distance_from_study
color: lightblue
and an image of one of the line graphs. You can see where there’s a space of time where a sensor was unavailable, but rather than seeing nothing, the graph areas are connected by an extrapolated line between the two good data points.
Any suggestions on what I’m missing?
