Skip to content

Observe a suggested best_soc_keep from yesterday's real outcome - #4484

Closed
chalfontchubby wants to merge 1 commit into
mainfrom
feat/best-soc-keep-auto-tune
Closed

chalfontchubby wants to merge 1 commit into
mainfrom
feat/best-soc-keep-auto-tune

Conversation

@chalfontchubby

Copy link
Copy Markdown
Collaborator

Summary

  • Adds an opt-in switch.predbat_best_soc_keep_auto_tune that, once a day, compares real import that happened at a worse rate than the export rate available at the same moment (regret) against the real minimum SoC reached yesterday, and publishes a suggested best_soc_keep to sensor.predbat_best_soc_keep_auto_tune.
  • Deliberately observer-only for now - it does not write the suggestion back to best_soc_keep. That's left for a follow-up once the correction logic has been dogfooded against real outcomes.
  • input_number.predbat_best_soc_keep_auto_tune_alpha (default 0.05) controls how much of each day's suggestion feeds into the next, via new = old + alpha * correction.

Test plan

  • New unit tests in apps/predbat/tests/test_best_soc_keep_auto_tune.py: switch off, once-per-day gate, regret (up) correction, margin (down) correction, clamping to [0, soc_max], no-battery-history skip.
  • ./run_all --quick - all passing
  • ./run_pre_commit - clean
  • Dogfooding against real outcomes before a follow-up PR wires up auto-apply

🤖 Generated with Claude Code

…utcome

Adds an opt-in best_soc_keep_auto_tune switch that, once a day, compares real
import at a worse rate than the export rate available at the same moment
against the real minimum SoC reached, and publishes a suggested best_soc_keep
to sensor.predbat_best_soc_keep_auto_tune for comparison. It does not write
the value back yet - that's for a later patch once the correction logic has
been dogfooded against real outcomes.
@springfall2008

Copy link
Copy Markdown
Owner

I guess the question is why, best_soc_keep normally should be 0 unless you specifically want to keep back battery for emergency?

@chalfontchubby

Copy link
Copy Markdown
Collaborator Author

I'm not sure 0 is optimal - there is always some variability around the predicted load - I don't know if you have stuff in place to optimise for that that is ahead of my understanding but my naive thought was if the aim was to hit 0 as the keep, and you turn on a load late in the day, then you end up pulling from the grid to fill the shortfall. If you have keep too high, you are giving up useful capacity.

If there are mechanisms in place to trade off the risk of expensive charge due to variance in the load vs prediction while not leaving export on the table, then this isn't necessary. I just found I was sometimes out of power in the evening without a keep - but maybe not so much as to offset the opportunity cost of a higher keep.

@chalfontchubby

Copy link
Copy Markdown
Collaborator Author

Closed having studied more - apologies.

@chalfontchubby

Copy link
Copy Markdown
Collaborator Author

(I randomly bake sourdough just before the night cheap rate which sometimes screws things up - I've been using keep to hold some charge for that "emergency" - but wanted to size it optimally. I'll check more on the other knobs available.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants