Site: drop stale battery grid charge limit without a dynamic tariff

[andig]

Fixes #29961

Problem

A user switched from a dynamic electricity tariff to a static one and could no longer remove the battery grid-charge price cap — it stayed visible with no way to clear it.

Root cause

Three settings depend on a dynamic tariff but are persisted and restored unconditionally at boot, while their UI editors are gated on smartCostAvailable / smartFeedInPriorityAvailable (= a dynamic tariff). After switching to a static tariff the editor — and its remove control — is hidden, leaving a stale limit that the user cannot clear:

Setting	Requires
batteryGridChargeLimit (site)	dynamic planner tariff
smartCostLimit (loadpoint)	dynamic planner tariff
smartFeedInPriorityLimit (loadpoint)	dynamic feed-in tariff

Beyond the UI, a stale batteryGridChargeLimit / smartCostLimit can still actively drive grid/loadpoint charging against a configured fixed price.

Fix

In the site's settings restore, once tariff availability is known:

• only reapply the persisted batteryGridChargeLimit when the planner tariff is dynamic, otherwise clear the stale value;
• clear stale loadpoint smartCostLimit / smartFeedInPriorityLimit when the respective tariff is not dynamic.

The loadpoint restore runs before the loadpoint has any tariff context, so the loadpoint limits are reconciled from the site.

Verification

• go build ./core/..., go vet ./core/, go test ./core/, gofmt — all clean.

🤖 Generated with Claude Code

[sourcery-ai]

Hey - I've left some high level feedback:

• When clearing a stale BatteryGridChargeLimit, consider handling the error returned by settings.SetString so that a failure to clear the persisted value doesn’t silently leave an inconsistent state.
• Instead of SetString(keys.BatteryGridChargeLimit, ""), consider using a dedicated delete/clear method (if available) so the storage semantics reflect that the limit is absent rather than an empty string.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- When clearing a stale `BatteryGridChargeLimit`, consider handling the error returned by `settings.SetString` so that a failure to clear the persisted value doesn’t silently leave an inconsistent state.
- Instead of `SetString(keys.BatteryGridChargeLimit, "")`, consider using a dedicated delete/clear method (if available) so the storage semantics reflect that the limit is absent rather than an empty string.

---

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.}

[andig]

@naltatis fixed two more occurrences of this kind- anything else you have in mind?

[naltatis]

We already had a solution for this in place. We show a warning dialog with the option to remove the existing limit when we detect that there is an unusable limit. This can either by because the battery is not controllable any more or your tariffs have changed. The battery grid charge path was broken. See fix here: #30013

I'd prefer the manual way (UI) over the auto-cleanup way. Doing this on boot has the potential of deleting limits as an effect of a temporary tariff initialization error or reconfiguration for tariffs by the user (remove > add).