if you open the device page, you should see the entites - but they might be deactivated
Thanks!
@tom_l also assisted and pointed out itâs now under the diagnostics section (this wasnât intuitive for me).
So after the update I was faced with 136 issues because of statistics data. That in itself is great, I like having the peace of mind that once those repairs are gone, the data consistency is ensured.
However, to get rid of these repairs, oh my godâŚ
95% of these are coming from the unifi network integration, more specifically from this commit, where they changed the data rate of a network client from Mb to MB/s.
From what I gathered, they indeed changed the measurements from tansfered megabytes, to megabits per second. Also Iâm (today at least) not really interested in that data, so I can choose the easy way out and select âDelete all old statistic data for this entityâ
But having to go through that list of 136 entities, clicking each one, selecting that option and clicking âFix issueâ is very, very, very cumbersomeâŚ
The Dev tools > Statistics page has a multiselect, when I saw that I almost rejoiced, but unfortunately tthat doesnât allow you to fix the issue across all sensors 
Edit: On top of that, on the âRepairsâ page these repairs seem to take long to disappear (possibly because the SQL queries to remove the old data take their time?), so after fixing some entities, I loose track of where I was and notice Iâm fixing issues which I already fixed beforeâŚ
The Dev tools > Statistics page doesnât seem to suffer from that last issue, once I click âFix issueâ there, the issue is gone from the list.
In my case they kept displaying more than an hour and gone after HA reboot.
Not to mention that corr. statistic issues were fixed in Dev tools several weeks ago and appeared as Repairs after update to 2024.10
Yep, they only disappear when the next statistics get rolled up. Typically once an hour.
For the multi-select, I believe you could have used spook to handle it with 1 service call via a script, however it requires templating.
Yes, as said above, they appear when the statistics calculation executes, which is once an hour. That calculation is what produces the repair because itâs looking at existing statistics while running the calculation.
Iâve also had an issue. I have a Tradfri shortcut button e1812 using an automation from blueprint by EPMatt. Iâve set up z2m actions for short, long and double press and only the long press action still works. All of a sudden they fail one or both conditions.
I see some legacy syntax errors, but these arenât supposed to be breaking yet. Even if I correct these in the blueprint and remake the automation I get either the same result or the other condition fails.
One short press of the button sends action=âonâ, then action=NULL, then action=ââ, almost all simultaneously. Payloads for long and double press are different for the first action, but the sequence is the same, except long press also sends a release sequence. None of this should have changed with the HA release, though, so somehow itâs being handled differently.
But these repairs appeared after a few HA reboots (on the 3rd run may be, and each run was more than an hour) after updating to 2024.10.
I.e. not after the 1st hour after updating to 2024.10.
And as I said - this statistics issues were fixed several weeks ago - why Repairs include them?
These statistics repairs were shown within several hours, then I rebooted and then they gone.
Anyway, is it normal that a âfixedâ (and probably âsubmittedâ) repair still shown for some time after a user fixed it?
I think youâre miss understanding that when HA boots up, it has 0 repairs. Then it creates the repairs when it finds them. Doesnât matter what repairs you had before you restarted, during boot up, it starts from 0.
Probably I am misunderstanding since I do not see how your last post explains everything.
- Approx 01.09 some statistics issues were shown in Dev tools - Statistics and I fixed them (deleted old LTS). Then these issues were not shown.
- Approx 01.10 a new 2024.10 version was installed.
- After a few reboots where each run was more than an hour - new Repairs came for those old statistics issue. These issues were not shown in Dev tools.
- I opened each repair, pressed âdeleteâ - but repairs were kept shown for a few hours. Then I rebooted, repairs gone.
You start the system.
It has 0 repairs.
When statistics runs sometime later, could be an hour, could be 2 hours, you get a repair (if thereâs something to repair).
You restart.
The system boots up.
It has 0 repairs.
When statistics runs sometime later, could be an hour, could be 2 hours, you get a repair (if thereâs something to repair).
etc
Well, the sequence you described is clear, thanks, but nothing changed in my setup within these runs - those entities were still without state_class, I saw no issues in Dev tools -Statistivs, and these repairs seem to appeared from nowhere. And why it did not disappear after I submitted them - a question as well.
Clicking submit should delete the LTS data, if it does not, you can attempt to fix it from the statistics table in developer tools â statistics tab.
Let me remind that there were no issues in Dev tools - Statistics since they were fixed a month ago.
If thereâs no state_class, then there is a problem in the data if LST exists for it. Thatâs what the repair is telling you.
You can verify this yourself by looking at the history for the entity in question. Go to the history tab, expand the date range to 10 years or so. If you have data thatâs beyond recorder, the error is telling you that âYou had statistics before, now you do not because state_class is missingâ.
The error then goes on to tell you, âIf you did not create the entity, you should create an issue with the integration thatâs creating the enittyâ.
Repairs told me same as a corresponding statistics issue, nothing more, and of course I fixed all these issues and deleted statistics which happened a month ago - but anyway Repairs decided to remind me about these already fixed issues.
Post the repair please.
Petro, unfortunately I have not save a screenshot, but here I posted a video.
It quickly shows a text, sorry, have no better version.
The 3rd case, the integration set state_class intentionally, then I set it to ânoneâ via customize, then I was proposed to delete LTS, and I did it.