If 250 is default, you should of course set anything larger than default if you want to increase the height.
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
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
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.
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?
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 ?
Line is always there with active tooltip with tooltip: showColorsTimeline: false and always hidden with active tooltip and tooltip: showColorsTimeline: true
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.
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:
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 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.