Quite often I am finding that my sensors and history stats have stopped updating, Usually a reboot fixes this. It is causing my history stats to become eratic and unreliable.
In this example I am trying to track how long each zone in my house calls for heat. So I have a dry contact relay attached the boiler controller and HA monitors the contacts as a binary sensor and then History stats keeps track of that sensor for 30 days. However it often “messes” up throwing off my entire stats for that month.
You can see in the Pic the History stat went nuts and even reported 15 decimal places when its only ever reported 2 in the past.
I have tried migrating over to MariaDB thinking it was a sqlite issue but the issue is still happening.
Is there a “best practice” setup for history stats or even MariaDB or is it just unstable HA??
I am running HA Core 0.116 On Pi4 running on a 120GB solid state drive.
I am not really 100% sure where to start troubleshooting this.
30 days could be a lot of samples. However you still seem to be using the default setting of only 20. You are probably not getting a month’s worth. If you look in the developer tools states menu at the attributes of the sensor you can see the sample count. If this is 20 you need to change the default value a lot higher.
In my case, the sensor gets randomly stuck in a daily basis. I can’t see any possible cause, at least yet. So no clue what is happening. But something is definitely wrong.
I believe that I ended up moving off from the built in DB and over to MariaDB I don’t believe that I have had a problem since. I can’t remember for sure. I’ll find out when we get back into heating season here and I start paying more attention to it again.
I am getting similar behaviour with a similar application - monitoring the demand for heat from various of the rooms in my house, along with the total runtime of the boiler. Clearly, the runtime for the boiler will always be at least as long as the demand time for any individual room, but that’s not always the case with my history stats sensors.
Today, for example, the total runtime is currently 1.73 hours, and the demand time for my office is 2.2 hours. That can’t happen.
I happen to have some Python code that pulls data from the history database and calculates these numbers after the fact, both for today and for days past. Right now it says the total runtime is 1.725 hours - close enough to the 1.75 in the history stats sensor - but for the office it says the total time is 1.73 hours. Again, that’s still wrong, but probably due to rounding errors. It is close enough to the total runtime, and in fact, the office is indeed likely to be the only room in the house needing heating so far today (that’ll change this evening).
So the data in the history database seems to be correct, and it is just the calculation of the history stats values that’s wrong.
Here’s the definition of one of my history stats sensors:
For me, it is a minor irritation. I can always calculate the correct values externally, and those are what I will use for long-term comparisons. But if there’s a simple bug in here somewhere, it would be nice to get it fixed. I don’t know anything about the innards of home assistant to know where to start looking, unfortunately.
Hey Steve, I believe it is possible to to have a Thermostat call time be longer than the actual boiler run time.
The way my boiler works anyways is anytime a thermostat calls for heat the boiler will fire up to its operating temp, once the operating temp is achieved it will turn off until enough heat energy is removed from the water due to the zone converting it to hot air at the radiator, once the water temp drops it will run again. Meaning the zone could be calling for heat for multiple boiler cycles which would result in the house thermostat having a higher total runtime than the boiler itself.
This is all assuming you have a hydronic heating system with a oil fired boiler based on how you call it a boiler and mention a radiator.
I have my binary sensor hooked directly to a dry contact relay that is triggered only when the actual pump on the burner is running. I figured that would give me the most accurate runtime stats.
I did wonder about that possibility, but the fact that the on/off states of the thermostat and radiators add up to what I’d expect suggests that’s not what’s happening. It looks to me like the rolling sum that’s calculated by the history stats sensor is just not quite right. It could be rounding errors. In the example I gave, the office radiator is often only demanding heat for a few minutes at a time, but several times throughout the day, and maybe a minute here and there adds up? Not sure that accounts for the 25 minute discrepancy I quoted, though.