Optimizer: derive per-device action suggestions from result

[andig]

Replaces reverted #30783, builds on #31383

Converts the optimizer schedule into a per-device advisory action for the current slot, published on the battery device and as a dedicated loadpoint key. Because the optimization is linear, the first slot sits at an operating-range extreme, so it maps cleanly onto the discrete action that control would later apply. Advisory only, control is intentionally not wired up yet.

💡 new optimizer icon (magic suggest bulb)
🔋 Battery page (🧪): each battery card shows its suggestion; with a single battery, suggestion and soc forecast share the optimizer tile
🚗 Vehicle status: optimizer icon (charge/pause variant) with explanatory tooltip, shown only when the suggestion differs from the current charging state
💡 Suggestion actions: home battery normal|hold|charge|holdcharge, loadpoint/vehicle charge|stop; idle battery interpreted from grid flow (importing → hold, exporting → holdcharge)
🧹 Suggestions are replaced on every optimizer run, cleared (null) for disconnected loadpoints and on optimizer errors
📡 Published state structure. Power values are published but not shown (device support required first)

battery.devices[i].suggestion: { "action": "hold", "charge": 0, "discharge": 0 }  
loadpoints/{id}/suggestion:    { "action": "charge", "charge": 11000, "discharge": 0 }

Wording

action	EN	DE
charge	Charge from grid	Aus dem Netz laden
hold	Prevent discharging	Entladen verhindern
holdcharge	Prevent charging	Laden verhindern
normal	Normal operation	Normaler Betrieb

Screenshots

battery view: one battery, dedicated optimizer box

batterie view: multiple batteries, suggestions per device, forecast combined

loadpoint charge advice

loadpoint pause advice

[sourcery-ai]

Hey - I've left some high level feedback:

• The suggestionThreshold constant is a magic number in currentSlotSuggestion; consider either naming it to convey why 50 W is appropriate (e.g. reference to measurement noise / optimizer resolution) or adding a brief comment explaining how it was chosen so future changes don’t accidentally invalidate the assumption.
• For non-battery types, currentSlotSuggestion always returns "stop" when charge <= suggestionThreshold regardless of discharge power or grid direction; if discharge or grid flow should influence EV/loadpoint recommendations, it may be worth revisiting this logic or documenting that this simplification is intentional.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `suggestionThreshold` constant is a magic number in `currentSlotSuggestion`; consider either naming it to convey why 50 W is appropriate (e.g. reference to measurement noise / optimizer resolution) or adding a brief comment explaining how it was chosen so future changes don’t accidentally invalidate the assumption.
- For non-battery types, `currentSlotSuggestion` always returns `"stop"` when `charge <= suggestionThreshold` regardless of discharge power or grid direction; if discharge or grid flow should influence EV/loadpoint recommendations, it may be worth revisiting this logic or documenting that this simplification is intentional.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[naltatis]

@copilot resolve the merge conflicts in this pull request

[Copilot]

@copilot resolve the merge conflicts in this pull request

Resolved by merging origin/master into this branch and fixing the conflict in core/site_optimizer_test.go. Included in commit 014accd.

[naltatis]

Created UI for battery and loadpoints. Updated publishing structure. See description and screenshots above,.

[Johannes-del]

Following this with interest. It looks like the direction that would replace a workaround I'm running.

I have a Vaillant aroTHERM heat pump modelled as a heating loadpoint (SoC = DHW
tank temperature), PV-only + dynamic tariff + smartCostLimit, no EV. Two behaviours
I currently emulate with a small external script that just flips the loadpoint's
limitSoc via the API:

1. source-dependent target: store to 60 °C only from PV surplus, cap grid/smartCost
   heating at 50 °C (the last 10 K are the worst COP band, and on grid they're pure
   loss vs. feed-in);
2. forecast gate: don't grid-charge in the morning if the solar forecast says PV
   will cover the tank for free later today.

Both are exactly what a price+forecast optimizer should decide on its own, so I'd
rather drop the script.

Will the per-slot suggestions (and later the wired-up control) extend to heating/thermal loadpoints, where "SoC" is a tank temperature and the store is thermal rather than a battery/EV? Or is the initial scope battery + EV only? Happy to test on a real thermal + PV + dynamic-tariff system if that's useful.

[naltatis]

ready to merge

[andig]

NICE!