# Edge-Module - Programmierstil

**URL:** <https://community.openems.io/t/edge-module-programmierstil/1477>\
**Category:** Deutsches Forum\
**Created:** [March 31, 2023, 9:37am UTC](https://community.openems.io/t/edge-module-programmierstil/1477 "2023-03-31T09:37:27Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![S\_BartelGFP](https://community.openems.io/letter_avatar_proxy/v4/letter/s/35a633/32.png) [@S\_BartelGFP](https://community.openems.io/u/S_BartelGFP)\
**Post date:** [March 31, 2023, 9:37am UTC](https://community.openems.io/t/edge-module-programmierstil/1477/1 "2023-03-31T09:37:27Z")

</div>

Hallo Community und Team

Ich würde gerne besser verstehen, nach welchem _Paradigma_ man Edge-Module implementiert.  
Wenn beispielsweise ein ESS implementiert wird, zu dem eine Batterie und ein WR gehören:

_Besitzt_ das ESS einen WR oder implementiert das ESS einen WR, indem es von ihm ableitet, bzw dessen Interface implementiert?

Zweite Frage;  
Wenn mein ESS die Hardware-Daten aus einer proprietären Quelle abfragt (http-Server → Json):

Sollte das per Zeitintervall geschehen und wenn ja, muss ich dafür einen eigenen Timer implementieren?

Oder

Sollte das auf Anforderung von Edge erfolgen und überschreibe ich dafür eine Methode des ESS oder erwarte einen Event?

Oder

Muss ich die http-Abfrage und das Json-Resultat 1:1 mit einem Channel verknüpfen und Edge _holt_ sich einzelne Parameter nach eigenem Gutdünken.

Letzteres wäre elegant aber uneffizient weil alle Hardware-Parameter in einem Json-Paket von http-Server kommen.

Vielen Dank!  
Sebastian

---

<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:** [April 4, 2023, 11:59am UTC](https://community.openems.io/t/edge-module-programmierstil/1477/2 "2023-04-04T11:59:06Z")

</div>

Hallo Sebastian,

danke für deine Fragen. Ich hoffe, dass ich sie einigermaßen zufriedenstellend beantworten kann.

**Zu 1.)**  
Vor einigen Jahren hatte ich dazu mal die Grafik unter [Architecture scheme](https://openems.github.io/openems.io/openems/latest/edge/architecture.html#_architecture_scheme) erstellt. Hier ein neuer Versuch, um die Beziehung zwischen _Natures_ ( **gelb** ) und Implementierungen ( **blau** ), sowie zwischen _Controllern_, _Ess_, _Battery_ und _BatteryInverter_ zu erklären. Ich habe versucht mich an UML anzulehnen; ich hoffe das ist verständlich.

 ![Ess, Battery-Inverter, Battery](https://community.openems.io/uploads/default/original/1X/fc3b5c1c029f05a4e0ac86520ff9fc673cd2be97.png)

- Im Beispiel ist der _Ess.SMA.SunnyIsland_ ein vollständiges Stromspeichersystem (_ESS_), d.h. es kennt die Daten von der Batterie und vom Batteriewechselrichter. Diese Kombination findet sich überlichweise bei ‘traditionellen’ Heimspeichern - z. B. Kombination von einem SMA mit BYD Battery Box, etc. Hier kommuniziert OpenEMS nicht direkt mit der Batterie, sondern nur mit dem Wechselrichter.

- Bei den meisten Gewerbe- und Industriespeichern und einigen Heimspeichern nutzt OpenEMS eine generische ESS-Implementierung (_Ess.Generic.ManagedSymmetric_), die wiederum einen _ManagedSymmetricBatteryInverter_ und eine _Battery_ benötigt.

**Zu 2.)**

Hier gibt es leider noch keinen Standard, deshalb wird das aktuell noch je nach Implementierung unterschiedlich gelöst. Beispiele:

- HardyBarth EVCS: [openems/HardyBarthReadWorker.java at develop · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.evcs.hardybarth/src/io/openems/edge/evcs/hardybarth/HardyBarthReadWorker.java#L26)
- Discovergy SmartMeter: [openems/DiscovergyWorker.java at develop · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.meter.discovergy/src/io/openems/edge/meter/discovergy/DiscovergyWorker.java#L46)
- Shelly: [openems/ShellyPlugImpl.java at develop · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/blob/develop/io.openems.edge.io.shelly/src/io/openems/edge/io/shelly/shellyplug/ShellyPlugImpl.java#L116) (das ist ein sehr schlechtes Beispiel, weil die Abfragen nicht asynchron laufen und so bei Verbindungsausfall den Haupt-Cycle blockieren.

Ansätze zur Standardisierung gibt es hier:

- Implement Generic HTTP Worker: [Implement Generic HTTP Worker by nicoketzer · Pull Request #2098 · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/pull/2098)
- Add Timers: by Counting, by Cycles, by Time: [Add Timers: by Counting, by Cycles, by Time by DerStoecki · Pull Request #1754 · OpenEMS/openems · GitHub](https://github.com/OpenEMS/openems/pull/1754)

Gruß,  
Stefan

---

<div class="post-metadata">

**Author:** ![SBartel](https://community.openems.io/letter_avatar_proxy/v4/letter/s/2acd7d/32.png) [@SBartel](https://community.openems.io/u/SBartel)\
**Post date:** [April 4, 2023, 5:39pm UTC](https://community.openems.io/t/edge-module-programmierstil/1477/3 "2023-04-04T17:39:15Z")

</div>

Hallo Stefan

Das hast Du ja heute eine Menge zu tun gehabt durch mich. Danke für Deine Zeit.

Zu 1:  
Das Schaubild sieht lehrreich aus, das werde ich mir morgen in Ruhe anschauen.

Zu 2, der externen http-Quelle:  
Du hast das ja im anderen Post schon mit dem “BEFORE\_PROCESS\_IMAGE” event beantwortet.

Wenn dann das Code-FAQ von Euch eingerichtet wird 😉 , kann ich einen schön kurzen async Request als Beispiel vorstellen.

Schönen Abend  
Sebastian