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…
I wanted to see how it performed throughout the passed year. However, we can only select the previous day in the dropdown? I did set it to Monthly in the right dropbox, but that was not very useful.
Please help me out if I missed the correct setting. If I didnt, would this be a valid FR…?
can select 6 months (or zoom out to) and monthly and see this
But I would still like to have an option to switch to increasing in this entities via a boolean switch or another select option in the dropdown. Whatever I set, I can not see what and when something happens exactly (if I need to check it directly). Same as for the changes in HA standard - one of the reasons to have this more than great replacement.
As said, not always, but at least in 50% of the cases. Perhaps a timing problem. Are you applying the alpha to hide asynchronously?
Same as for the other topic (lost of line, but there always, when in the future). Funny thing is, that the line is back, when I select on datapoint. Then it re-appears with the tooltip. To whatever can lead this information.
And THANKS already for the white background in advance.
Regarding this screnshot from my iphone
I think some less somewhere in padding or width would already bring it in one line on (at least tested so in chrome developer tools with iPhone SE). Funny thing is, that I have a 12 and developer tools already shows it in one line, but my phone not.
When I compare to the developer tools screenshot it look s different.
Much more margin/paddings in real live in first screenshot. Whyever.