Verify that there are no statistics in history then. Keep in mind, that your band-aide to remove the state class may be causing the issue as well. It depends on when customize is loaded in relation to the entity.
I have some amount of entities with intentionally set “state_class: none”.
In all cases I see no graphs on statistical graphs.
There is a test view in my setup: auto-entities + grid + statistics graph for all entities with explicitly set “state-class: none”. This view is used to check an absence of LTS.
After each time I set “state_class: none” there was a corresponding issue in Dev tools - Statistics. The issue proposed to delete old LTS. It was working fine.
I have some doubts regarding this particular problem with Repairs.
On the video I posted there are several repairs for statistics issues - which I fixed weeks ago.
But in fact there is one more possibly related issue: in 2024.5 a Traccar Server integration was changed by its author: battery_level data were exposed as sensors instead of being an attribute of a device_tracker. And these “battery” sensors were with “state_class: measurement”. Since I did not need LTS for these sensors, I set “state_class: none” via customize. It happened on May. Then I fixed corresponding statistics issues in Dev tools, it seems to not causing problems.
But since May anyway these statistics issues were shown 2-3 times for each “battery” sensor! Of course these issues were fixed same way “delete old LTS” - although that mentioned view still displayed “no stats available”. So, the problem here - WTH these statistics issues appeared again although I first fixed them on May?
So, the last time I seen these issues in Dev tools was about at the beginning of September.
Probably there is something wrong with Traccar Server integration and this can affect Repairs too.
I really like the new header-card but the size of it (font, icon) is a bit small compared to the older cards.
I would just like to enlarge everything by 120%
This is a custom mini graph card with a built-in entities card below it.
Note how the graph shows the correct unit, but the entities card (1) seems to convert it to seconds and (2) includes no unit for the first two sensors. The third has its unit though, and it really seems no different.
There is inconsistency with showing device_class duration in Frontend.
So, it is more general issue, not related to Ping integration.
As for “why these data became sensors” - it was my original issue caused a corr. PR: these durations occupied lot of place in DB, every update of a ping entity caused a new record in attributes table.
So what’s the difference between that and with every update causing a new entry in the state table?
I’m pretty sure the reasoning is that there is a conscious architectural decision to move away from attributes where the value can be better represented as an entity. No idea what the guidelines are but some values will stay as attributes.
Before: every update caused 1 new record in “states” and 1 new record in “state_attributes”.
After: every update caused only 1 new record in “states”.
At least this was an initial idea, have not checked DB yet.
As for a real reason: ofc there is a general trend, but this particular PR was added after that issue as following that trend.
Yes, it’s a general issue with how durations are handled in some cases, but it’s not completely isolated to the frontend, as the linked frontend issue to the link I posted explains too. The problem is that nobody has a really good suggestion at the moment.
It’s just now more glaring with the changes made to the ping integration, where you don’t want any variation on HMS formats, but just want a decimal value (int or float).
I think there were cases where some sensors would update way more frequently than the attributes, leading to a lot of duplicate attribute entries (imagine there being 10 attributes, but only 1 changes at a time), but there were also cases where static attributes have been removed. In this case though, all these values update together everytime, so I’d agree that there’s probably no saving here.
I’m glad to hear there are plans to move away from attributes. Hanging lots of them off an entity probably seems like a great idea until you look at how they’re stored in the database. Basically, that creates a lot of unnecessary duplication of data. And no good way to exclude the unwanted data. Here’s a recent example of how that affects the database.
Ok, I really only had a quick glance on that issue; hope it will be fixed at least on the ping integration’s level - and then we will keep testing how these duration are displayed.
If a state was changed 10 times and attributes were not - then each record in a “states” table contains same value of “attributes_id” (pointing to the last record in the “attributes” table).
As for ping bibary_sensor: for every update a new “states” record and a new “attributes” record was created. Since I did not need these “duration” attributes - I suggested to change this behavior.
Now, if a user does not use “durations” - the changed implementation will save a lot of space in DB; if a user does need these “durations” (and thus enables these sensors) - then may be even more space in DB will be used as it was before…
The action is null when z2m sends the device update. After the update to 2024.10.1 the mqtt integration now sets the action to unknown as soon as it receives the null value in the above message. So this can happen at random times.
I am using Home assistant Core with docker. Is it safe to upgrade now with the 10.1 release? I saw somtehing like this: After adding /srv/homeassistant/bin to path in the SystemD service file HA core 2024.10 runs as expected. How to add that?
