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 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.
-
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
- Discovergy SmartMeter: openems/DiscovergyWorker.java at develop · OpenEMS/openems · GitHub
- Shelly: openems/ShellyPlugImpl.java at develop · OpenEMS/openems · GitHub (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
- Add Timers: by Counting, by Cycles, by Time: Add Timers: by Counting, by Cycles, by Time by DerStoecki · Pull Request #1754 · OpenEMS/openems · GitHub
Gruß,
Stefan