You were absolutely right. Missed to copy this from standard card as well. Too long ago. Forgot the option.
It is working now, but not yet for the grouping.
Secondly on iOS morinfo at least on my iPhones it is still display not in one line and have a line break between date picker and zoom. Same es Markus wrote somewhere above already. Can live with it, but a little bit less width so both fit in one line, would be good.
Thirdly, on iOS as well. if I scroll some pixels in the future the line disappears on curve graphs. Only the shadow stays. Same sometimes if I go back in the past or if I zoom out. There not always, but sometimes. Perhaps something with unavailable data or whatever else. Did you see such behavior already and someting I can do against it?
Ugh yeah, I think I know what the problem with the white menu backgrounds is. The framework the HA native dialogs use (Lit) has some kind of weird html sanitizing going on, that makes your life extra hard. I’m going to fix this tonight.
@finity, it is still important that you set the dark mode flag correctly. Either the theme has to correctly declare it to HA or you have to manually set uimode in the card(s) YAML. If you don’t, the general colors of the card (labels, time stamps, grid lines, etc) will be off and barely visible. Like in your screenshot.
About iOS, well yeah, there’s really nothing I can do about this I’m afraid, since I do not have an iOS device (nor do I know anyone who has one). It’s 100% Android all around me
Not really. Sometimes if you zoom out a lot or scroll over large amounts of data quickly, the database can’t keep up. It can take a few seconds to show up and sometimes you have to give it a little nudge by scrolling just a bit more, so to initiate a DB refetch. But besides that, sounds like an iOS specific rendering problem. On OSX (Safari) everything works fine.
on custom-ui, we’re struggling with this exact same thing… would you terribly mind if I asked you to see if you can spot what we would need to change there too? Update is what we do now.
Sound awesome.
I still have the toolbars in more-info with 1.0.36. Restarted HA and cleared browser cache.
I still run HA 2022.10 though, since really really I don’t like the stats in more_info.
Is 2022.11 required?
Edit: Tried it my test instance on 2022.11, visible toolbars there also.
Maybe I’m doing it wrong? This is my only config. I select an entity, press +, then Enable history info panel - the page reloads, then change the card config to:
Post your YAML for the card. Also make sure to actually view the history explorer card that contains the config at least once. It needs to be visible to update its config.
I had a quick look at your code. You’re using a very different method to modify the more info panel. You’re basically waiting for a HA expansion tag to open (on any dialog) and then brute force the DOM and see if it’s the attributes on the more info dialog, by walking the DOM with hardcoded elements. That works, but it’s very fragile. It’s basically like webscraping the DOM As soon as the HA frontend guys change the slightest little thing, it’s gonna break. At a quick glance, comparing the 2022.4 and 2022.11 DOM around this area, it looks very similar. But the slightest change will be an issue.
Another possibility is timing. Your code is very time sensitive. You only try to search the DOM twice, during the first 200 msec after the attributes expand. Then the code gives up. If the expansion takes longer, it’s going to fail.
Things you can do (load the code up on the JS debugger):
Put a breakpoint just below updateMoreInfo, on line 47. Open the attributes, see if it hits. If not, they changed the event.
Change the number of retries on line 51 from 2 to some huge value. See if it works now. If it does, it’s a timing issue.
Break on line 53. Open the attributes and step line by line, following your DOM walking. See where it fails. Doing this you’ll eventually hit the problem.
Do improve the code and make it more robust, directly search customElements for a custom tag close to your target, like for example ha-attributes. Then you can remove pretty much all of the DOM scrapping. In a next step, you could also directly hook into the ha-attributes tag, overriding its prototype. Then you could remove the timing based brute forcing. That’s the way the history explorer card does it.
Thanks @HeyImAlex for this amazing extension, great stuff!
I have just two visual issues…
I am using it to show a daily bar chart for 3 of my devices with the biggest power consumption:
The three bars per day show the energy in kWh used by each entity (state_class: total).
At first glance, everything looks good. All values are correctly displayed and the last day shows the energy consumed so far today.
But at the second look, I have two small issues:
The date labels are drawn at midnight, I would expect them to be in the middle of the day.
The last day (today) is cut off since this screenshot was taken at 8am in the morning. This is annoying because I have to scroll to see all three columns. It’s all about the horizontal scroll offset: When the “daily” is selected, I expect the last day to be fully shown (not cut off).
Do you see a change to fix these issues (especially the second)?
No, they’re right where they should be Keep in mind that the bars do not represent a point in time, they represent a time range. In daily mode, and that applies to other intervals too, a bar represents the data from, for example, November 14th at midnight to November 15th at midnight (or actually Nov 14th at 23:59:59.999 to be precise). So showing the bars between two date labels at midnight is the correct thing to do. Note that when you hover over a bar, the tooltip will show you midday. That’s technically a bug, it should show the range instead.
Funny thing is, it used to be like that up to a few months ago, when I changed it because everybody was complaining about it (it does look a little weird with graphs other than bars, as it creates whitespace for future values not yet filled during the current day). I didn’t really mind either way personally, so I changed it to what most people wanted. Can’t please everybody I guess
Can I somehow define a “minimum y-axis interval”? Usecase?
When I look at an entity that has changes +/- 0,4 degrees, it may still look dramatic, since the scale is just 11,4 - 12,4. When I compare that to next temperature entity that has changed 4 degrees, it looks the same at a first glance (but the scale on this one is 5,0 - 10,0). Therefore, I would like to define a minimum interval rather than a specific range. So I guess what I’m looking for is something like this:
temperature:
ymindelta: 5
Maybe one of those lovely edge cases, but anyway.
I love using history-explorer in more-info, but for one specific entity, I would like no graph at all. Is it possible to show nothing at all for a specific entity?
Was this the answer to the white grouping drop down
or that the line disappear when having only some future on the screen
Or to the line break for the control items
BTW (on iOS as well) the additional line is back, which we had in the past already (wen displaying only one entity). Not on every open and, but in 50-60% of the opens. See in the last screenshot as well. Don’t know what the chart is calculation and why it seems that it thinks, that there are two entities andis drwaing one line too much. It’s is not binded behavior to a special entity. It comes on every entity on radnom random open only. Best cases to fix, I know.
No, these things aren’t possible at this time. You can always open an FR on Github. No guarantees though, especially about your point 1, this can be pretty involved to implement (lots of corner cases).
Yeah. The white background in menus is fixed and will be in the next release.
The two others are iOS specific rendering problems. I haven’t seen them on any other browser or OS. It looks like it’s not correctly interpreting the colors used to draw either the graph or the grid lines. For the timeline, the horizontal line was never removed. It was set invisible with an alpha of zero to hide it when showing only a single bar. It seems iOS is ignoring this.
[OT] Developing for Apple hardware is a major PITA tbh. We’re coming across this a lot at work too, Apples’ OpenGL implementation is weird in similar ways. They’re interpreting the standard differently from any other manufacturer on the planet (or they’re right out ignoring it). Special snowflake effect. We need to have separate code paths in our engine, one for Apple and one for everyone else…
As soon as the HA frontend guys change the slightest little thing, it’s gonna break. At a quick glance, comparing the 2022.4 and 2022.11 DOM around this area, it looks very similar. But the slightest change will be an issue.
much appreciated!
