Loadpoint: adapt UI for integrated and switch devices

[andig]

fixes #30897
see docs evcc-io/docs#1091

Integrated devices (e.g. a heat pump on a switch socket) reused the regular charger UI, which exposed controls that do not apply to them. This adapts the loadpoint UI to the charger feature flags that the backend already publishes.

• hide the charged energy value for integrated devices (no charging session) We swap with metrics data once stable (energy today, ...).
• drop the Min+Solar mode for switch devices (no current control)
• hide the charging current settings max current setting in loadpoint settings for switch devices. min current and phases are still required to calculate min power (pv mode)
• extend the heating Playwright test to cover the above
• drop min/max current block (charger type) from config ui loadpoint modal (see settings)
• introduce Current control: no label to indicate this behavior in config ui

Screenshots

Config UI: switch device > no current control

Config UI: drop min/max current, charger type section

Main UI: no minpv mode for switch devices

Loadpoint Settings: drop max current

👮 Note: Dropping max current setting will force minCurrent to stay under 16A (maxCurrent default, removed from UI). Still changeable via API.

TODO

• check if this really helpful or in conflict with the mini loadpoint approach

Out of scope

• Consider replacing minCurrent (+ phases?) by something like minPower. @andig

[sourcery-ai]

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

• Mode.vue now expects a switchDevice prop, but the diff doesn’t show it being passed from the parent (e.g. Loadpoint.vue), so please ensure this prop is wired through wherever <Mode> is used or the new Min+Solar logic will never activate.
• The Playwright assertion modal.getByText("Charging Current") is tightly coupled to the English label; consider using a data-testid (as done elsewhere) to make the test resilient to localization changes.
• The code now uses integratedDevice, switchDevice, and chargerFeatureSwitchDevice; it may be worth aligning the naming (or adding brief comments) to clearly distinguish these concepts and reduce confusion for future changes.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Mode.vue now expects a `switchDevice` prop, but the diff doesn’t show it being passed from the parent (e.g. Loadpoint.vue), so please ensure this prop is wired through wherever `<Mode>` is used or the new Min+Solar logic will never activate.
- The Playwright assertion `modal.getByText("Charging Current")` is tightly coupled to the English label; consider using a data-testid (as done elsewhere) to make the test resilient to localization changes.
- The code now uses `integratedDevice`, `switchDevice`, and `chargerFeatureSwitchDevice`; it may be worth aligning the naming (or adding brief comments) to clearly distinguish these concepts and reduce confusion for future changes.

## Individual Comments

### Comment 1
<location path="tests/heating.spec.ts" line_range="46-48" />
<code_context>
+  test("no current settings in loadpoint settings", async ({ page }) => {
+    const lp = page.getByTestId("loadpoint").first();
+    await lp.getByTestId("loadpoint-settings-button").last().click();
+    const modal = page.getByTestId("loadpoint-settings-modal").first();
+    await expectModalVisible(modal);
+    await expect(modal.getByText("Charging Current")).toHaveCount(0);
+  });
+});
</code_context>
<issue_to_address>
**suggestion (testing):** Use a more stable selector than plain text for the Charging Current setting.

Using `getByText("Charging Current")` ties the test to copy and localization. Prefer targeting this control via a test ID or a stable role/name (e.g., the form field’s accessible label) and assert that that specific control is absent for switch devices, so the test stays behavior-focused and less flaky.

Suggested implementation:

```typescript
  test("no current settings in loadpoint settings", async ({ page }) => {
    const lp = page.getByTestId("loadpoint").first();
    await lp.getByTestId("loadpoint-settings-button").last().click();
    const modal = page.getByTestId("loadpoint-settings-modal").first();
    await expectModalVisible(modal);

    // switch device has no current control in settings
    await expect(
      modal.getByTestId("loadpoint-settings-current-control"),
    ).toHaveCount(0);
  });

});

```

To fully implement this change you will also need to:
1. Add a stable test id to the “Charging Current” control in the loadpoint settings UI, for example:
   - `data-testid="loadpoint-settings-current-control"` on the form field wrapper (or the primary input element).
2. Ensure this `data-testid` is only rendered for devices that support configurable charging current so the test remains behavior-focused.
</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.}

[andig]

@naltatis this is pretty extensive- not sure you want to take a look? Feel free to close.

[naltatis]

This indeed mixes some topics from the heating epic, the mode redesign and the mini loadpoints (consumer) concept. I'll go through this and see if we can extract some quick wins as individual PRs.

[andig]

Fine if not, just need to update the issue then.

[RenatusRo]

Please hold your horses on this one:
> drop the Min+Solar mode for switch devices (no current control)

Reason:
This limits the available behaviour options of the control loop and how the energy budget is assigned to the LPs.
A fast LP draws its current from grid, while minPV will first try to satisfy its demand from PV (and supplement from grid, if not enough PV)

see
#20625

[andig]

The only thing minPV does is keep the switch active if there's no current control. It doesn't do anything for demand afaikt.

[florian240483]

Please hold your horses on this one: > drop the Min+Solar mode for switch devices (no current control)

Reason: This limits the available behaviour options of the control loop and how the energy budget is assigned to the LPs. A fast LP draws its current from grid, while minPV will first try to satisfy its demand from PV (and supplement from grid, if not enough PV)

see #20625

For switch-devices (simple on/off devices), there is no difference between fast-mode or min+pv?! In fact, the min+pv behavior does not exist, because the device can only be switched on or off.

[naltatis]

Updated the implementation and PR description. Added screenshots.

[naltatis]

A fast LP draws its current from grid, while minPV will first try to satisfy its demand from PV (and supplement from grid, if not enough PV)

The only thing minPV does is keep the switch active if there's no current control. It doesn't do anything for demand afaikt.

@RenatusRo I was not able to verify this. For switch devices fast mode should give you the same behavior as minpv does.

[RenatusRo]

A fast LP draws its current from grid, while minPV will first try to satisfy its demand from PV (and supplement from grid, if not enough PV)

The only thing minPV does is keep the switch active if there's no current control. It doesn't do anything for demand afaikt.

@RenatusRo I was not able to verify this. For switch devices fast mode should give you the same behavior as minpv does.

yes, neither was me - it looks like my mental model diverged from reality :-(
There was some real life subtlety when operating multiple LPs + planner which forced me to operate switch sockets with minPV instead of Now - but i couldn't reproduce it today.
So, I rest my case.

[VolkerK62]

For switch devices fast mode should give you the same behavior as minpv does.

What about battery hold? Is active in fast mode, but not in minpv.

[andig]

Thats more a coincidence than a feature…

[florian240483]

I have a question about this implementation: i thought the calculation of min power (for pv mode) is done via "standbypower = -2000" for instance?
Why is then the min. current setting necessary?

The disadvantage of this approach is, that i had to configure the dedicated energy meter, to measure the actual power.

[andig]

i thought the calculation of min power (for pv mode) is done via "standbypower = -2000" for instance?

No.

Why is then the min. current setting necessary?

Min Current is a property of the IEC protocol- depending on phases this means min power.

[florian240483]

But thats how it is described in the documentation: https://docs.evcc.io/de/smartswitches/
Or am I just misunderstanding the docs?

[naltatis]

@florian240483 I extended the docs to make the different jobs of standby and mincurrent more clear evcc-io/docs#1091

[andig]

@naltatis good to merge?

[naltatis]

yes

[CiNcH83]

I like the changes a lot! My heat pump feels less like a car charger now.

[florian240483]

One more thought: for switchdevices, the "Fast" mode would probably be better described as "On"—or is that part of the more extensive overhaul of the mini-loadpoints?

[naltatis]

One more thought: for switchdevices, the "Fast" mode would probably be better described as "On"—or is that part of the more extensive overhaul of the mini-loadpoints?

Yes, a rename is coming. Solar mode is also awkward for users with only a home battery.

[romkeller]

Is there a way to make the minPV (minimum solar charging) option reappear via a configuration entry if it has disappeared? I built a custom automation for this since my wallbox is not supported by evcc.

[andig]

Why would it disappear for a wallbox in the first place?

[romkeller]

With my wallbox itself, it is not possible to control the current regulation via evcc. However, the wallbox has its own 'min solar' mode, which I have been calling up via a Home Assistant automation as soon as I select the menu item in evcc. Therefore my question: is there a possibility to display this menu item again?