Controller

For the following devices driver implementations are available in OpenEMS Edge.

1. BYD Battery-Box Commercial

Implemented Natures

  • Battery

Source Code

2. Battery FENECON Commercial

Source Code

3. Battery FENECON Home

Source Code

4. Battery Pylontech Powercube M2

  • Implemented Natures

    • Battery

    • OpenemsComponent

    • StartStoppable

Source Code

5. Soltaro Battery Rack

Implemented Natures

  • Battery

Source Code

6. KACO blueplanet gridsave

  • Applies to

    • KACO blueplanet gridsave 50.0 TL3

    • KACO blueplanet gridsave 92.0 TL3

  • Implemented Natures

    • StartStoppable

    • SymmetricBatteryInverter

    • ManagedSymmetricBatteryInverter

Source Code

7. REFUstore 88K

Implemented Natures

  • SymmetricEss

  • ManagedSymmetricEss

Manufacturer Product Page Source Code

8. Sinexcel Battery Inverter

Implemented Natures

  • SymmetricEss

  • ManagedSymmetricEss

Source Code

9. Bosch BPT-S 5 Hybrid

Source Code

10. Core services for OpenEMS Edge

10.1. ComponentManager

A service that provides easy access to OpenEMS-Components and Channels. It also provides some sub-services:

DefaultConfigurationWorker

Applies a default configuration, i.e. activates certain OpenEMS Components that are to be enabled by default on deployment, like Modbus-TCP-Slave Api and JSON/REST Api.

OsgiValidateWorker

Checks if configured Components are actually enabled.

OutOfMemoryHeapDumpWorker

Checks for heap-dump files which get created if OpenEMS Edge crashed because of an OutOfMemory-Error in a previous run.

10.2. Cycle

Provides the core runtime Cycle of OpenEMS Edge

10.3. Host

A service that provides host and operating system specific commands like configuration of TCP/IP network.

10.4. Meta

A service that provides 'OpenemsConstants' as Channels so that they are available via Apis; example: _meta/Version for the current version of OpenEMS Edge.

10.5. Sum

A service that holds summed up information on the power and energy flows, like aggregated production, consumption and energy storage charge/discharge.

10.6. AppManager

A service for managing Apps. It creates, deletes and updates Components, Network configuration and the execute order of the Components in the scheduler.

10.7. App

The predefined Apps for the AppManager.

11. Edge-2-Edge

Enables Edge-to-Edge connection of devices from a slave OpenEMS Edge via Modbus. This requires Controller Api Modbus/TCP Read-Write to be active on the slave system, e.g. via the FEMS App Modbus/TCP Schreibzugriff for a FENECON Energy Storage System.

11.1. Implementations:

  • Edge2Edge.Ess

11.2. Example application

  • Setup a 'Slave' OpenEMS Edge instance, that controls one or more energy storage systems

    • Component-ID of the energy storage system or the ESS-Cluster is ess0

    • Activate Controller Api Modbus/TCP Read-Write and add ess0 to the configured component_ids

At this point you can open OpenEMS UI and check the system profile under settings. Click on the ctrlApiModbusTcp0 component and download the generated Modbus/TCP register table. You should find ess0 listed there. An example Excel file can be found here: https://github.com/OpenEMS/openems/tree/develop/io.openems.edge.controller.api.modbus/doc
This is the setup you will find after purchasing a "FEMS App Modbus/TCP Schreibzugriff" for a FENECON Energy Storage System

  • Setup a 'Master' OpenEMS Edge instance.

    • Configure Bridge Modbus/TCP:

      • id: modbus0

      • ip: IP-Address of the Slave instance

    • Configure Edge-2-Edge ESS:

      • id: ess0

      • remoteAccessMode: AccessMode.READ_WRITE (for default Read-Only access this would be AccessMode.READ_ONLY)

      • remoteComponentId: ess0

      • modbus_id: modbus0

    • Now you are able to access the remote energy storage system as if it was connected locally, e.g. configure a Controller Ess Fix Active Power on ess0 to set a fixed charge or discharge command.

Source Code

12. OpenEMS Energy

Implementations and Services for OpenEMS Energy Schedules.

To understand the functionality and terms used in this implementation, its helpful to refer to the Jenetics manual available at https://jenetics.io/.

13. Terms

Following terms and relations to Jenetics are used:

13.1. Mode

The Mode refers to a predefined operation mode of a OpenEMS Controller. A Mode is represented in Jenetics as a Gene.

13.2. Period

The Period refers to a space in time. A Period holds one Mode per OpenEMS Controller to define its operation mode within this period of time. A Period is represented in Jenetics as an index within a Genotype of Chromosome s.

13.3. Schedule

A Schedule refers to a set of multiple Periods. A Schedule is represented in Jenetics as a Genotype.

13.4. Optimization

A Optimization consists of multiple Schedules that are typically simulated within a 15-minutes period. A Optimization is represented in Jenetics as a Population.

14. Context and their Scopes

Energy Scheduler uses Context objects that hold information that is relevant to a certain Scope of an Optimization run.

OpenEMS Controllers use delegation to EnergyScheduleHandler objects to handle requirements of the Energy Scheduler.

14.1. GlobalOptimizationContext (goc)

The GlobalOptimizationContext - commonly abbreviated as goc - is a Context that is valid throughout an entire Optimization. It’s typically recreated once per 15-minutes.

Example data: - Prediction of Production and Consumption - List of all Energy Schedulers - Global Limits like a limited Grid power - …​

14.2. GlobalScheduleContext (gsc)

The GlobalScheduleContext - commonly abbreviated as gsc - is a Context that is valid for simulation of one Schedule. It’s typically recreated multiple times per second.

Example data: - Initial Energy of an ESS at the start of a Period.

14.3. ControllerOptimizationContext (coc)

The ControllerOptimizationContext - commonly abbreviated as coc - is a Context that is valid throughout an entire Optimization for one Controller/EnergyScheduleHandler. It’s typically recreated once per 15-minutes.

14.4. ControllerScheduleContext (csc)

The ControllerScheduleContext - commonly abbreviated as csc - is a Context that is valid for simulation of one Schedule of one Controller/EnergyScheduleHandler. It’s typically recreated multiple times per second.

Source Code

15. ADS-TEC StoraXe Energy Storage System

For the moment, this is a read-only implementation. Control of the ESS is not yet supported.

Implemented Natures: - AsymmetricEss - SymmetricEss - ElectricityMeter (for Grid and PV)

Source Code

16. FENECON BYD Container

Implemented Natures

  • SymmetricEss

  • ManagedSymmetricEss

Source Code

17. ESS Cluster

Combines multiple energy storage systems (ESS) to one common ESS. This way every Controller can easily work with multiple ESS in parallel. Distribution of power requests to each ESS is controlled via the Power-Class .

Source Code

18. FENECON Commercial 40 AC/DC/Hybrid

Implemented Natures

  • SymmetricEss

  • ManagedSymmetricEss

  • EssDcCharger

Source Code

19. Generic Energy Storage System

Represents an Energy Storage System consisting of a Battery-Inverter and a Battery.

Source Code

20. Samsung ESS

This bundle implements the Samsung SDI ESS.

Compatible with - https://www.photovoltaik4all.de/speicher/samsung/samsung-sdi-lithium-ionen-speicher-3-6-kwh/SA23695

Source Code

21. SMA SunnyIsland 6.0H and Sunny Island 4.4M

Implemented Natures

  • SymmetricEss

  • ManagedSymmetricEss

  • AsymmetricEss

  • ManagedAsymmetricEss

  • SinglePhaseEss

  • ManagedSinglePhaseEss

Source Code

22. Alpitronic Hypercharger V1-X

Implementation of the Alpitronic Hypercharger V1-X DC electric vehicle charging station.

22.1. Compatibility

  • Alpitronic Hypercharger V1-X

22.2. Additional application notes

The charging station comes with up to four physical connectors. This implementation is designed in a way, that each connector is represented by an individual OpenEMS Component. So if you have a Alpitronic with two connectors, please configure two "EVCS Alpitronic Hypercharger" with the connector configuration property set to SLOT_0 and SLOT_1 respectively.

Supported Firmware versions: 1.7.2 and higher.

Source Code

23. EVCS Cluster

Distributes the charging power (Depending on the implementation) to the prioritized charging stations. The implementations calculate the maximum power that can be used by all charging stations.

Possible Cluster implementations:

Cluster for peak shaving
The peak shaving cluster is calculating the power depending on the grid power that can be used per phase, the maximum allowed storage power and the current values of grid, storage and EVCS consumption.

Cluster for self consumption
The self consumption cluster is calculating the power depending on the excess power.

Source Code

24. EVCS Core

24.1. Core

Core services for electric vehicle charging.

24.2. Implementing an Electric Vehicle Charging Station

These are a couple of steps that should be helpful in your implementation of a new evcs component. Note that some parts may still be missing.

  1. Gather all the important information about your Electric Vehicle Charging Station (EVCS)

    1. Communication Protocol

    2. Possible Read/Write values (Important for used Natures and their values)

    3. IP address, URL, Modbus Unit ID, or any other relevant parameters required for the communication

  2. Select Natures depending on the Read/Write values provided by the evcs (In many cases more than one)

    • Evcs (Basic reading functionality)

    • ManagedEvcs (Additional Channels and functions for writing charge power limits)

    • SocEvcs (Additional Channels for the State of Charge information)

  3. Use already existing Bridge (e.g. Hypercharger using AbstractOpenemsModbusComponent) or create a new bridge (Not every protocol is/can be generalized in a separate bundle)

    • Note that AbstractManagedEvcsComponent cannot be used if the component is a modbus component (Some functions must be called manually)

  4. Create Component based on the evcs related natures. Example HyperchargerImpl:

    @Designate(ocd = Config.class, factory = true)
@Component(//
		name = "Evcs.AlpitronicHypercharger", //
		immediate = true, //
		configurationPolicy = ConfigurationPolicy.REQUIRE //
)
@EventTopics({ //
		EdgeEventConstants.TOPIC_CYCLE_BEFORE_PROCESS_IMAGE, //
		EdgeEventConstants.TOPIC_CYCLE_EXECUTE_WRITE //
})
public class HyperchargerImpl extends AbstractOpenemsModbusComponent
		implements Evcs, ManagedEvcs, OpenemsComponent, ModbusComponent, EventHandler, Hypercharger, TimedataProvider {

    • @Designate: Standard

    • @Component: Standard

    • @EventTopics: Handle this events in the handleEvent method

    • AbstractOpenemsModbusComponent: Ease the communication with a modbus device

    • Evcs: See above

    • ManagedEvcs: See above

    • OpenemsComponent: Identifies an OpenemsComponent

    • ModbusComponent: Specific for modbus component

    • EventHandler: Used to act in a specific Event in an Openems Cycle

    • Hypercharger: Individual "Nature" for additional Channels besides the evcs natures

    • TimedataProvider: Needed for this evcs to calculate the total energy charged

  5. Create Properties needed. Most important for components not using AbstractManagedEvcsComponent:

    /**
* Handles charge states.
*/
private final ChargeStateHandler chargeStateHandler = new ChargeStateHandler(this);

/**
* Processes the controller's writes to this evcs component.
*/
private final WriteHandler writeHandler = new WriteHandler(this);

  6. Constructor using ChannelIds of implementing Natures:

    public HyperchargerImpl() {
		super(//
				OpenemsComponent.ChannelId.values(), //
				ModbusComponent.ChannelId.values(), //
				Evcs.ChannelId.values(), //
				ManagedEvcs.ChannelId.values(), //
				Hypercharger.ChannelId.values());
	}

    If it is not listed here, the component is not aware of the channels in that nature.

  7. Add Activate, Deactivate & Modified

    @Activate
private void activate(ComponentContext context, Config config) throws OpenemsNamedException {
	this.config = config;
	if (super.activate(context, config.id(), config.alias(), config.enabled(), config.modbusUnitId(), this.cm,
			"Modbus", config.modbus_id())) {
		return;
	}

	/*
	 * Calculates the maximum and minimum hardware power dynamically by listening on
	 * the fixed hardware limit and the phases used for charging
	 */
	Evcs.addCalculatePowerLimitListeners(this);

	this.applyConfig(config);
}

@Modified
private void modified(ComponentContext context, Config config) throws OpenemsNamedException {
	if (super.modified(context, config.id(), config.alias(), config.enabled(), config.modbusUnitId(), this.cm,
			"Modbus", config.modbus_id())) {
		return;
	}
	this.applyConfig(config);
}

private void applyConfig(Config config) {
	this.config = config;
	this.calculateTotalEnergy = new CalculateEnergyFromPower(this, Evcs.ChannelId.ACTIVE_CONSUMPTION_ENERGY);
	this._setFixedMinimumHardwarePower(config.minHwPower());
	this._setFixedMaximumHardwarePower(config.maxHwPower());
	this._setPowerPrecision(1);
	this._setPhases(3);
}

@Override
@Deactivate
protected void deactivate() {
	super.deactivate();
}

    The Channel values set in the applyConfig are given by the config or by default.

    The Fixed Minimum/Maximum HardwarePower and the Phases Channel are used to calculate the minimum and maximum power for the user interface. (Automatically handled by calling Evcs.addCalculatePowerLimitListeners(this) or the AbstractManagedEvcsComponent)

    Maximum Charge power selected: 17000 W

    4140 W -----------------------x------------ 22080 W (charging 6 - 32 amps on 3 phases)

    Maximum Charge power selected: 1600 W

    1380 W --x--------------------------------- 7360 W (charging 6 - 32 amps on 1 phase)

  8. Modbus specific methods

    1. Reference to the modbus bridge

      @Override
@Reference(policy = ReferencePolicy.STATIC, policyOption = ReferencePolicyOption.GREEDY, cardinality = ReferenceCardinality.MANDATORY)
protected void setModbus(BridgeModbus modbus) {
	super.setModbus(modbus);
}

    2. Modbus-Register mapping

      @Override
	protected ModbusProtocol defineModbusProtocol() throws OpenemsException {
		var modbusProtocol = new ModbusProtocol(this,

				new FC3ReadRegistersTask(this.offset.apply(0), Priority.LOW,
						m(Hypercharger.ChannelId.RAW_CHARGE_POWER_SET,
								new UnsignedDoublewordElement(this.offset.apply(0)))),

				new FC16WriteRegistersTask(this.offset.apply(0),
						m(Hypercharger.ChannelId.APPLY_CHARGE_POWER_LIMIT,
								new UnsignedDoublewordElement(this.offset.apply(0))),
						m(Hypercharger.ChannelId.SETPOINT_REACTIVE_POWER,
								new UnsignedDoublewordElement(this.offset.apply(2)))),
								...

      Most mistakes: - Wrong function code, offset, or any other information provided by the Modbus protocol or manual - Wrong AbstractModbusRegisterElement for a register - Missing register (Unimportant register could be skipped with new DummyRegisterElement(xxx),) - Important tasks with Priority HIGH are blocked by other unimportant tasks with Priority HIGH - Read/Write register must be read and write in different tasks with different function codes - Scale factor overlooked. The scale factor can be easily adjusted using, for example, SCALE_FACTOR_MINUS_2

  9. Check if every Channel is set correctly

    To do this, you could add the component in the controller 'DebugDetailedLog', or download the information of a component using the 'Excel Export' feature in the system profile."

Source Code

25. dezony IQ Charging Station (BETA)

This component implements the dezony IQ charging station by the manufacturer dezony: https://dezony.com

25.1. Software release life cycle: BETA

This implementation has been carried out during OpenEMS Hackathon Q1/2023 and is not yet fully feature tested. Please consider it BETA quality

25.2. Compatibility

25.3. Additional application notes

Implemented Natures: * Evcs (Electric Vehicle Charging Station) * ManagedEvcs

API: dezony swagger documentation

Source Code

26. Go-e Charger Home Charging Station

This component implements the go-e charger home charging station, which is controlled and read out using the Rest-API protocol. It collects all relevant informations into the given Nature Channels and its own Channels and sends charging commands that have been set by another controllers.

Implemented Natures: * Evcs (Electric Vehicle Charging Station) * ManagedEvcs

27. Heidelberg Wallbox Energy Control Charging Station

Implementation of the Heidelberg electric vehicle charging station.

27.1. Compatibility

  • Wallbox Energy Control

27.1.1. Technical Data

Implemented Natures: * Evcs (Electric Vehicle Charging Station)

Source Code

28. Mennekes Amtron Professional Charging Station

This component implements the Mennekes Professional charging station by the manufacturer Mennekes. It collects all relevant information into the given Nature Channels and its own Channels and sends charging commands that have been set by another controllers.

28.1. Software release life cycle: BETA

This implementation has been carried out during OpenEMS Hackathon Q1/2023 and is not yet fully feature tested. Please consider it BETA quality

28.1.1. Technical Data

Implemented Natures: * Evcs (Electric Vehicle Charging Station) * ManagedEvcs

Source Code

29. ABL Charging Station

This component implements the ABL EMH 3 series charging station, which is controlled and read out using the OCPP protocol. It provides specific information for the AbstractOcppEvcsComponent.

Implemented Natures: * Evcs (Electric Vehicle Charging Station) * MeasuringEvcs

Extended abstract class: * AbstractOcppEvcsComponent

Source Code

30. Electric Vehicle Charging Station OCPP Common

The Open Charge Point Protocol (OCPP) is an application protocol for communication between Electric vehicle charging stations (EVCS) and a central management system.

The whole bundle contains a library of the OCPP functions. It also provides a default abstract ocpp EVCS component that can be used by every specific charging station and a OcppServer interface that provides a minimum functionality, to be able to send data to a charging station.

Implemented Natures: * Evcs (Electric Vehicle Charging Station * MeasuringEvcs (Can get measured information)

Source Code

31. IES KeyWatt Charging Station

This component implements the IES KeyWatt CCS charging station with a single plug, which is controlled and read out using the OCPP protocol. It provides specific information for the AbstractOcppEvcsComponent.

Implemented Natures: * Evcs (Electric Vehicle Charging Station * ManagedEvcs * MeasuringEvcs (Can get measured information)

Extended abstract class: * AbstractOcppEvcsComponent

Source Code

32. OCPP Server

The OCPP Server is implementing a central management system. The server maintains connections to the EVCS’s, i.e.

  • connects to the charging stations

  • distributes their information to each EVCS component

  • send commands to the charging stations

Source Code

33. Spelsberg SMART PRO charging station (BETA)

Implementation of the Spelsberg SMART PRO charging station.

This EVCS component implementation is not yet fully feature tested. Please consider it BETA quality.

33.1. Technical Data

  • Rated current: 16A single and three phase

  • Charging cable: Type 2, up to 16A

  • Max. charging power: 11kW (three phases), 3.7kW (single phase)

  • Communication protocol: Modbus TCP

33.2. This implementation includes:

  • Reading of current and power from the EVCS

  • Setting charge power/current via OpenEMS Edge EVCS Controller

  • Calculation of the energy summary for transactions

  • EVCS status updates

  • Validation of Modbus TCP connection

33.3. Planned Features:

  • Support for automatic phase shifting

Source Code

34. Webasto Next Charging Station (BETA)

Implementation of the Webasto Next electric vehicle charging station.

34.1. Software release life cycle: BETA

This implementation has been carried out during OpenEMS Hackathon Q1/2023 and is not yet fully feature tested. Please consider it BETA quality

34.2. Compatibility

34.2.1. Technical Data

  • Rated current:

    • 16A single phase

    • 32A three phases

  • Charging cable: Type 2, up to 32A / 400V AC

  • Max. charging power: 22kW (three phases), 3.7 (single phase)

  • Communication protocol: Modbus TCP

34.3. Additional application notes

The implementation includes:

  • Reading actual values from the charging station

  • Setting charge power/current set-points via OpenEMS Edge EVCS Controllers

Source Code

35. Webasto Unite Charging Station (BETA)

Implementation of the Webasto Unite electric vehicle charging station.

35.1. Software release life cycle: BETA

This implementation has been carried out during OpenEMS Hackathon Q1/2023 and is not yet fully feature tested. Please consider it BETA quality

35.2. Compatibility

35.3. Additional application notes

The implementation includes:

  • Reading actual values from the charging station

  • Setting charge power/current set-points via OpenEMS Edge EVCS Controllers

Source Code

36. EVSE Charge-Point Hardy Barth (Salia)

This component implements the Salia charging station by the manufacturer Hardy Barth: https://www.echarge.de/de/home

Source Code

37. EVSE Charge-Point Heidelberg Connect

Source Code

38. EVSE Charge-Point KEBA KeContact P30 and P40

Provides implementations for KEBA P30 via UDP protocol and KEBA P40 via Modbus/TCP protocol.

Source Code

39. EVSE Electric-Vehicle Generic

Source Code

40. FENECON DESS

Applies to multiple similar products like the FENECON by BYD PRO Hybrid.

Implemented Natures: - SymmetricEss - AsymmetricEss - EssDcCharger - ElectricityMeter (for Grid and AC-connected PV)

Source Code

41. FENECON Mini 3-3 | 3-6

Implemented Natures: - SinglePhaseEss - AsymmetricEss - SymmetricEss - ElectricityMeter (for Grid and PV)

Source Code

42. FENECON Pro 9-12

Implemented Natures: - SymmetricEss - ManagedSymmetricEss - AsymmetricEss - ManagedAsymmetricEss - ElectricityMeter (for PV)

Source Code

43. GoodWe ET and BT-Series Hybrid Inverters

Ess:

  • SymmetricEss

Charger: (ET only)

  • EssDcCharger

Grid-Meter:

  • ElectricityMeter

Source Code

44. Heatingelement Askoma

Implements an Askoma heating element.

See https://www.askoma.com/de/produkte.html

Source Code

45. Heatingelement MyPv

Implements a MyPv heating element.

See https://www.my-pv.com/de/

Source Code

46. Filipowski (F&F) Analog Output

This bundle implements the MR-AO-1 analog output module, which has four possible analog outputs.

Compatible with - MR-AO-1

Implemented Natures - AnalogOutput

Default Configuration - Baud rate: 9600 - Data bits: 8 - Parity: NONE - Start bits: 1 - Stop bits: 2

Source Code

47. GPIO (General Purpose Input/Output)

This bundle implements GPIO (General Purpose Input/Output) ports using LinuxFS communication. Tested mainly on Raspberry Pi based devices.

47.1. ModBerry X500 CM4

The module supports GPIOs of all ModBerry X500 CM4 models. ModBerry is based on the Raspberry Pi Compute Module 4.

The pin out description is available in the datasheet: https://modberry.techbase.eu/wp-content/uploads/2020/11/ModBerry_500CM4_EN.pdf

Source Code

48. KMtronic Modbus Relay Board

This bundle implements the Kmtronic Modbus Relay board. Relay outputs can be used to turn ON/OFF lights, motors and signal alarms. Implementations are for 4 and 8 relais.

Implemented Natures

  • DigitalOutput

Source Code

49. Emergency Power Switch

This implements a Emergency Power Switch (German: Netztrennstelle).

Source Code

50. RevolutionPi Digital IO Module

This bundle implements the Kunbus RevolutionPI DigitalIO enhancement board. It can be used to turn ON/OFF a data output or to read in digital data input. It provides 14 digital input and 14 digital output channels.

Implemented Natures: - DigitalOutput - DigitalInput

50.1. Dependencies

The RevolutionPi Digital IO OpenEms Bundle depends on the librevpi-dio-java git library project. A binary version of this library is already included in this OpenEMS Bundle. See https://github.com/clehne/librevpi-dio-java for more information.

50.2. Notes

Prepare Kunbus RevPi:

The Digital IO hardware enhancement module on your Kunbus RevolutionPi system needs to be enabled before starting OpenEMS (see Kunbus-Website for configuration settings).

51. Shelly WiFi Relay Switch

This bundle implements Shelly WiFi Relay Switches and Meters.

Compatible with - Shelly 1 - Shelly 2.5 - Shelly 3EM - Shelly Plug S - Shelly Plus Plug S - Shelly Pro 3EM 3-Phase Meter - Shelly Plus 1PM - Shelly Pro 3 - Shelly Plus PM Mini Gen2 - Shelly Plus PM Mini Gen3

Source Code

First you have to configure a modbus server in LogoSoft which either accepts all connection sources or you limit this to your EMS-system. Like all other modbus devices you have to configure a modbus-ID (255 is default in LogoSoft!) and a start address, e.g. 100 or use the default address 0.

If you don´t do any changes the addresses are configured as coils. In Logo! a virtual address (V) is written 0.0 which is the virtual address 0, Bit 0. For the connected device the coil-addresses start with 800 (first bit/coil), 801 is the second coil and so on

Source Code

53. WAGO Fieldbus Coupler 750-352

Implemented Natures

  • DigitalOutput

  • DigitalInput

This component reads the current WAGO fieldbus coupler configuration and dynamically creates its Input and Output Channels accordingly.

Make sure to update the WAGO fieldbus coupler configuration before activating this component. Open the WAGO fieldbus web interface, click "IO config" and "create ea-config.xml" to update the configuration. Default username is admin, default password is wago.

The following examples assume the Component-ID is io0 and the addresses are valid for the first WAGO extension. For extensions 2, 3,…​ just increase the number behind M. Channel names follow this logic:

53.1. WAGO 750-523 "1-channel relay output"

wago.com

io0/RelayM1

Input/Output

the relay

io0/RelayM1Hand

Input

state of the manual switch

53.2. WAGO 750-501 "2-channel digital output"

wago.com

io0/DigitalOutputM1C1

Input/Output

the first digital output

io0/DigitalOutputM1C2

Input/Output

the first digital output

53.3. WAGO 750-400 "2-channel digital input"

wago.com

io0/DigitalInputM1C1

Input

the first digital input

io0/DigitalInputM1C2

Input

the second digital input

Source Code

54. Weidmüller Fieldbus Coupler UR20-FBC-MOD-TCP-V2

Implemented Natures

  • DigitalOutput

  • DigitalInput

This component reads the current Weidmüller fieldbus coupler configuration and dynamically creates its Input and Output Channels accordingly.

The following examples assume the Component-ID is io0 and the addresses are valid for the first extension. For extensions 2, 3,…​ just increase the number behind M. Channel names follow this logic:

54.1. Digital input module UR20-4DI-P

io0/DigitalInputM1C1

Input

digital input #1

io0/DigitalInputM1C2

Input

digital input #2

io0/DigitalInputM1C3

Input

digital input #3

io0/DigitalInputM1C4

Input

digital input #4

54.2. Digital output module UR20-8DO-P

io0/DigitalOutputM1C1

Input/Output

digital output #1

io0/DigitalOutputM1C2

Input/Output

digital output #2

io0/DigitalOutputM1C3

Input/Output

digital output #3

io0/DigitalOutputM1C4

Input/Output

digital output #4

io0/DigitalOutputM1C5

Input/Output

digital output #5

io0/DigitalOutputM1C6

Input/Output

digital output #6

io0/DigitalOutputM1C7

Input/Output

digital output #7

io0/DigitalOutputM1C8

Input/Output

digital output #8

https://catalog.weidmueller.com/catalog/Start.do?ObjectID=2476450000

Source Code

55. KACO Blueplanet Hybrid 10

55.1. Implemented Components:

  • Kaco.BlueplanetHybrid10.Core

    • This component is always required to establish the communication to the hardware device.

  • Kaco.BlueplanetHybrid10.Ess

    • This implements the Energy Storage System part (i.e. ManagedSymmetricEss) for read-only (fast internal control) or read-write (slow external control)

  • Kaco.BlueplanetHybrid10.Charger

    • This implements the DC Charger/MPP tracker for the photovoltaics system (i.e. EssDcCharger). Note that there is only one instance for both MPP trackers, because the inverter does not provide separated power values.

  • Kaco.BlueplanetHybrid10.PvInverter

    • This implements the inverter as a pure photovoltaics inverter (i.e. ManagedSymmetricPvInverter). Use this instead of Ess+Charger, if you are using the inverter purely as PV inverter without a battery.

  • Kaco.BlueplanetHybrid10.GridMeter

    • This implements the grid meter (product name "VECTIS" or "blueplanet hy-switch") connected to the inverter (i.e. ElectricityMeter)

55.2. License/Dependencies

The configuration of the Kaco.BlueplanetHybrid10.Core Component requires an identkey. This relates to the "Partner ID" that has to be acquired from Katek Memmingen GmbH. Without the identkey it is not possible to establish a communication with the hardware device.*

This bundle is provided under the EPL (Eclipse Public License), but it depends on the Katek EDCOM library under io.openems.edge.katek.edcom, which is licensed as LGPL (GNU Lesser General Public License) by Katek Memmingen GmbH.

55.3. Product page:

https://kaco-newenergy.com/de/produkte/blueplanet-hybrid-10.0-TL3/

Source Code

56. Katek EDCOM Library

EDCOM 8.1 is a java cross platform library for communication with 10kW hybrid Inverter.

Java code provided by Katek Memmingen GmbH under the GNU LPGLv3.0. Converted to Java 11 compatible code and packaged as OpenEMS Edge bundle by FENECON GmbH.

Source Code

57. KOSTAL

57.1. KOSTAL PLENTICORE

  • hybrid inverter with battery control and PV production

  • KSEM device

57.2. KOSTAL PIKO

  • SymmetricEss

  • ElectricityMeter (for Grid meter)

  • EssDcCharger (for PV)

Source Code

58. ABB B23 Meter

Implemented Natures: - ElectricityMeter

Source Code

59. Artemes AM-2

Implemented Natures: - ElectricityMeter

Source Code

60. B-Control | TQ-Systems EM300 Meter

Implemented Natures: - ElectricityMeter

Source Code

61. DRT428M-2 Meter

Reads data of a DRT428M-2 Meter. More details are present in the below link https://xn—​stromzhler-v5a.eu/stromzaehler/drehstromzaehler/fuer-hutschiene-geeicht/252/drt428m-2-zweirichtungs-drehstromzaehler-geeicht-fuer-din-hutschiene-mit-s0-ir-rs485#

Implemented Natures: - ElectricityMeter

Source Code

62. Meter Camille Bauer APLUS

Implementation of a Camille Bauer APLUS meter.

https://camillebauer.com/produkt/aplus/

Source Code

63. Carlo Gavazzi EM300 Meter

Applies to - CARLO GAVAZZI EM330 - CARLO GAVAZZI EM340

Implemented Natures: - ElectricityMeter

Source Code

64. Discovergy Smart-Meter

Reads data of a Discovergy Smart-Meter via online REST-Api. See https://api.discovergy.com for details.

Implemented Natures: - ElectricityMeter

Source Code

65. Eastron/Microcare SDM 630 and 120 Meter

This implementation is functionally compatible with a number of energy meters with the names:

  • SDM 630 and

  • SDM 120

Implemented Natures: - ElectricityMeter

Source Code

66. Janitza Meters

Implemented Meters: - UMG 96RM-E - UMG 104 - UMG 511 - UMG 604

Source Code

67. Meter KDK 420506PRO20-U (2PU CT) Professional meter

Implementation of a KDK meter.

67.1. Software release life cycle: Stable release

67.2. Compatibility

Source Code

68. PhoenixContact Meter

Implemented Natures

  • ElectricityMeter

Source Code

69. Plexlog Datalogger

Implemented Natures: - ElectricityMeter

Source Code

70. PQ-Plus Meters UMD96 | UMD97

Implemented Natures: - ElectricityMeter

Details of the meter is present in

UMD 96 - https://www.pq-plus.de/produkte/hardwarekomponenten/umd-96/

UMD 97 - https://www.pq-plus.de/en/products/hardware-components/umd-97/

Source Code

71. Schneider Acti9 Smartlink Meter

Implemented Natures: - ElectricityMeter

To configure the meter, first add a modbus tcp bridge connecting to the correct IP address, then configure this meter to use the configured modbus bridge. The unit ID is by default 1.

Source Code

72. Siemens Meter

  • Applies to

    • Siemens PAC1600

    • Siemens PAC2200

    • Siemens PAC3200

    • Siemens PAC4200

  • Implemented Natures

    • ElectricityMeter

Source Code

73. SMA Sunny Home Manager 2.0 Integrated Meter

This implementation uses the integrated energy meter of the SMA Sunny Home Manager 2.0 Data needs to polled through Modbus from an attached SMA inverter as the HM2.0 does not have a local API on the device itself

Implemented Natures: - ElectricityMeter

Source Code

74. SOCOMEC Meter

Just configure Meter.Socomec.Singlephase or Meter.Socomec.Threephase. The actual type and modbus protocol of the Socomec meter is identified automatically.

Source Code

75. Virtual Meter

75.1. Virtual Subtract Meter

This is a virtual meter built from subtracting other meters or energy storage systems.

The logic calculates Minuend - Subtrahend1 - Subtrahend2 - …​.

Example use-case: create a virtual Grid-Meter from Production-Meter, Consumption-Meter and Energy Storage System (ESS) - by definition Consumption is defined as `Consumption = ESS + Grid + Production (AC) - or: `Grid = Consumption - ESS - Production (AC) - this can be achieved by configuring the Consumption-Meter as Minuend and Production-Meter and ESS as Subtrahends.

75.2. Virtual Add Meter

This is a virtual meter which is used to sum up the values from multiple symmetric meters. The use case for this feature is, Usually when there are multiple meters reading values from different systems, The average values from the systems make more sense for calculation and statistics.

Implemented Natures - ElectricityMeter

75.2.1. Example Configuration

  • Component-ID : meter0

  • Alias : virtualMeter

  • Meter-Type : PRODUCTION

  • Meter IDs : [meter1, meter2, meter3]

Meter IDs is a list of the meters which needs summing of the values.

The above example configuration describes, The values from the three meters configured (meter1, meter2, meter3) are summed up and average values is set to the corresponding channel address.

Source Code

76. Weidmueller 525 Meter

Implemented Natures: - ElectricityMeter

Source Code

77. Meter Ziehl EFR4001IP

Implemented Natures: - ElectricityMeter

For details, see https://www.ziehl.com/de/produkte/detail/EFR4001IP-362.

Modbus Protocol: https://www.ziehl.com/de/produkte/dl/Betriebsanleitung_Modbus-3585/?task=download

Source Code

78. OneWire Thermometer

Implemented Natures

  • Thermometer

Source Code

79. Long Short-Term Memory (LSTM) predictor

The Long Short-Term Memory (LSTM) model is a type of recurrent neural network (RNN) that is particularly well-suited for time series prediction tasks, including consumption and production power predictions, due to its ability to capture dependencies and patterns over time. More details on LSTM

This application is used for predicting consumption and production power values. Here, for power prediction, LSTM models can analyze historical power data to learn patterns and trends that occur over time, such as:

  • Daily and seasonal variations: Consumption power often follows cyclic patterns (e.g. higher usage during the day, lower at night). Solar production power is high during the day and zero during the nights.

  • External Factors: LSTM can incorporate external factors like weather, day of the week, or holidays to improve prediction accuracy.

79.1. Training LSTM for power predictions:

  • Input Data (channels address _sum/UnmanagedConsumptionActivePower): Time series data of past consumptions.

  • Pre-processing: Data needs to be scaled and sometimes transformed to remove seasonality or noise.

  • Training: The LSTM is trained on historical data using techniques like backpropagation through time (BPTT), where it learns to minimize the error between predicted and actual consumption.

  • Prediction: Once trained, the model can predict future power consumption for various time steps ahead (e.g., hours, days, or even weeks).

In practice, LSTMs are favored for their ability to learn complex time-related patterns, making them effective in forecasting energy demand patterns that can inform Energy Management System (EMS) for optimized energy distribution and cost strategies.

79.2. Note for activating the predictor

This predictor creates a folder named "lstm" in the OpenEMS data directory (defined by openems.data.dir in EdgeApp.bndrun).

Initially, a generic model will be used for predictions, which may not yield optimal results. However, a training process is scheduled to occur every 45 days, during which the models in this directory will be updated. The 45-day interval consists of 30 days for training and 15 days for validation.

As a result of this process, a new model will be trained and will automatically replace the previous one.

Source Code

80. Persistence-Model Predictor

Predicts values using the 'same-as-last-day' approach.

Source Code

81. Linear Model Production-Predictor

This model predicts future PV production using weather and time-related data. It employs a linear model that learns the relationship between historical PV generation and corresponding historical weather data. Based on weather forecasts and time information, the model can then estimate the expected PV output for future periods.

Source Code

82. Similarday-Model Predictor

This predictor uses "Similar day technique" for prediction. This particular implementation requires mainly two inputs, which are

  • Num of past weeks (n)

  • The channels address data, which needs to predicted.

The Similarday-Model Predictor predicts same values as on same day in the previous weeks, e.g. the prediction for coming monday calculates the average of (n) previous monday’s.

This predictor is mainly used for predicting the Consumption power and energy. And the Accuracy of the model is scientifically verified within EMSIG project.

Note: This predictor adds one hour offset for (n) weeks during time changeover (summertime → wintertime and wintertime → summertime).

Source Code

83. PV-Inverter Cluster

Combines multiple PV-Inverters to one common PV-Inverter. This way every Controller can easily work with multiple PV-Inverters in parallel.

Source Code

84. Fronius PV inverter

Implementation of the Fronius PV inverters.

Tested on - Fronius Symo

Implemented Natures: - ElectricityMeter - ManagedSymmetricPvInverter

Source Code

85. KACO blueplanet PV inverter

Implementation of the KACO blueplanet series PV inverters.

85.1. Compatibility

  • NX3 M2 Series

  • TL3 Series

    • KACO blueplanet 3.0 TL3 - 10.0 TL3

    • KACO blueplanet 15.0 TL3 + 20.0 TL3

    • KACO blueplanet 29.0 TL3 LV

    • KACO blueplanet 50.0 TL3

    • KACO blueplanet 60.0 TL3

    • KACO blueplanet 87.0 TL3 - 125 TL3

    • KACO blueplanet 125 TL3 - 165 TL3

85.2. Additional application notes

Experiences from testing this plugin with a KACO Blueplanet NX3 M2:

  • Modbus Unit-ID was 3, for both Modbus TCP and RTU. Modbus TCP also worked with Unit-ID 1, but RTU only worked with 3.

  • When using the Wlan module to connect via Modbus TCP, make sure no cable is plugged into the RJ45 socket used for Modbus RTU. If there is a cable plugged in, it will still work, but you will get a lot of connection errors.

  • Similar situation when using Modbus RTU - unplug the Wlan module. Modbus RTU still works with the Wlan module plugged in, but you will get a lot of connection errors.

  • The Wlan module that handles the Modbus TCP connection does not automatically reconnect to the configured Wlan router if it looses the connection (for example, when the router is restarted), or if the router is not reachable when the inverter starts up.

  • To reconnect, the inverter needs to restart. Since the NX3 usually shuts down over night and restarts in the morning, this is not too much of a problem.

Source Code

86. Kostal PV inverter

Implementation of the Kostal PV inverters.

Tested on - Kostal Plenticore 5.5 - Kostal Pico 5.5

With versions: - UI Version: 01.18.05255 - MC version: 01.47 - IOC version: 01.45

Older versions had problems with the implementation of sunspec.

Configuration in Kostal UI: Modbus must be active and byte order must be big-endian for sunspec.

Implemented Natures: - ElectricityMeter - ManagedSymmetricPvInverter

Source Code

87. SMA Sunny Tripower PV inverter

Implementation of the SMA Sunny Tripower PV inverters.

Tested on - SMA SUNNY TRIPOWER 8.0 / 10.0 - SMA SUNNY TRIPOWER 15000TL / 20000TL / 25000TL

Implemented Natures: - ElectricityMeter - ManagedSymmetricPvInverter

Source Code

88. Solar-Log

Implemented Natures: - SymmetricPvInverter - ElectricityMeter

Source Code

89. Simulated OpenEMS Components

This bundle provides simulated OpenEMS Components for the Natures. They are useful for testing and demoing without real hardware.

89.1. Simulator-App

The Simulator-App is a very specific component that needs to be handled with care. It provides a full simulation environment to run an OpenEMS Edge instance in simulated realtime environment. After you ran a Simulation, you will receive the simulation result as a JSON. Also the simulation result can be viewed in OpenEMS UI.

Be aware that the SimulatorApp Component takes control over the complete OpenEMS Edge Application, i.e. if you enable it, it is going to delete all existing Component configurations!

To run a simulation:

  1. Run OpenEMS Edge using the EdgeApp.bndrun

  2. Open up Apache Felix Web Console and

    1. activate a "Controller Api REST/JSON Read-Write"

    2. activate a "Simulator App"

  3. Send a JSON-RPC Request like the following, providing full configurations for all required OpenEMS Edge Components

{
   "method":"componentJsonApi",
   "params":{
      "componentId":"_simulator",
      "payload":{
         "method":"executeSimulation",
         "params":{
            "components":[
               {
                  "factoryPid":"Scheduler.AllAlphabetically",
                  "properties":[
                     {
                        "name":"id",
                        "value":"scheduler0"
                     }
                  ]
               },
               {
                  "factoryPid":"Simulator.GridMeter.Reacting",
                  "properties":[
                     {
                        "name":"id",
                        "value":"meter0"
                     }
                  ]
               },
               {
                  "factoryPid":"Simulator.NRCMeter.Acting",
                  "properties":[
                     {
                        "name":"id",
                        "value":"meter1"
                     },
                     {
                        "name":"alias",
                        "value":"Consumption"
                     },
                     {
                        "name":"datasource.id",
                        "value":"_simulator"
                     }
                  ]
               },
               {
                  "factoryPid":"Simulator.ProductionMeter.Acting",
                  "properties":[
                     {
                        "name":"id",
                        "value":"meter2"
                     },
                     {
                        "name":"alias",
                        "value":"South Roof"
                     },
                     {
                        "name":"datasource.id",
                        "value":"_simulator"
                     }
                  ]
               },
               {
                  "factoryPid":"Simulator.EssSymmetric.Reacting",
                  "properties":[
                     {
                        "name":"id",
                        "value":"ess0"
                     },
                     {
                        "name":"maxApparentPower",
                        "value":10000
                     },
                     {
                        "name":"capacity",
                        "value":10200
                     },
                     {
                        "name":"initialSoc",
                        "value":50
                     }
                  ]
               },
               {
                  "factoryPid":"Controller.Symmetric.Balancing",
                  "properties":[
                     {
                        "name":"id",
                        "value":"ctrlBalancing0"
                     },
                     {
                        "name":"ess.id",
                        "value":"ess0"
                     },
                     {
                        "name":"meter.id",
                        "value":"meter0"
                     }
                  ]
               }
            ],
            "clock":{
               "start":"2000-01-01T00:00:00.00Z",
               "end":"2000-01-08T00:00:00.00Z",
               "timeleapPerCycle":900000,
               "executeCycleTwice":true
            },
            "profiles":{
               "meter1/ActivePower": [436,404,373,344,316,290,267,248,236,227,220,216,211,207,203,199,196,193,192,191,191,191,193,195,198,201,206,211,219,232,254,290,342,405,474,543,607,666,719,767,810,849,886,924,962,999,1029,1049,1055,1047,1025,990,944,890,833,779,732,692,658,630,607,588,572,555,539,527,524,535,562,602,647,692,731,764,795,825,854,878,892,887,861,820,775,733,704,683,666,646,621,591,556,518,479,440,402,364,436,404,374,345,316,290,267,249,236,227,220,216,211,207,203,199,196,193,192,191,191,191,193,195,198,201,206,211,219,232,255,291,342,405,475,544,608,667,720,768,811,850,888,926,964,1000,1030,1050,1056,1048,1027,992,945,891,834,780,733,693,659,631,608,589,572,556,540,528,525,536,563,603,648,693,732,765,796,826,855,880,893,888,862,821,776,735,705,684,667,647,622,591,556,519,480,441,402,365,338,304,274,249,231,218,209,204,200,198,197,195,194,193,191,191,192,194,196,200,204,215,238,279,340,413,489,557,607,642,663,673,676,673,665,653,638,622,607,594,586,580,578,578,580,584,593,607,626,647,664,673,670,658,639,619,600,583,568,553,539,527,517,511,510,515,527,549,579,618,662,711,761,810,855,893,922,940,943,931,902,862,818,777,744,716,691,665,635,602,566,528,489,450,412,374,338,304,275,250,231,218,210,204,201,198,197,196,194,193,192,192,192,194,197,200,205,216,239,279,340,414,490,558,608,643,664,674,677,674,666,654,639,623,608,595,587,581,579,579,581,585,594,608,627,648,665,674,671,659,640,620,601,584,569,554,540,528,518,512,511,516,528,550,580,619,663,712,762,811,856,895,924,941,945,932,904,864,820,778,745,717,692,666,636,603,567,529,490,451,413,375,338,304,275,250,231,218,210,204,201,198,197,196,194,193,192,192,192,194,197,200,205,216,239,279,340,415,491,558,609,643,664,675,678,675,666,654,639,624,608,596,587,582,579,579,581,586,594,608,628,649,666,675,672,659,641,621,602,585,569,554,540,528,518,513,512,517,529,550,581,619,664,712,763,812,857,896,925,942,946,933,905,865,820,779,745,718,693,667,637,603,567,529,491,452,413,375,339,305,275,250,232,219,210,204,201,198,197,196,194,193,192,192,192,194,197,200,205,216,239,280,341,415,491,559,609,644,665,676,679,676,667,655,640,624,609,596,588,582,580,580,582,586,595,609,628,649,667,676,673,660,641,621,602,585,570,555,541,529,519,513,512,517,529,551,581,620,665,713,764,813,858,897,926,943,947,934,906,865,821,780,746,719,694,668,637,604,568,530,491,452,413,375,339,305,275,250,232,219,210,205,201,199,198,196,195,194,192,192,193,195,197,201,205,216,239,280,341,415,492,559,610,645,666,676,679,676,668,656,641,625,609,597,588,583,580,580,582,587,595,609,629,650,667,676,673,661,642,622,603,586,570,555,541,529,519,514,513,518,530,551,582,621,665,714,764,814,859,897,927,944,948,935,906,866,822,781,747,719,694,668,638,604,568,530,492,452,414,376],
               "meter2/ActivePower": [0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,4,24,100,250,277,345,449,457,535,530,575,770,862,720,779,808,638,552,457,440,574,537,499,356,216,267,180,180,147,102,19,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,23,105,162,223,271,309,370,431,463,514,481,463,516,467,406,375,361,401,387,372,345,334,337,312,275,229,184,141,96,20,4,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,5,20,74,134,173,209,254,275,302,331,380,419,437,471,410,441,444,410,394,400,396,384,387,391,350,291,260,208,140,74,20,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,3,24,130,215,278,378,443,529,534,568,797,726,618,766,703,802,809,755,783,682,633,672,590,629,515,523,403,318,251,171,31,3,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,26,56,336,1979,945,2897,3580,2510,3097,3499,5616,6327,2631,898,3859,3909,4931,3683,5996,1777,3615,3415,1601,1254,4954,4145,3426,1163,101,457,27,5,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,6,21,65,25,48,84,108,125,123,99,84,119,214,202,183,104,151,450,881,1878,3424,5211,4329,3986,1796,1904,1618,1173,646,758,50,13,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,13,35,104,163,246,349,329,406,387,379,457,396,488,530,540,591,835,774,740,569,549,542,524,549,471,446,337,234,192,110,30,7,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0]
            },
            "collect":[
               "_sum/GridActivePower",
               "_sum/EssActivePower",
               "_sum/ProductionActivePower",
               "_sum/ConsumptionActivePower",
               "_sum/EssSoc"
            ]
         }
      }
   }
}

Source Code

90. SolarEdge PV Inverter + Grid-Meter

Implementation of the SolarEdge PV inverters.

Implemented Natures: - ElectricityMeter

Source Code

91. Tesla Powerwall 2

Implementation of the Tesla Powerwall 2 energy storage system

Implemented Natures

  • SymmetricEss

Source Code

92. Time-Of-Use Tariff Awattar

Retrieves the hourly prices from the Awattar API and converts them into quarterly prices. Prices are updated every day at 14:00 and stored locally.

Source Code

93. Time-Of-Use Tariff Corrently by STROMDAO

Retrieves the quarterly prices from the Corrently API. Prices are updated every day at 14:00 and stored locally.

Source Code

94. Time-Of-Use Tariff ENTSO-E

This implementation uses the ENTSO-E transparency platform to receive day-ahead prices in European power grids.

To request a (free) authentication token, please see chapter "How to get security token?" in the official API documentation: https://transparencyplatform.zendesk.com/hc/en-us/articles/12845911031188-How-to-get-security-token

Prices retrieved from ENTSO-E are subsequently converted to the user’s currency (defined in Core.Meta Component) using the Exchange Rates API.

For detailed information about the Exchange Rates API, please refer to: https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html

Source Code

95. Time-Of-Use Tariff Groupe-E

This implementation uses the Groupe-E platform to receive day-ahead quarterly prices.

Prices retrieved from Groupe-E are subsequently converted to the user’s currency (defined in Core.Meta Component) using the Exchange Rates API.

For detailed information about the Exchange Rates API, please refer to: https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html

Source Code

96. Time-Of-Use Tariff Stadtwerk Hassfurt

Retrieves the hourly prices from the Stadtwerk Hassfurt API and converts them into quarterly prices. The current implementation supports both "haStrom Flex" and "haStrom Flex Pro" models provided by Stadtwerk Hassfurt.

Source Code

97. Time-Of-Use Tariff Manual

This bundle provides manually configurable time-of-use-tariffs.

Implementations:

97.1. Octopus Go

Calculates the quarterly prices for the next 36 hours based on the standard and low-price details from the user’s contract. For a detailed overview of the tariff structure, please refer to: https://octopusenergy.de/octopus-go

97.2. Octopus Heat

Calculates the quarterly prices for the next 36 hours based on the high, standard and low-price details from the user’s contract. For a detailed overview of the tariff structure, please refer to: https://octopusenergy.de/octopus-heat

Source Code

98. Time-Of-Use Tariff rabot.charge

Retrieves the hourly prices from the rabot.charge API and converts them into quarterly prices.

Source Code

99. Time-Of-Use Tariff Swisspower

Retrieves the quarterly prices from the Swisspower ESIT API.

For detailed information about the Swisspower ESIT API, please refer to: https://esit-test.code-fabrik.ch/doc_scalar/

Prices retrieved from Swisspower are subsequently converted to the user’s currency (defined in Core.Meta Component) using the Exchange Rates API.

For detailed information about the Exchange Rates API, please refer to: https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html

Source Code

100. Time-Of-Use Tariff Tibber

Retrieves the hourly prices from the Tibber API and converts them into quarterly prices. Prices are updated every day at 14:00 and stored locally.

Source Code

101. Weather Open-Meteo

Implements a subscription to the Open-Meteo API to fetch weather forecasts for the upcoming days at fixed time intervals. The system periodically polls the API to update forecast data. Historical weather data can be retrieved on demand through individual API calls. All weather data is provided with a resolution of 15 minutes.

Source Code

102. KACO blueplanet hybrid 10.0 TL3

Implemented Natures

  • SymmetricEss

  • ManagedSymmetricEss

(proprietary)