evcc-io
OpenEMS: align maxchargepower configuration (BC)
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)
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 https://github.com/evcc-io/evcc/pull/25929. Not sure which policy we want but we should honor consistency. When finished, https://github.com/evcc-io/evcc/pull/25932 should also enforce required params for yaml-based config.
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.
@iseeberg79 can't we simply require this value? https://github.com/evcc-io/evcc/pull/25932 will raise any errors from missing value.
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.
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