proposal version for a new EVCS API (v2)

[opernikus-common]

The current EVCS nature is not suitable for larger chargeparks. It includes unnessecary or unclear information (e.g. MaxPower, MaxHwPower, FixedMaxPower ) and it is missing important information (e.g. PhaseRotation, PowerObject, Constraints).

This pull request opens a proposal for a change on the EVCS nature. It puts a new version of the evcs api (io.openems.edge.evcs.v2.api) beside the old implementation. It should not be merged into the development branch. It should be taken as a reference for a discussion on a future EVCS nature.

Therefore we also like to introduce multiple EvcsPower objects (analog to EssPower), each responsible for a single electrical cabinet (done in another PR). It makes it a lot easier to limit Currents on a given power line segment and build controller hierarchies.

For more a discussion on this topic see commmunity post Proposal: New EVCS Api

[sebastianasen]

First of all, I appreciate the collaboration between you guys and the outputs.

I have still a few open points:

• I know it is a little bit confusing, that there are multiple information about maximum and minimum evcs Power (MaxPower, MaxHwPower, FixedMaxPower) as you mentioned. This was made like this, because we wanted to have an easy way to show the current possible settings understandable and stable to the customer in the UI.

Surely, for charge parks it is not as important as for normal households, but the Nature should be prepared for both, isn't it. It would be great if the UI part has still the possibility, to show the customer the possible minimum and maximum for his charger (depending also on the phases used). If i have only a dynamic maximum, calculated by the EvcsPower, the Inputs for the user are confusing and not stable (e.g. User Input 10 kW, dynamic maximum 7 kW. Same for the Minimum)

Internally the Power constraints will anyway act in this ranges and could limit the charging station but still have this limits present and as initial constraints set.

Maybe it would be clearer if the channels would be named different. (Open for suggestions) MaximumHardwarePower (Let's say UiMaximumLimit): The AbstractManagedEvcsComponent or Evcs.addCalculatePowerLimitListeners(this); calculating this value by just setting the real hardware limits e.g. KEBA Dip-Switch Settings [FixedMaximumHardwarePower] and the current phases separately. FixedMaximumHardwarePower: Set (normally) once, mentioned before MaximumPower: Defined during run time (e.g. Car is charging less than requested) - This could be also the output of the EvcsPower maximum In this approach, a new evcs must only set the FixedMaximumHardwarePower and the phases.

• Detailed Phase information Please feel free to add the channels already in the current evcs api if that gets us ahead. I agree with the PhaseRotation as an important information and the current values as well. Even the three Enum values are fine, it could make sense to add the other three possibilities like the "invert" config in a normal meter, if the installer is doing wrong things.

• Priority is not used in the Evcs Nature for now (I assume this the plan) It could be done like this, but I would suggest having more Priority Level 5 to 10 (To be not limited in future) - Internally it could be mapped to Low, Medium, High.

Furthermore, I will try to push the Alpitronic charging station as soon as possible.

[opernikus-common]

@sebastianasen, I am well aware of the solar optimized charge widget. It is very impressive feature of OpenEMS and personally I like it very much. We need to take care that this will work with the new nature!

I removed the Channels nevertheless, because

1. the XXMin/MaxPower channel name always confuses developers and one need to dive deep into the widget to understand the meaning
2. curently in my opinion this Channels are controller specific and they have nothing to do with the EVCS.

Also I am not lucky with the Widget reconfiguring the EVCSs current (Zoe option). A new driver developer does not know that and that sometimes broke a productive system of us (when a ZOE is charged for the first time).

Unfortunately right now, I do not have a solution for the solar optimized charge feature, but before we switch to the new API we should take care that the API includes all relevant Channels.

So we may add your suggestions to the EVCS. But without having looked at the widget closely, I would prefer to put the Channels into the ControllerEvcs. Maybe we can have a talk about this, when we know a little more about the EvcsPower object.

[github-actions[bot]]

This PR has been automatically marked as stale due to inactivity. It will be closed in 7 days if no further activity occurs.

[github-actions[bot]]

This PR has been closed due to inactivity

It was automatically closed because there has been no recent activity. If the PR is still relevant, please feel free to reopen and update it and add any new information.