OpenEMS: align maxchargepower configuration (BC)

[iseeberg79]

Removed default value for maxchargepower as it is unkown.

The parameter maxchargepower is not to be required because to control a battery is optional. As it should not be empty if battery control is configured, error handling is required.

Works for UI-based and yaml-based configurations.

Required: set a proper value for maxchargepower to make grid charging available (default was 4200, higher values possible)

[iseeberg79]

@deadrabbit87 @Bockhorn-IT could you do a review?

[Bockhorn-IT]

Sorry, I forgot to remove the default value in the rest template.

Looks good for me and your explanation makes sense.

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• Using {{- if .maxchargepower }} will treat 0 as false, so a configured value of 0 will hit the ErrNotAvailable branch; if 0 is a meaningful value, switch to an explicit nil/empty check (e.g., test for existence in .params or use a sentinel) instead of relying on truthiness.
• The new source: error / error: ErrNotAvailable branch changes behavior when maxchargepower is omitted; confirm this error type is the intended one for UI/yaml validation and consider aligning it with any existing validation pattern used for other optional-but-required-when-feature-enabled parameters.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Using `{{- if .maxchargepower }}` will treat `0` as false, so a configured value of `0` will hit the `ErrNotAvailable` branch; if `0` is a meaningful value, switch to an explicit nil/empty check (e.g., test for existence in `.params` or use a sentinel) instead of relying on truthiness.
- The new `source: error` / `error: ErrNotAvailable` branch changes behavior when `maxchargepower` is omitted; confirm this error type is the intended one for UI/yaml validation and consider aligning it with any existing validation pattern used for other optional-but-required-when-feature-enabled parameters.

---

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]

The parameter maxchargepower is not to be required because to control a battery is optional. As it should not be empty if battery control is configured, error handling is required.

It seems we're inconsistent across templates there, see #25929. Not sure which policy we want but we should honor consistency. When finished, #25932 should also enforce required params for yaml-based config.

[iseeberg79]

Yes, we should. There is as well the sum-of-devices approach different here I am not very happy with.

You directed recently not defaulting to "unknown" values. Let's clarify and fix.

I tried to be consistent with latest Plenticore changes here. I am personally not very happy not to use default values here. I think the default values are making things easier.

Required is not true because of a "cascade" of parameters.

Actually this change would be okay. Having default values I'd like to prefer.

[andig]

@iseeberg79 can't we simply require this value? #25932 will raise any errors from missing value.

[iseeberg79]

Thanks for re-opening

no, not in this case as the template should work without battery (ess0) provided and requires no chargepower in this case.

We could of course require a battery device but this is a breaking change and is inconsistent from my point of view because of the summarized value approach.

What about to redesign the template, require the devices instead of using summarized values? Then maxchargepower should be initially a required value and evcc shows any producer or battery defined.

Personally I'd like to go for the changes this PR introduces.

[andig]

We could of course require a battery device but this is a breaking change and is inconsistent from my point of view because of the summarized value approach.

If should only be required for usage battery of course

[iseeberg79]

Of course, but still remains