New History in 2022.7 - Multiple dynamic History URLs by groups

For a long time i used the History only for a few entities included in the history config.

The new history panel is nice, but:
- the selections are gone after restarts
- the selections are gone after ‘Show more’ in a more-info dialog
- i want to have multiple sets with selections

You can bookmark the history in your browser, but then you have to edit them because they include timestamps.

So here is my (hopefully only temporarily) Workaround.

Create groups with the entities you want in the history set.
The ‘history_…’ is used in the python_script below to filter these groups out.

history_test:
  entities:
    - climate.study
    - light.kitchen_lights
    - sensor.astronomical
    - sensor.available_ha_version
    - sensor.disk_use_percent
    - sensor.memory_use_percent
    - sensor.moon
    - sensor.outside_temperature

history_switches:
  entities:
    - switch.delayed_switch
    - switch.mqtt_test
    - switch.switch_state_revert
    - switch.test_switch

EDIT:

Just for the records this was my first atempt with a python script and an automation

Create a python_script that creates a sensor with the url paths as attributes.

count = 0
attributes = {}

for entity_id in hass.states.entity_ids():

    entity_domain = entity_id.split('.')[0]
    entity_name = entity_id.split('.')[1]

    if entity_domain == 'group' and 'history' in entity_name: # Here's the 'history' key from the group names above

        count = count + 1
        path = '/history?entity_id='

        for entity in hass.states.get(entity_id).attributes['entity_id']:
            path = path + entity + '%2C'

        attributes[entity_name] = path[:-3]

attributes['friendly_name'] = 'History Group URLs'
attributes['icon'] = 'mdi:chart-box-outline'

hass.states.set('sensor.history_urls_by_group', count, attributes) # sensor entity_id that is created

An Automation that populates the sensor on HA start and group reload.

automation:
  - alias: create_history_url_by_group
    trigger:
      - platform: homeassistant
        event: start
      - platform: event
        event_type: "call_service"
        event_data:
          domain: "group"
          service: "reload"
    action:
      - delay: "00:00:03"
      - service: python_script.create_history_url_by_group

Unfortunately UI cards actions and weblinks support no templating, but we can use the Config Template Card.
Here’s an example from the Entities Card Editor, i think yaml users know how to use it. :smiley:

type: custom:config-template-card
entities:
  - sensor.history_urls_by_group
card:
  entities:
    - entity: sensor.memory_use_percent
      hold_action:
        action: navigate
        navigation_path: ${states['sensor.history_urls_by_group'].attributes.history_test}
    - entity: sensor.ha_uptime
    - type: weblink
      name: History Switches
      url: ${states['sensor.history_urls_by_group'].attributes.history_switches}
  show_header_toggle: false
  title: Sensors
  type: entities

20220711_123729

From here, all credits go to @gonzotek who templated the groups directly into the config-template-card. :+1:

Now you can open the history with different sets of entities from anywhere in your Dashboards with tap_actions or weblinks.

Have fun!

2 Likes

Due to time limitations, I’ve been holding off on upgrading to 2022.7(.x), so I haven’t had a chance to play with the new history features directly, but I’ve been reading about them and some of the frustrations people have had with them. I like the idea of dynamically creating the urls, but I think we can take it step further and not require a python script and automation, thanks to Markdown cards and jinja templates.

Here’s a few examples I think might work(not being able to actually test the generated links in 2022.6) . The first one should replicate what you’ve done in python and template cards, @VDRainer. Then there is one that crams every entity in like the old History page would open with. And finally, a couple more examples for just a specific domain or multiple (it shouldbe possible to filter for other things as well, like entities with certain attributes, or parts of ids, probably devices and integrations, etc.):

type: markdown
content: >-
  {% for group in states.group %}
    {%- if "history_" in group.entity_id -%}
      [{{ state_attr(group.entity_id,"friendly_name") }}](/history?entity_id=
      {%- for group_entity in expand(group) -%}
        {{ group_entity.entity_id }}{%- if not loop.last %}%2c{%- else -%}){%- endif -%}
      {%- endfor -%}
    {%- endif %}
  {% endfor %}

  [All History](/history?entity_id={%- for entity in states if entity.domain not
  in ["automation", "zone"] -%}{{ entity.entity_id }}{%- if not loop.last
  %}%2c{%- else -%}){%- endif -%}{%- endfor %}

  [Zones](/history?entity_id={%- for entity in states if entity.domain  in
  ["zone"] -%}{{ entity.entity_id }}{%- if not loop.last %}%2c{%- else -%}){%-
  endif -%}{%- endfor %}

  [Sensors and Binary Sensors](/history?entity_id={%- for entity in states if
  entity.domain  in ["sensor", "binary_sensor"] -%}{{ entity.entity_id }}{%- if
  not loop.last %}%2c{%- else -%}){%- endif -%}{%- endfor %}

Note: In my Home Assistant instance, both the All History and “Sensors and Binary Sensors” links break Chrome (and possibly other browsers)… it complains of long urls if I try to open the links in a new tab(although it appears to possibly work in the same tab…can’t say for sure until I get on 2022.7). Smaller installations (mine has a tad under 1000 entities) might work ok.

Excessively long URLs are not something we can really do much about other than by lowering the number of entities being passed in to the url. So some additional work on the History page (e.g. bringing back the old ‘show all’ functionality in some form, and providing an alternative to urls to saving entity sets) would still be most welcome!

Edit: The long url error isn’t coming from the browser, some quick Googling on the error suggests it might be the aiohttp library Home Assistant uses producing the error (gives me some small hope this can be fixed or worked around).

1 Like

Thanks for your response.

That was my first idea too, but i dont want to add markdown cards wherever i like to open the history sets.

Using hold_actions in entities or button cards saves space and makes this a smooth solution.

I think it’s possible to discard the python_script and to generate the urls with javascript templates in the config-template-card, but not for me. :slight_smile:

I never liked and used the old history with all entities, IMO a big mess.
Like i said in my first post, i used the history config to include a few important entities.

I see…How about something like this then?

type: custom:config-template-card
variables:
  link_url: >
    group => { return "/history?entity_id=" + 
    states[group].attributes.entity_id.toString().replace(/,/g,"%2c"); }
entities:
  - group.outdoor_devices
  - group.upstairs_bathroom_lights
card:
  type: entities
  entities:
    - type: weblink
      name: Outdoor Devices History
      url: ${ link_url("group.outdoor_devices") }

    - type: weblink
      name: Upstairs Bathroom Lights History
      url: ${ link_url("group.upstairs_bathroom_lights") }

    - entity: sensor.memory_use_percent
      hold_action:
        action: navigate
        navigation_path: ${ link_url("group.upstairs_bathroom_lights") }

(Note: for this example, I’m using real entities from my HA instance, and I only have a couple groups defined at the moment, but hopefully it should give you an idea if this approach would work for you or not)

1 Like

Very nice, thanks a lot! :+1:

Now the only thing that’s missing are the timestamps in the url to open the sets with different time frames.

&start_date=2022-07-12T18%3A00%3A00.000Z&end_date=2022-07-13T21%3A00%3A00.000Z

Do you know how to generate them in jayascript?
Say now - 24h?

Time is a pain (just generally in any coding language, but especially Javascript)…but let me see if I can work it out. I think 2022.6 accepts the timestamps so I should at least be able to test these ones out locally.

1 Like

Wasn’t too difficult to get a minimal proof of concept actually.

type: custom:config-template-card
variables:
  link_url: >
    group => { return "/history?entity_id=" + 
    states[group].attributes.entity_id.toString().replace(/,/g,"%2c"); }
  hour_span: |
    hours => { 
      var now_time = new Date(new Date().getTime() + 120000);
      var then_time = new Date(new Date().getTime() - (3600000*hours) );
      return "&start_date=" + then_time.toISOString() + "&end_date=" + now_time.toISOString(); 
    }
entities:
  - group.outdoor_devices
  - sensor.time
card:
  type: entities
  entities:
    - type: weblink
      name: History Time Link Test
      url: ${ "/history?entity_id=group.outdoor_devices" + hour_span(24) }

Notes:

  1. I’m omitting the link_url function call in this example since I can’t easily test multiple entities in 2022.6, but you should be able to substitute that back in for the manual string I’m using.

  2. You should be able to adjust “hour_span(24)” to use any number of hours (or partial hours, e.g. 0.5 for a half hour in the past). You could also do things like (24 * 7) to get a week, or (24 * 7 * 3) for three weeks history.

  3. I’m including a time sensor in the group of entities Config Template Card watches for updates, because otherwise the javascript template won’t be updated if the page is open for a period of time and no other entities have updated (which means that when clicking link, the resulting History page could provide an incorrect time span). There’s probably other ways to handle this, but it was the easiest path to success for me.

  4. You might notice that the now_time variable is actually two minute in the future - that’s to account for some possible clock skew between browser and the HA server, as well as being certain to include the most recent events that might have occurred between when the time sensor changed and the link is clicked. Setting future end dates is allowed by the History page (it seems they always round up to the hour when loading a fresh history in 2022.6 in fact).

Amazing! :heart_eyes:
Works like a charm!
Here is the code from my first post with the additions of gonzotek.

type: custom:config-template-card
variables:
  link_url: >
    group => { return "/history?entity_id=" + 
    states[group].attributes.entity_id.toString().replace(/,/g,"%2c"); }
  hour_span: |
    hours => { 
      var now_time = new Date(new Date().getTime() + 120000);
      var then_time = new Date(new Date().getTime() - (3600000*hours) );
      return "&start_date=" + then_time.toISOString() + "&end_date=" + now_time.toISOString(); 
    }
entities:
  - group.history_switches
  - group.history_test
  - sensor.time
card:
  type: entities
  entities:
    - type: weblink
      name: History Switches
      url: ${ link_url("group.history_switches") + hour_span(24) }
    - type: weblink
      name: History Test
      url: ${ link_url("group.history_test") + hour_span(3) }
    - entity: sensor.memory_use_percent
      hold_action:
        action: navigate
        navigation_path: ${ link_url("group.history_test") + hour_span(24) }

I like the new history now! :rofl:

1 Like

I wish I’d seen this post before attempting my own (less elegant) solution. But, in case it helps anyone else, here’s how I approached the same issue. I’m trying to debug my heating system and regularly want to see what happened to about 20 different sensors - entering them one-by-one every time wasn’t an option. I bookmarked the history page but I’d have to update the time / date ranges each time - frustrating.

So, I created a sensor to display ‘now minus 6 hours’ - the time I wanted the history to start from.
I use include files in my config.yaml, and in my time_date.yaml I created this sensor:

- platform: template
  sensors:

# History graph now -6 hrs datetime
    history_now_minus_6h:
      value_template: "{{ as_timestamp(now() - timedelta(hours=6)) | timestamp_custom('%Y-%m-%dT%H:%M:%SZ') }}"

This creates a ‘start’ date and time in the right format for the history URL

Then I created a markdown card with a simple link to the history page:

- type: markdown
  content: >-
    [link text](https://nabucasa_url/history?entity_id=entity_1,entity_2,etc&start_date={{
    states('sensor.history_now_minus_6h') }})

If you don’t enter an end date/time into the history URL, it defaults to now - so perfect for looking at the last 6 hours of history.

1 Like