Proposal: New EVCS Api

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

PR #2047 puts a new nature (located in io.openems.edge.evcs.v2) beside the old evcs nature. This community post can be used to make suggestions, comments and changes to PR #2047. They are very welcome!
The OpenEMS association invites to a Hackathon on February, the 23/24th. It is about EVCSs in general.
I would appreciate it, if we can find a common understanding of a new EVCS interface until that date.

Some forks of OpenEMS include EVCS drivers. When the new interface is defined this EVCS drivers will be merged back into the official OpenEMS repository.

Here are some additional information or discussion points:

EvcsPower objects:
At present controller logic is unnessecary complex to control charge parks with OpenEMS.
Therefore we like to introduce an EvcsPower Objects (analog to EssPower but not as singleton).
In reality a charge park can consist out of multiple electrical cabinets and each cabinet
has its own limitations. Having an EvcsPower object per cabinet makes life much easier.
The consolinno guys and we are working on a cluster/controller which is responsible for a single cabinet and which can be used recursively. Thus it will be really easy to build very complex charge parks.

Sometimes discussion came up to add the Meter interface to an EVCS (and takeout meter relevant channels from the EVCS nature). It has advantages and disadvantes. The PR does not handle this topic. Probably a good time to talk about this yet. I am curious about your opinion on that.

Bidirectional Charging:
Still an open point. Interface change does not take care on bidirectional charging.
As we may have a bidirational charge point during the hackathon it may be good to
add basic nature for that as well.

Backward Compatibility:
This is a major version step. Introducing Power objects and several other changes will not be backward compatible.

When installing a lot of charge points it is good practice to rotate the electrical phases.
Some companies might have a mobile fleet with vehicles with 2-phase charger only. With rotated electrical phases on the EVCS the problem with phase shifting loads is reduced drastically.
Might be good for a controller to now the phase rotation.

Priority (rw):
Each EVCS should have a priority. There may be controllers using the priority of the EVCS and there may be controllers overwriting the priority of an EVCS.

Background to some CHANNELs:

By default CHARGE_POWER is positive. We might talk about how to use this with bidirectional charging stations.

ManagedEvcs:SET_DISPLAY_TEXT (in v2 removed):
Within OpenEMS no public code is using it. Most chargepoints are not able to do it.

ManagedEvcs:SET_ENERGY_LIMIT (in v2 removed):
This makes driver more complex than nessecary. Should either be
a utility function, or a controller function, maybe a stackable controller.

Unclear, really difficult to understand. Understanding it is a huge time waste. Also unneeded with PowerObjects.

ManagedEvcs:CHARGE_MODE (in v2 removed):
Driver should not be responsible for that.

Please feel free to add comments here or directly to the Pull Request.