I have run into a situation caused by HA restart. Nothing is broken here, just looking for a solution for a self induced anomaly.
I have an automation that restarts HA at 2 AM every night. This came about due to a problem I was having with TPLink devices dropping offline overnight. I found they all came back online after an HA restart, hence the automation to perform a nightly restart of HA.
The issue I am having now is due to a little climate science project in which I have created a number of sensors that i am observing in a ‘test’ version of my Lovelace dashboard. One of the sensors involves computing a mathematical ratio of two other sensors. When the graph is generated from this sensor there is a spike in the graph that is hundreds of units greater than the usual range. This occurs at the HA reset every night. This spike results in the y-axis range being so large that the rest of the graph is pretty much unusable. I have added an action to the HA restart automation to disable the recorder just before the restart.
My question is whether or not the recorder will be reenabled when HA comes back online or if it will remain in the state it was in when the restart was initiated.
I have, for the time being, created another automation to restart the recorder at 2:05 AM just to avoid missing too many events being recorded. I would like to avoid having to guess when HA has restarted and just be sure the recorder will restart without my intervention.
Surely it would be easier to fix your sensors so that the spike doesn’t occur
I suppose I could range restrict each and every sensor in my system. That seems like a lot more work than just getting an opinion on whether or not the recorder will restart or not on HA restart.
Yes maybe not easier but best practice.
My original supposition that this was happening on HA restart turns out to not be true. Further observation shows that while this does happen in the middle of the night it is not happening on restart. I am currently running a test to determine is this is a divide by zero problem. Yes, divide by zero, should not happen. The graphic representation of the sensor shows a value ‘near zero’ unfortunately the graph will not show the exact value at that point. Extracting the value will probably require getting into database inquiries.
Update:
The undesirable spike in the sensor in question appears to be transitory in nature no doubt caused by the occasional unreliability of the sensor data at the root of data used in the at question sensor. There did not appear, to me, to be any way to deal with this outside of filtering/limiting the resultant sensor data as suggested by SgtBatten. This is working and while the transitory spikes still occur, limiting their excursion brings the y-axis extents into a reasonable range making the normal data useful.
One thought I had about the cause of the spikes was a divide-by-zero error. I designed a test to prove it disprove this with another sensor. While I found that testing this test sensor template in the ‘Designer Tools/Template’ page, dividing by zero produced an error message, implementing the test sensor on a Lovelace entities card did not produce any error response. The effect in the database recording was that the sensor data remained at the previous value prior to the divide by zero event.
In the end the desired result is now available and this is closed.