Every Energy Management System (EMS) has its own unique strengths and weaknesses. At OpenEMS, our mission goes beyond developing a powerful open-source EMS—we aim to provide the best possible integration with other EMS ecosystems. In the spirit of open source, we believe in building bridges, not silos.
When it comes to integrating multiple EMS behind a single meter, there are generally three different approaches, each serving different use cases:
1. Read-Only Integration
In this setup, multiple EMS run in parallel, simply reading data from each other without taking over control. This is often the easiest and most robust integration method, allowing systems to co-exist and benefit from shared data.
Examples include:
- OpenEMS Edge provides local Modbus/TCP and JSON/REST interfaces.
- HomeAssistant can read from OpenEMS Edge via ha_openems.
- EVCC can read from OpenEMS Edge (PR #2673).
- OpenEMS Edge can read data from EVCC (WIP PR #3119).
2. Full Control Override
Here, one EMS becomes the central controller, while the other acts as a command receiver. This setup is ideal when one system needs to enforce central control logic.
Examples include:
- OpenEMS Edge offers local Modbus/TCP and JSON/REST interfaces that also support set-points (e.g., for battery charge/discharge). Note: These control interfaces may require a separate license in some OpenEMS distributions like FEMS.
- An OpenEMS “Master” Edge can override a “Slave” Edge via the Edge-to-Edge interface:
Edge-to-Edge on GitHub - This approach is used with many FENECON Industrial energy storage systems, e.g. together energy traders
3. Logical Integration
This hybrid approach combines the strengths of both EMS. It allows systems to work together intelligently while complying with regulatory requirements - like “Is it allowed to charge the battery from grid?”
A prime example:
- Balancing Schedule Controller: A higher-level EMS sends a schedule to OpenEMS Edge for managing the grid connection point. OpenEMS then handles the real-time control with high responsiveness. Documentation: Balancing Schedule Controller
- WIP: we (FENECON) are working on extending the Balancing-Controller to accept a “Grid Set-Point” - to be released soon…
This kind of logical integration is particularly useful when combining cloud-based EMS with local EMS, allowing for secure, cyber-resilient operation while leveraging the advantages of both layers.
Proposal: Advanced Integration with Clever-PV
As part of this ongoing effort, we propose an enhancement to the integration with clever-PV. This would allow control override of OpenEMS Edge via the clever-PV Push API.
- The idea: The HTTP response from the Push API should include control commands (e.g., battery set-points).
- The goal: A generic and future-proof communication structure that can support other cloud EMS and evolving control command formats.
Key resources:
General
- Method:
POST - Content-Type:
application/json - Authentication: Device-specific API key (via endpoint URL)
- Rate Limit: 180 requests per minute (OpenEMS default is 15 seconds)
- Success Response: HTTP
202 Accepted
Request (default clever-PV Push API)
{
"watt": -1000,
"producingWatt": 1500,
"soc": 75,
"chargingPower": 500,
"powerStorageState": 1,
}
Alternatively we propose a JSON object that uses OpenEMS Channel-Addresses, similar to CurrentData in OpenEMS UI.
{
"currentData": {
"_sum/GridActivePower": -1000,
"_sum/ProductionActivePower": 1500,
"_sum/EssSoc": 75,
"_sum/EssDcDischargePower": -500,
}
}
Use-Case 1: NO_DISCHARGE
As in the OpenEMS “ESS Time-of-Use Tariff”-Controller there should be a command that stops discharging a energy storage system. Loads are supplied either by PV or from grid. Charging is still allowed.
Example:
- If stored energy in battery is not sufficient to supply loads, stop discharging during cheap hours (FEMS App Time-of-Use Tariff :: FENECON Dokumente)
- Do not charge an electric vehicle from the battery in certain situations ([FEMS] Auto per Wallbox nicht aus Speicher laden)
Extended Request
- Add extendable “availableControlModes” | “ess” which holds a list of available control modes for Energy Storage Systems.
NO_DISCHARGEis only available if no “ESS Time-of-Use Tariff”-Controller is activated (i.e. not installed or configured withMode.OFF- Mode “NO_DISCHARGE” has no additional parameters, but for other modes this JSON object could hold limits like max charge/discharge power.
{
"...",
"availableControlModes": {
"ess": [{
"mode": "NO_DISCHARGE",
}]
}
}
When activated:
{
"...",
"activeControlModes": {
"ess": {
"mode": "NO_DISCHARGE",
}
}
}
Response
To Activate:
{
"activateControlModes": {
"ess": {
"mode": "NO_DISCHARGE",
}
}
}
To Deactivate:
{
"activateControlModes": {
"ess": null
}
}
- Empty Response does not deactivate the Mode
- Response has to be updated once every 60 seconds, otherwise it gets deactivated (“Watchdog”)
Use-Case 2: LIMIT_CHARGE
As in the OpenEMS “ESS Grid Optimized Charge”-Controller there should be a command that limits the (DC-side) charging power of an energy storage system. Surplus PV is fed to grid. Discharging is still allowed.
Example:
Extended Request
{
"...",
"availableControlModes": {
"ess": [{
"mode": "LIMIT_CHARGE",
}]
}
}
Response
To Activate:
{
"activateControlModes": {
"ess": {
"mode": "LIMIT_CHARGE",
"maxChargePower": 1000, // [Watt]
}
}
}
To Deactivate:
{
"activateControlModes": {
"ess": null
}
}
We look forward to feedback from the OpenEMS community and to continued collaboration with developers and EMS vendors across the ecosystem.
Please add your comments; I’ll try to incorporate the feedback above.
Let’s make energy systems more open—and smarter—together.
Changelog
- 02.06.2025 Use
"mode"as key withinavailable/activateControlModes. Add proposal forCurrentDatathat aligns with OpenEMS standards.
.