Reset of values after outage fix #91
Conversation
added detection for anomalous data and drops the reading if they are larger than is sensible Set to use the following Circuit-specific thresholds (but they are changeable) self._max_energy_jump_wh = 20000 - defaults at 20 kWh max jump between readings since a 60amp circuit can't pull more than 15 kwh, and I can't think of a residential setup where there would be more than that even on an EV charger self._max_energy_rate_w = 50000 # 50 kW max power rate feels very generous to avoid false positives I think? In theory i focused this at the circuit level only, so I don't THINK it will have any knock-on effects to the solar and grid readings, which are quite higher.
This reverts commit b90ef99.
crafted a backstop to keep sensors from going `unavailable` every time the panel updates or restarts, causing HA to calculate energy deltas from 0 to current, instead of previous to current as desired.
|
had to step out as soon as I opened this, but when I get home I'll take a look at any CI issues and try to address them ASAP tonight. |
|
having no end of a headache with some of the CI stuff. Just when I get it passing locally, I get new issues on GH that I didn't have locally. Going to take another stab at this tomorrow to get it passing. |
|
Yes sorry I haven't forgotten you. I'm on the verge of a major refactoring to add this baseline for these math-aware sensors and your request will be in it. I will pull your changes this week so no worries. Cheers |
|
sounds good!
…On Tue, Jul 15, 2025 at 08:49 Bill Flood ***@***.***> wrote:
*cayossarian* left a comment (SpanPanel/span#91)
<#91 (comment)>
Yes sorry I haven't forgotten you. I'm on the verge of a major refactoring
to add this baseline for these math-aware sensors and your request will be
in it. I will pull your changes this week so no worries.
Cheers
—
Reply to this email directly, view it on GitHub
<#91 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAALDF7IDHDYDZBWR6ZSCWD3IUPJHAVCNFSM6AAAAACBQR5SEKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZUGIZDEOBTGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Just to add a little color my thinking is that we use the synthetic sensor definition, which I have already integrated to store the previous state of the sensor in an attribute of the sensor and then test the current state against that previous state with another variable (potentially a SensorSet global or two for power vs energy thresholds). We can expose these thresholds in the options and then when the sensor evaluates its state it can do something meaningful like log the spike, toss it, etc. I'll look at what you've done algorithmically and incorporate those concepts and we can iterate on how best to proceed. Since your panel is working with your fork can no one else is complaining I feel like we have a bit of time to get this right. See the discussion here for some background on the bigger picture. |
|
I'm working on this now with the ha-synthetic-sensor now looking much better and integrated into my 1.2.0 branch. It was just a massive effort with > 1500 tests. I'll put the grace period in the options. I assume your fix has solve the problem for you and the approach is a go... |
|
I'm working on this now that the ha-synthetic-sensors is working well. It was just a massive effort (>1500 tests) so hopefully will get 1.2.0 out later this week or early next. It will be fun to see what we can do with it. I'll put the grace period in the options. Assume the general approach is working for you. That was great digging! |
|
This doc describes the approach. |
Sorry I thought I had opened this for a PR weeks ago! It's been working fine on my system, but I defer to your judgement @cayossarian if you are satisfied with my changes or not before merging them in. Would love to get this into a release, sooner than later, if possible.