Optimizer: enable by default

[andig]

Add ability to enable optimizer via UI.

• enable "experimental"
• enable "Optimizer 🧪" (Integrations)

Screenshots

Todos

• add opt-in ui toggle @naltatis
• add documentation, see docs: add optimizer docs#1025
• use optimizer.evcc.io deployment, see chore: azure deployment optimizer#65
• update privacy policy (data processing) @naltatis Add optimizer privacy evcc.io#50

Future
Add more status info like last update, server fails, ... to the optimizer tile.

[sourcery-ai]

Hey - I've left some high level feedback:

• The new OPTIMIZER_URI constant is exported and all-caps; consider using an unexported, Go-style optimizerURI (or similar) unless it’s intentionally part of the public API.
• Since the optimizer is now always enabled with a default URL, consider whether the on/off behavior should be controlled explicitly (e.g., by a config flag) rather than implicitly via the environment variable.
• You might want to read and cache the optimizer base URI once (e.g., at site initialization) instead of calling os.Getenv on every optimizerUpdate to avoid repeated environment lookups in a potentially hot path.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The new `OPTIMIZER_URI` constant is exported and all-caps; consider using an unexported, Go-style `optimizerURI` (or similar) unless it’s intentionally part of the public API.
- Since the optimizer is now always enabled with a default URL, consider whether the on/off behavior should be controlled explicitly (e.g., by a config flag) rather than implicitly via the environment variable.
- You might want to read and cache the optimizer base URI once (e.g., at site initialization) instead of calling `os.Getenv` on every `optimizerUpdate` to avoid repeated environment lookups in a potentially hot path.

---

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]

We should do this as an opt-in, since we're transmitting usage data here. I'd introduce a dedicated optimizer toggle in the experimental dialog and also add a documentation page explaining the optimizer concept, its goals and its current state.

[CiNcH83]

I wonder if "cloud-based" is the right terminology. At least not for people who run their local instance.

[naltatis]

I wonder if "cloud-based" is the right terminology. At least not for people who run their local instance.

Good point. Updated the text to be more concrete and use "external service" terminology. (updated screenshot)

[sourcery-ai]

Hey - I've found 1 issue, and left some high level feedback:

• The OPTIMIZER_URI constant in core/site_optimizer.go is exported but only used internally; consider making it unexported and following Go naming conventions (e.g. optimizerURI) to avoid polluting the public API surface.
• You now have three helpers around optimizer/experimental state (optimizerEnabled, isOptimizer, isExperimental); consider consolidating them or reusing optimizerEnabled where appropriate to avoid diverging logic between CLI and runtime behavior.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- The `OPTIMIZER_URI` constant in `core/site_optimizer.go` is exported but only used internally; consider making it unexported and following Go naming conventions (e.g. `optimizerURI`) to avoid polluting the public API surface.
- You now have three helpers around optimizer/experimental state (`optimizerEnabled`, `isOptimizer`, `isExperimental`); consider consolidating them or reusing `optimizerEnabled` where appropriate to avoid diverging logic between CLI and runtime behavior.

## Individual Comments

### Comment 1
<location path="assets/js/components/Config/OptimizerModal.vue" line_range="56-65" />
<code_context>
+		},
+	},
+	methods: {
+		async change(e: Event) {
+			try {
+				this.error = null;
+				await api.post(`config/optimizer/${(e.target as HTMLInputElement).checked}`);
+				} catch (err) {
+				const e = err as AxiosError<{ error: string }>;
+				this.error = e.response?.data?.error || e.message;
+			}
</code_context>
<issue_to_address>
**suggestion:** Avoid reusing the name `e` for both the event parameter and the error object in `change`.

Inside `change`, `e` is used both as the `Event` parameter and then redefined in the `catch` block. Even though the scopes don’t conflict, this hurts readability and can cause confusion during future changes. Consider using clearer names, e.g. `event` for the parameter and `error`/`axiosError` in the `catch` block.

```suggestion
	methods: {
		async change(event: Event) {
			try {
				this.error = null;
				await api.post(`config/optimizer/${(event.target as HTMLInputElement).checked}`);
			} catch (err) {
				const axiosError = err as AxiosError<{ error: string }>;
				this.error = axiosError.response?.data?.error || axiosError.message;
			}
		},
```
</issue_to_address>

---

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