@HeyImAlex,
I love what you have done. Myself, I prefer manual configuration in the overview raw configuration.
One, I like to overlay and set fill: rgba(0,0,0,0.0). Currently, I prefer the type: panel card, as it uses the width of the screen providing more detail. My question… When I attempt to add another cardName I get an error stating “This view contains more than one card, but a panel view can only show 1 card.” Interestingly … If I use the UI and add the other entity, it will display them both but without detailed configuration like removing the fill and overlay. Here is a screen capture:
Any suggestions. Also, is there a link to all available user definable options. I have found some of your configuration options in your github read.me file.
As above. I would propose to use a standard dashboard with a view in panel mode, set a stack card (as the one allowed carD) and you can add how many you want with total width.
Yeah as others have said, the panel view mode only supports a single card. That’s what it was designed to do. If you want multiple cards in there at full width, you can use a vertical stack card inside the panel view and then add the history explorer card(s) to the vertical stack.
You are confusing entities with cards. You don’t need to have multiple cards just to display multiple graphs. Just add them under the graphs section and they will appear one after the other on the same card. Look at the advanced YAML example in the readme.
When the gaps in the data appear, they’re always at the initial view of the presentation, at a state change boundary, and always on the left side. Sometimes when I scroll back far enough in time, the presentation corrects itself. If I scroll back towards the initial view, it will reappear.
In this particular case, the gap is correlated to a server restart.
Yep, this is a limitation of how the database recorder component works in HA. When requesting a limited time range from the database, the initial start value is not always correctly returned (if there has been no state change within the requested range). There’s nothing I can do about this sadly. I have added a way to slightly mitigate this (it would have been much worse if using the raw states directly), but I can’t do more without seriously impacting performance.
The workaround is to scroll further left, so that the next slot ranges are loaded until a state change is found in the database, which will then complete the missing data. Or alternatively, you can temporarily select a larger range (like maybe a week or two) and then zoom back in.
Oh and this isn’t specific to V1.0.20, it’s always been like that. It depends on the data and the frequency of state changes. It will mostly appear on data with low frequency state changes, where a sensor stays in a single state for a long time.
Edit: there is one thing I could do to mitigate this issue a bit more, it’s something that has been on the todo for awhile. It won’t solve the issue entirely (the recorder component would have to be fixed for that), so you would still need to scroll further left or unzoom to make certain long states appear. But I could make it so that they don’t disappear again when you scroll back right once they’re loaded.
Could you you automate the above at the initial view assuming the defaultTimeRange or a fixed time interval? I realize it might slow it down or have limited efficacy. Failing that, is it worthwhile to suggest a PR for the database implementation, or is that a 3rd-party component? I’ve seen databases that record changes of state or value, but perform full updates at fixed intervals to address similar issues.
Unfortunately not. The caching system works on 24 hour slots which are pulled from the DB on demand. The mitigation policy uses backtracking that will search the previous slot for a starting value when the database recorder component didn’t deliver one. If the previous slot isn’t loaded, there’s no data to backtrack into. Preloading doesn’t work either, because it’s impossible to know how far you would have to preload to get to the first stored state change down the history. You’d have to preload the entire history to know where to start - chicken and egg problem. You also can’t just preload a certain entity and not others, the recorder component doesn’t support that.
What I can do is to backtrack iteratively into multiple previous slots, rather than a single one. Which would solve the case where the state disappears again when scrolling back right. But it doesn’t change the fact that these previous slots need to be loaded first.
This is a fundamental issue in the recorded / database implementation of HA, amongst a lot of other fundamental issues it has (although they just fixed a big one in 2022.4). Fixing these kind of issues would pretty much require a complete rewrite of the recorder component, which unfortunately is way out of scope for a visual glitch like this.
I’ve been thinking about implementing a feature that would create a local shadow-copy of the entire database client-side, in a highly compressed and optimized format. That would not only solve the issues @pocket has, it would also make the history blazing fast over all time ranges, as the DB would only have to be queried for occasional syncing and nothing else.
Would be a pretty big project, so depends on if I find the time for it.
This card has a potential. But there is a problem, at least with my configuration. As I understand this card relay on history but you can change how long you wanna keep things in history. In my case this is 8 days. So this card will show history for 8 days. Long term history I keep in maria_db.
So if you wanna show long term history use maria_db, influx and grafana.
Is it possible to configure multiple values for a sensor? For example, a thermostat can take three values - idle, heating, and cooling. I want to define the colors for the three values (orange for heating, blue for cooling, and gray for idle). Basically, I want to replicate the Ecobee chart (see screenshot below)
Note that you can remove the color and the fill settings for the timeline entities, they’re only used for line graphs. Makes the YAML a bit cleaner. The timeline coloring is entirely based on the stateColors definitions.
Okay I just did a test on 2022.4 with my production database, rather than the test DB I have on my dev setup. It looks like this effect is much worse in 2022.4 than it was before the database changes. In fact, from some purely observational tests, it looks like the entire DB performance is worse in 2022.4.
That is not good news. It looks like they broke this even more in 2022.4 than it was before I will have to do more testing. Ugh. Not the way I planned on spending my weekend…
Edit: yup, the database retrieval behavior changed in 2022.4. Now it won’t return the initial state at all anymore, as soon as it is outside of the requested range. The HA native history panel is also affected. It might be an artifact of database migration though, so I will wait a couple of days for new data to accumulate and then test again. If this persists, it’s a bug that will have to be reported for the recorder component.
Just got this card added tonight and am absolutely loving it.
.
I want to create a history graph that shows when my AC is running. That is stored in an attribute, not the state. The entity’s state is what mode it is in, so it just shows ‘auto’ all the time (unless I flip to either ‘heat’ or ‘cool’ or ‘off’). Whether the system is running or not is stored in an ‘hvac_action’ attribute that is either ‘idle’, ‘heating’, or ‘cooling’. I know the attribute I’m after is getting recorded because I can see when the system is running in the stock built-in history graph (though, the ui for that graph is bit ugly).
I suspect the answer is to create a sensor template that sets its state based on the actual entity’s attribute, but thought I would ask if anyone had any better ideas before I did that.
Is there a cleaner way to get history graph of an attribute?
The problem fixed itself with new data being stored in the db using the new table format introduced in 2022.4. It only affected the part of your data that was previously migrated from the old to the new format. Looks like a bug in the migration process, but no big deal as this migrated data will be pushed out progressively as new data comes in.
Yeah pretty much. Just a simple template sensor will do. Adding native support for attributes to the card would very significantly impact the overall performance of the card, even on entities that don’t use attributes. The changes in 2022.4 made this even more clear cut, as there is now an official setting in the API to ignore all attributes for better performance (there already was such a setting previously, but the loss of attributes was merely a sideeffect back then ; now it’s official).
I will have to do more testing. Ugh. Not the way I planned on spending my weekend…