Proposal: EMS Integration Behind a Meter: Towards Seamless Collaboration (clever-PV)

[stefan.feilmeier]

@benzman81:

@benzman81

Case1)
I always do the latter manually via the emergency power reserve. I would prefer to have these settings in the UI, of course, otherwise I would have to create an extra header in a third-party system just for this.
Why the until condition? I don’t want to load my car from the energy storage and would like to set the setting via API or UI in the fire and forget style. That way you don’t forget to reset, which has often happened to me with the emergency power reserve.

You can maybe use the OpenEMS add-on for Home-Assistant, to automate this: GitHub - Lamarqe/ha_openems: Home Assistant Integration for Fenecon FEMS and OpenEMS

I don’t want to load my car from the energy storage

In general I don’t agree with this statement, because very often it is very feasible to do that. Of course there needs to be a stop condition then. (e.g. “Charge 10 kWh till 7am in the morning”). We are working on such features in the “Energy Scheduler v2” project.

---

@c.lehne:

@c.lehne

It could also be used to enable convenience features, like e.g. connecting your calendar with your electrical car, without affecting the security of the local EMS installation. I really like the idea of working with control modes and limitations, rather than working with specific power setpoints.

Thanks for that use-case. Yes, indeed a lot of current developments are towards “schedule management”, where a schedule is always a list of “control modes” per time-period (e.g. 15 minutes slot). So maybe the API should allow/foresee optional time/duration settings already from the beginning.

See discussion and OpenEMS Networking Friday slides here: 04.04. Networking Friday on Energy Scheduler v2 & Genetic Algorithms - #2 by stefan.feilmeier

@c.lehne

With regard to charging stations (or possibly even entire charging parks), control via control modes would also be appropriate.

Really appreciate your experience here. That’s why I already had ess in activeControlModes, to be prepared also for evcs or evse. The Evse.Controller.Single already uses such control modes per chargepoint as you describe:

• openems/io.openems.edge.evse.api/src/io/openems/edge/evse/api/chargepoint/Mode.java at develop · OpenEMS/openems · GitHub
• openems/io.openems.edge.controller.evse/src/io/openems/edge/controller/evse/single/Config.java at develop · OpenEMS/openems · GitHub
  With that in mind, maybe the activeControlModes should indeed directly link to a Controller or Component, e.g.

{
   "...",
   "activeControlModes": {
     "ess0": {
       "mode": "NO_DISCHARGE",
     }
     "ctrlEvseSingle0": {
       "mode": "FORCE",
     }
   }
}

(I’m using ess0 instead of ctrlEssTimeOfUseTariff0 because this should work also without an installed/bought Time-of-Use-Tariff-Controller)

---

@c.lehne

Provide a docker container with a) a simple UI and push API and b) an OpenEMS Edge bundle as reference implementation. This could be a good starting point for energy programming beginners to e.g. control their chargepoint programmatically or disable battery discharge during car charge.

I am not sure yet if/how this will be used as an extension or replacement for the existing local JSON/REST-Api. Current proposal really just targeted Cloud-EMS, but of course this could also make sense towards Home-Assistant, OpenHAB, ioBroker, etc.

---

@JonasGhost:

Thanks for bringing up and explaining Energy Communities. Austria is ahead there, but as this is a European Law, we will see it more widely applied soon.

OpenEMS could play multiple roles in such an environment; with parts handled by OpenEMS Backend and parts handled locally by OpenEMS Edge. I have also seen that clever-PV and other Cloud-EMS providers are actively working on implementing specific solutions for this use-case. On the Edge-side this could than be handled by OpenEMS with the proposed API.