[Under New Management] Interactive history explorer custom card

I tried this… but this doesn’t change anything (sorry my YAML skills are no that good :slight_smile:

  - type: line
    lineMode: lines
    timeTickDensity: high
    lineGraphHeight: 100
    decimation: accurate
    options:
      ymin: 0
      ymax: 100
    showTimeLabels: true
    entities:
      - entity: sensor.algemeen_current_flow_temp
      - entity: sensor.algemeen_flow_setpoint_value
      - entity: sensor.algemeen_return_temperature_ch

If 250 is default, you should of course set anything larger than default if you want to increase the height. :wink:

For timeTickDensitythis only adjusts in some screensize cases, so not a 1:1 setting. If it is not fitting to your needs, I don’t know any other settings. Of forgot them.

For decimation you should switch off if you want to see all data. accurate is still decimating.

Both lineGraphHeight and timeTickDensity need to go under the root key, not under individual graphs, or they won’t do anything. decimation can be used per graph, but that’s an advanced usage. Adding it to the root would be the better option in your case. accurate should keep the spikes when you zoom out.

Example:

type: custom:history-explorer-card
lineGraphHeight: 400
timeTickDensity: high
decimation: accurate
lineMode: stepped

Note that by default, timeTickDensity is already high.

Edit: if you want the exact same non-smoothed look of the graph as the native one, you need to disable curve interpolation too. I’ve edited the example YAML above. It’s all described here, with little example images and all :slight_smile:

Thanks a lot! I think i’m almost there… only thing i get not working is the vertical timelines… would be nice if this is per 15 min instead of 1 hour…

The code i’m using now is:

type: custom:history-explorer-card
cardName: historycard-23388208
combineSameUnits: true
labelsVisible: true
labelAreaWidth: 250
timeTickDensity: medium
decimation: accurate
lineGraphHeight: 300
lineMode: stepped
uiLayout:
  invertZoom: true
stateColors:
  binary_sensor.algemeen_flame_status.on: green
  binary_sensor.algemeen_flame_status.off: red
  binary_sensor.algemeen_heating_request.on: green
  binary_sensor.algemeen_heating_request.off: red
  binary_sensor.algemeen_heating_request_ch.on: green
  binary_sensor.algemeen_heating_request_ch.off: red
  binary_sensor.algemeen_pompen_vloerverwarming_status.on: green
  binary_sensor.algemeen_pompen_vloerverwarming_status.off: red
  binary_sensor.kelder_k_2_vloerverwarming_status.on: green
  binary_sensor.kelder_k_2_vloerverwarming_status.off: red
  binary_sensor.woonkeuken_0_3_vloerverwarming_status.on: green
  binary_sensor.woonkeuken_0_3_vloerverwarming_status.off: red
  binary_sensor.woonkamer_0_2_vloerverwarming_status.on: green
  binary_sensor.woonkamer_0_2_vloerverwarming_status.off: red
tooltip:
  showDuration: true
defaultTimeRange: 4h
header: Centrale Verwarming
graphs:
  - type: timeline
    options: null
    showTimeLabels: true
    entities:
      - entity: binary_sensor.algemeen_heating_request
      - entity: binary_sensor.algemeen_pompen_vloerverwarming_status
      - entity: binary_sensor.algemeen_heating_request_ch
      - entity: binary_sensor.algemeen_flame_status
  - type: timeline
    options: null
    showTimeLabels: true
    entities:
      - entity: binary_sensor.kelder_k_2_vloerverwarming_status
      - entity: binary_sensor.woonkeuken_0_3_vloerverwarming_status
      - entity: binary_sensor.woonkamer_0_2_vloerverwarming_status
  - type: line
    options:
      ymin: 0
      ymax: 100
    showTimeLabels: true
    entities:
      - entity: sensor.algemeen_current_flow_temp
      - entity: sensor.algemeen_flow_setpoint_value
      - entity: sensor.algemeen_return_temperature_ch
  - type: line
    options:
      interval: minutes
      ymin: 18
      ymax: 26
    showTimeLabels: true
    entities:
      - entity: sensor.temperatuur_ruimte_taster_k2
      - entity: sensor.temperatuur_ruimte_taster_woonkeuken_0_3
      - entity: sensor.temperatuur_ruimte_voorkant_woonkamer_0_2
  - type: line
    options:
      interval: minutes
      ymin: 0
      ymax: 100
    showTimeLabels: true
    entities:
      - entity: sensor.klepsturing_kelder
      - entity: sensor.klepsturing_woonkeuken
      - entity: sensor.klepsturing_woonkamer
  - type: line
    options:
      interval: minutes
      ymin: 0
      ymax: 100
    showTimeLabels: true
    entities:
      - entity: sensor.algemeen_modulatie_status_ketel

Huh. Well to be honest with you, this spacing is on purpose. I didn’t realize that people actually want this very high tick density like on the native graphs. I always thought it to be highly undesirable, as it clutters up the graph, so for me the current high setting is about as much I can possibly tolerate :yum:

I guess I can add a veryhigh density setting.

Hahaha the reason why I would like it by 15 minutes is because this way you can easily see with different charts below each other if the timing is the same. :). Of course you can also see this if you hover your mouse over it but that is less obvious to me.

just noticed this:

I am not entirely sure why it shows that starting time, but if thats correct, it should display ‘for 24 hours’ or something like that?

That’s how the HA recorder component works, unfortunately. It will generate a ‘virtual’ start time that coincides with the start time of the request, instead of the ‘real’ last event, if that last event was prior to the requested time frame. It’s the same for the native HA history. Just scroll left a little, so the card loads in the earlier data, and the start time will adjust.

It certainly should ! That’s a bug. I could reproduce this. Should be easy to fix.

Not, what you noticed, but I’m happy, that I’m not the only one with the not hidden horizontal line. And the most left vertical one. Or at least someone confirmed it now outside by setup.

This is macos and not ios or ipad os as in my cases, isnt it?

Yes it’s macOS desktop browser window ( so not the macOS app)

Do you have the line glitch in more info line chart cases as well? Until now, I was the only one reported it. But as this was the case for the glitch above as well, and you have it as well, it would be interisting, if you have this second one as well. Wow. A lot of as wells.

I’m speaking about the set line color, which gets lost if scrolling to future or on every day break if scrolling in the past.

Interesting. Since I have access to a Mac (not an iOS device), I should be able to reproduce this. I never noticed this before in my tests though. Do you also get all the blinking artifacts described in this github issue here ?

Nope, everything looks normal for me on Mac. Weird.

mac hec test

And with tooltip too

mac hec test tooltip

Did you check with

Line is always there with active tooltip with tooltip: showColorsTimeline: false and always hidden with active tooltip and tooltip: showColorsTimeline: true

don’t think so no.

What I do see is that when changing the time period, the graphs almost greys out, and I have to hover or sometimes select it multiple times to get it to show correctly again

Yes, that is, what I have and mean as well. Can you do me a favor and take another entity with more data (not only fpr 2 hours or so), so something like a temperature, leave it on 1 day show period and then move 50% to the future and see if it is happening as well. And secondly move slowly back to some day breaks.

This here


But this is not the topic from above for bar chart (the reference github issue is containing two glitch-cases).

For bar chart is the horizontal line and the left line

image

are they appearing and disappearing when you are moving or activating and deactivating the tooltip via hover/click?

Dec-25-2022 11-57-41

in Christmas theme…

hard to see, but I do believe there’s a tiny intensity decrease on the vertical line in front of the graph now and then. Hardly an issue probably I would think, but, yes it is there:

Dec-25-2022 12-01-07

@HeyImAlex this might be a FR, and I am not sure it would ever go, but here it is…

Id somehow love to be able to do

    uiLayout:
#       toolbar: hide
#       selector: hide

based on a frontend boolean:

    uiLayout: 
       toolbar: >
          [[[ return states['input_boolean.hide_history_explorer_toolbar'].state; ]]]
       selector: >
          [[[ return states['input_boolean.hide_history_explorer_selector'].state; ]]]

because every now and then I want to switch between the regular more-info and the HE-more-info. For that, we need to reach the dropdown on the selector, and since I have that disabled normally for the more-info, I now need to edit my yaml twice.
Would be way more user friendly if we could toggle the boolean to enable/disable the selector, turn on/off the history more-info setting and toggle boolean again.

Maybe we can already do that in another way, and if so, I am sorry for not seeing that yet… if not, would you p[lease consider this as a FR?

The issue (not big) is, that the lines are displayed, not that they are not displayed. They should not and should be hidden by code. But you have the same as I, webkit is displaying them most of the time and in your example hide them correctly only on some hover tooltips.

I think all these rendering anomalies on Mac probably all have the same underlying problem. They just manifest slightly differently based on some other external factors. If the underlying issue is fixed (something about alpha/opacity not being correctly taking into account), then this will most likely fix all these issues. The problem is reproducing this. That thing just doesn’t manifest itself when I use it on a Mac :confused: I’ll do some more test when I get the chance.

Super specific. And the problem is that it contains Jinja. Keep in mind that this card runs on your browser, it’s not a HA integration. Your browser doesn’t know how to evaluate templates and doesn’t have access to all that. There might be some undocumented way to ask HA to evaluate a template over the API, but I haven’t found (nor really looked for) something like this. Feel free to open a FR on github, but it will mostly likely not be very high priority I’m afraid.