Core concepts & terminology

This chapter describes some of the core concepts and commonly used terms in OpenEMS:

1. OSGi Bundle

OpenEMS Edge is using the OSGi platform to provide a completely modular and dynamic service oriented system.

Logical groups of source code are put into one OSGi Bundle. Every directory in the source code root directory starting with io.openems.*` is a bundle.

More bundle naming conventions are:

  • Bundle names ending with *.common are for common code that is shared by multiple components. Examples are:


    for common code between Edge and Backend, like helper utils, JSON-RPC definitions and Abstract Worker implementations


    for common code within Backend.


    for common code within Edge.


    for common code used by API Controllers

  • Bundle names ending with *.api are for Natures and APIs. Examples are:


    for Controllers


    for Schedulers

  • Bundle names ending with *.core are for shared and helper OSGi services. Examples are:


    for central singleton services:


    handles access to OpenEMS Components and Channels


    is responsible for the process Cycle


    for accessing the host and operating system


    for some Meta information like the version of the running OpenEMS Edge


    for summing the values of the entire energy system, all meters, energy storage systems and so on.


    for the central EssPower service, that distributes power requirements to different energy storage systems

2. OpenEMS Component

OpenEMS Edge is built of Components, i.e. every main component implements the OpenemsComponent interface .

By definition each Component has a unique ID. Those Component-IDs are typically:

  • ess0 for the first storage system or battery inverter

  • ess1 for the second storage system or battery inverter

  • …​

  • meter0 for the first meter in the system

  • …​

If you receive your OpenEMS together with a FENECON energy storage system, you will find the following Component-IDs:


    • ess0: FENECON Pro Ess

    • meter0: Socomec grid meter

    • meter1: FENECON Pro production meter

  • FENECON Mini

    • ess0: FENECON Mini

    • meter0: FENECON Mini grid meter

    • meter1: FENECON Mini production meter

3. Channel

Each OpenemsComponent provides a number of Channels. Each represents a single piece of information. Each Channel implements the Channel interface . By definition each Channel has a unique ID within its parent Component.

4. Nature

Natures extend normal Java interfaces with 'Channels'. If a Component implements a Nature it also needs to provide the required Channels. For example the Energy Storage System (ESS) Simulator Simulator.EssSymmetric.Reacting implements the Ess interface and therefor needs to provide a Soc Channel that provides the current 'State of Charge' of the battery.

Controllers are written against Nature implementations. Example: A Controller can be used with any ESS, because it can be sure that it provides all the data the Controller requires for its algorithm.

5. Channel Address

By combining the unique Component-ID and Channel-ID each Channel in the system can be addressed by a distinct 'Channel Address' in the form Component-ID/Channel-ID.

Example: the state of charge ("Soc") of the first energy storage system ("ess0") has the channel address ess0/Soc.

6. Scheduler

The Scheduler handles the order, in which Controllers are executed. For details see Scheduler and Controller below.

7. Controller

The actual business logic or algorithms are wrapped as 'Controllers'. i.e. they implement the Controller interface . Each Controller holds one specific, encapsulated task.