Preload next grid setpoint before optimization run

[tonvanboven]

Summary

This PR preloads the previously computed grid setpoint into Home Assistant at the start of a new optimization run.

Why

At quarter/hour boundaries there can be a short gap before a new optimization result is written, which can make the setpoint appear to "drop" or not be visibly applied in time. By restoring the precomputed next setpoint immediately at run start, the controller behavior stays continuous.

What changed

• Added a small in-memory + file-backed cache for the next grid setpoint.
• Restored cached setpoint to HA at the beginning of calc_optimum().
• Reused existing battery feed-in entity resolution (entity_set_power_feedin) to avoid introducing new config fields.
• After each run, cached and persisted the next interval setpoint (../data/next_grid_set_point_cache.json).
• Added guarded logging for missing entity/config and cache read/write failures.

Scope

• Intended as a minimal, targeted change.
• Only updates dao/prog/day_ahead.py.

Validation

• Syntax validated with: python3 -m py_compile dao/prog/day_ahead.py
• Deployed and restarted on NixOS using scripts/sync-to-vm.sh for runtime testing.

Notes

• This PR targets the RC branch: 2026.7.0.rc.

[tonvanboven]

Korte NL-samenvatting:\n\nDeze wijziging zorgt ervoor dat de vooraf berekende volgende grid setpoint meteen aan het begin van een nieuwe optimalisatierun teruggezet wordt in Home Assistant. Daardoor voorkom je een zichtbare dip/gat rond de kwartier-/uurgrens voordat de nieuwe run zijn eerste setpoint schrijft.\n\nScope is bewust klein gehouden: alleen dao/prog/day_ahead.py met cache + restore-logica (in-memory en bestand), zonder extra configuratievelden.

[Copilot]

Pull request overview

This PR adds a “next grid setpoint” preload mechanism so Home Assistant can be updated immediately at the start of a new optimization run, reducing visible setpoint gaps at quarter/hour boundaries.

Changes:

• Added an in-memory + JSON file-backed cache for the “next” grid setpoint.
• Restored the cached setpoint to Home Assistant at the beginning of calc_optimum().
• Persisted the next-interval setpoint at the end of each optimization run.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[tonvanboven]

Closing and removing clean variant branch.

[corneel27]

What I don't understand is: why you want to save/restore the "grid_set_point".
More important seems to me:

• the next feedin of the batterie/batteries
• the next amperes of the ev('s)

Can you explain to my why you make this choice?
It this moment I have to much questions and comments to approve this PR.

[corneel27]

I see the comments of Copilot.
I am not glad with the what AI-agents in general produce in this project.
My opinion is: the value of AI-agents is - at the moment - overvalues. They are good in analyzing bugs in software and when I am stuck in a problem they can show me a way for a solution, but they are inadequate in providing an efficient final solution.
They always try to make a tiny problem bigger and they want you to upgrade to a (more expensive) model or plan.

[github-actions]

⚠️ Documentation is out of date

The generated files SETTINGS.md and config_schema.json are out of sync with the current Pydantic models.

Please run the following commands locally and push the updated files:

python scripts/generate_docs.py
git add SETTINGS.md config_schema.json
git commit -m "Update generated documentation"
git push

[tonvanboven]

What I don't understand is: why you want to save/restore the "grid_set_point". More important seems to me:

• the next feedin of the batterie/batteries
• the next amperes of the ev('s)

Can you explain to my why you make this choice? It this moment I have to much questions and comments to approve this PR.

You are right that the key controls are:

• next battery feed-in/dispatch
• next EV charging amperes

After yesterday’s update, this is exactly what the preload now stores and restores for the first interval:

• battery_controls (net power + operating mode + stop datetime)
• ev_controls (ampere, with apply status)

So the implementation is no longer centered on a generic grid setpoint idea; it is focused on continuity of battery and EV control across runs. I also improved the logging yesterday so it clearly shows which battery and EV values were cached/applied.

If helpful, I can still do one final cleanup pass to align naming/comments even more explicitly with battery and EV terminology, but functionally this is already how it works now.