Same here, now I delay upgrades until I have nothing better to do and always afraid of missing some functionality or feature I’m used to. I’m one unhappy camper now…
1 Like
Just thought I’d share my personal solution to this, since it doesn’t seem to be getting any traction, despite it being a feature regression with no option for users to provide it back even optionally without jumping through a bunch of hoops.
This is how I’ve provided the same old experience for myself (and FWIW I don’t have any trouble loading all my entities in under a couple seconds, with a multi-day lookback):
- Create a notify file-logger in your
configuration.yaml:
notify:
- platform: file
name: entity_log
filename: /config/www/entity_log.txt
timestamp: false
- Add a script that writes all your entities to the above file notifier:
print_entities_to_file:
alias: "Print Entities To File"
sequence:
- service: notify.entity_log
data_template:
message: >
{% for state in states %}{{- state.entity_id -}}%2C{% endfor %}
- Run the above script
- In your file editor, open the listed logfile and copy the entire list of entities
- Add a custom panel in your
configuration.yamlthat links to the full history page, with all the entities available to be viewed:
panel_custom:
- name: Full History
sidebar_title: Full History
sidebar_icon: mdi:clock
url_path: "history?entity_id={paste your list of entities here}"
module_url: /api/hassio/app/entrypoint.js
embed_iframe: true
require_admin: true
You’ll occasionally have to update your list, but it’s as quick as running the script and doing a quick copy-paste when you want to update your “all” history view. Definitely not as good as a “Show All” checkbox would be on the history page, but better than using a dedicated History Explorer (that I’ve had nothing but performance problems with) or having to add and remove entities one at a time, and definitely better than having nothing at all.
1 Like
Workaround which works wonderful for me,
Lovelace-Card auto-entities from hacs, displayed in a panel view
type: custom:auto-entities
filter:
include:
- {}
exclude: []
card:
type: history-graph
2 Likes
Hello Mr ransel …
This seems to be a good solution and I am trying to implement it, but for some reason I am struggling with creating a notify file-logger in my configuration.yaml; it doesn’t create the file and then the script can’t fine notify. It looks like the notify function in YAML isn’t recognized when I restart HA although I just copied and pasted the code you provided … I must be doing something wrong, but haven’t been able to figure it out so far …
Thanks for sharing this.
I’m not sure how to use this. Is it a Dashboard? A Card on an existing Dashboard. Entering this text anywhere doesn’t seem to work for me. Any advice? Did you ever get the scroll bars working like you wanted?
It’s code for a custom dashboard; you will have to make sure you have the helper and a couple of custom cards from HACS installed to make use of it. Also, you may have to tweak how the code is arranged in the raw configuration editor.
it’s a view, in panel mode
I do have some iterations made, and scroll yes
- title: History domains
icon: mdi:history
path: history_domains
type: panel
cards:
- type: entities
entities:
- entity: input_number.history_span
- entity: input_select.domain
- type: custom:hui-element
card_type: entities
entities:
- type: custom:config-template-card
entities:
- input_number.history_span
- input_select.domain
variables:
span: states['input_number.history_span'].state
domain: states['input_select.domain'].state
card:
type: custom:auto-entities
card:
type: history-graph
hours_to_show: ${span}
card_mod:
style: |
ha-card {
box-shadow: none;
margin: 8px -16px 0px -16px;
}
filter:
include:
- domain: ${domain}
card_mod:
style: |
ha-card {
box-shadow: none;
}
.card-content {
max-height: 800px;
overflow-y: scroll;
}
or use the great history-explorer-card as panel mode:
- title: History
icon: mdi:history
path: history
type: panel
cards:
- type: custom:history-explorer-card
cardName: history-panel-view
showUnavailable: false
recordedEntitiesOnly: true
lineMode: stepped
uiLayout:
selector: top
toolbar: both
Some small additional tips to make the history explorer card easier to use in panel mode, as well as making it more like the old history, for those who prefer.
Make the top controls sticky, so you keep easy access to the navigation UI when you have lots of entities added and have to scroll a lot vertically:
uiLayout:
selector: top
toolbar: both
sticky: top
Add an auto refresh option if you want the graphs to follow the database changes and show the current entity values in the label too (showUnavailable is false by default, so you don’t have to specify it):
- type: custom:history-explorer-card
cardName: history-panel-view
recordedEntitiesOnly: true
lineMode: stepped
showCurrentValues: true
refresh:
automatic: true
By default, the built-in history only loads the last 3 hours of data, while the history explorer loads between 24h and 48h. So it might be slower on open (but you see more !). If you prefer the built-in behavior, add this to the config:
defaultTimeRange: 3h
Long term statistics support is automatically enabled by default, so you will get the long term data merged into the history for sensors that support it.
Also make sure to get the latest version of the card, there have been significant performance enhancements.
1 Like
Magician!
thank you so very much for your ongoing efforts!
you make this community shine!
Sorry to be so dense, Marius, but I can’t figure out what to do to get whereever I need to paste this yaml. do I create a Dashboard, set it to Panel, and ad a Manual card? That doesn’t work. I tried ticking Sub View, and that did nothing. It say No Card Type specified. Any further details would be appreciated.
I’ll look at the history-explorer-card too since that is an actual card option listed in the table!
Those are the complete yaml lines of 2 separate views.
Depending on your way of editing/ splitting up your config ( I use yaml mode) just copy that and maybe delete the leading -. Ofc then adjust the spacing.
And yes, you do need the entities and cards I use there. Can’t just copy blindly and expect things to work out of the box
Ofc. I forgot that the individual pages on the Dashboard are called Views. There are also SubViews in Dashboards. Semantics is everything! 
I just loaded the history-explorer-card and it IS pretty awesome.
yeah, you could just as easily load it on a subview. actually I might just do that to save space in my menus 
Hi Alex, I’ve installed the history explorer card and the customization is completely insane! I’m loving it! Reminds me of Button Cards, which are all over my HA Dashboard.
One thing I’ve found is that any wildcard-added entities in the filter bar at top disappear after I restart Firefox, likely because I (1) use Private Mode all the time so no cache is maintained, and (2) my cache is cleared when closed even if not in Private Mode.
I tried adding wildcards like sensor.* to the YAML, but the Card complained. Is this possible, or is the solution for a persistent set of entities to list them all individually? Maybe I missed it in the docs, but I did read it! 
EDIT: NM, I just saw you respond to an Issue on GitHub that wildcards are not yet supported. Unfortunately, my entity list (from my Recorder file) is pretty long, so hopefully wildcards, or even better, using what is filtered by the Recorder file will become an option in the future. That would eliminate the need for the multiple View All from Recorder File feature requests being made (and ignored) to FIX the built-in History card - like THIS one, and the one I made. Cheers.
Thanks, glad you like it.
You didn’t mention this in the github discussion, but yeah, in private mode the info will be cleared by the browser when you close it. It’s not a cache or a cookie, it’s stored in local browser storage (some other HA frontend data is stored there too). If you can add an exception to your browser for it to keep persistent data from your HA instance, then the dynamically added wildcard entities will remain. You can clear the cache and the cookies, that won’t affect it.
And as mentioned on the GH issue, if you want only entities that are part of the recorder, add this:
recordedEntitiesOnly: true
You can see that this line was part of Marius example config too. I think everybody uses it. Maybe I should make it the default.
1 Like
For me, this is what makes HEC UNmissable and I can’t believe core still doesn’t use this.
So glad I asked you to add this. And Yes, it should be default 