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

**URL:** <https://community.openems.io/t/proposal-ems-integration-behind-a-meter-towards-seamless-collaboration-clever-pv/10115>\
**Category:** Uncategorized\
**Created:** [May 26, 2025, 3:59pm UTC](https://community.openems.io/t/proposal-ems-integration-behind-a-meter-towards-seamless-collaboration-clever-pv/10115 "2025-05-26T15:59:33Z")\
**Posts on this page:** 1\
**Showing post:** 6

<div class="post-metadata">

**Author:** ![stefan.feilmeier](https://community.openems.io/user_avatar/community.openems.io/stefan.feilmeier/32/2585_2.png) [@stefan.feilmeier](https://community.openems.io/u/stefan.feilmeier)\
**Post date:** [June 2, 2025, 9:21am UTC](https://community.openems.io/t/proposal-ems-integration-behind-a-meter-towards-seamless-collaboration-clever-pv/10115/6 "2025-06-02T09:21:56Z")

</div>

@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 · GitHub](https://github.com/Lamarqe/ha_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](https://community.openems.io/t/04-04-networking-friday-on-energy-scheduler-v2-genetic-algorithms/7079/2)

> [@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:

- [https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.evse.api/src/io/openems/edge/evse/api/chargepoint/Mode.java#L19-L22](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.evse.api/src/io/openems/edge/evse/api/chargepoint/Mode.java#L19-L22)
- [openems/io.openems.edge.controller.evse/src/io/openems/edge/controller/evse/single/Config.java at develop · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.controller.evse/src/io/openems/edge/controller/evse/single/Config.java)  
With that in mind, maybe the `activeControlModes` should indeed directly link to a Controller or Component, e.g.

```auto
{
   "...",
   "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.

---

_[View the full topic](https://community.openems.io/t/proposal-ems-integration-behind-a-meter-towards-seamless-collaboration-clever-pv/10115)._