OpenEMS in der Praxis: MQTT-Implementierung von Consolinno

Neues von unserem OpenEMS-Mitglied Consolinno: Diesmal gibt’s einen Experten-Artikel zum Thema MQTT! Da der Artikel mit Fachwörtern gespickt ist, findet ihr bei Bedarf am Ende einige Begriffserklärungen (#).

Was heißt MQTT? 

Consolinno: Das „Message Queuing Telemetry Transport Protokoll“ (kurz MQTT) ist ein stark präsentes Protokoll im IoT-Bereich, das die Datenkommunikation zwischen verschiedenen Teilnehmern, z. B. den verbundenen Geräten, über einen #Broker ermöglicht. Daher war es uns wichtig, dieses Protokoll in OpenEMS umzusetzen.

Gibt es Unterschiede zum MQTT-Protokoll von Fenecon, das bereits in OpenEMS implementiert ist? 

Consolinno: Wie man in einem Update von Stefan Feilmeier nachlesen kann, unterstützt OpenEMS das MQTT-Protokoll 5. Es hat feste #Topics und eine fest implementierte Art und Weise, wann und wie es seine Daten pushed. Er erwähnte ebenfalls:  

„Be aware that this implementation only marks the start of MQTT support in OpenEMS. Therefor implementation details might change with future versions.“ 

Das bedeutet, MQTT mit der Version 5 kann genutzt werden. Dies stellt einen Vorteil gegenüber der Consolinno-Implementierung dar, welche lediglich die Version 3.1.1 (OASIS-Dokumentation) bzw. mit leichten Änderungen auch Version 3.1 des MQTT unterstützt. Die Nutzer*innen können aber mit Hilfe unserer Implementierung aussuchen, welche Daten an welche #Topics geschickt werden sollen. Das geschieht für jede Komponente individuell – also für die konfigurierbaren Module in OpenEMS (z.B. eine PV-Anlage oder auch virtuelle Komponenten). Pro Komponente können theoretisch mehrere #Payloads und #Topics konfiguriert werden.

Was ist mit eurer Implementierung noch möglich? 

Consolinno: Zusätzlich können Daten #subscribed werden. So könnten virtuelle Komponenten wie Temperatursensoren Daten erhalten, mit denen ein reales Energiesystem arbeitet. Außerdem können Commands #subscribed werden (das sind einfache Befehle, auf die eine Komponente reagieren kann). Die konkreten Befehle und die Reaktion darauf müssen jeweils implementiert werden. Weiter können Fahrpläne, die von einer KI erstellt werden und nach einem bestimmten Schema aufgebaut sind, abonniert werden. Fahrplancontroller können diese richtig zusammensetzen und auf die OpenEMS-Komponenten verteilen. Dadurch schaffen wir eine intelligente KI-Steuerung von Energiesystemen, was zukünftig im Klimaquartier Esslingen oder bei MAGGIE in Regensburg eingesetzt wird.  

Mit unserer Implementierung können Komponenten nicht nur über die ApacheFelix Web-Oberfläche für MQTT konfiguriert werden, sondern auch über ein JSON file oder sogar über REST. Diese Konfiguration kann im Nachhinein abgeändert werden. Der Nutzer wird dabei unterstützt, indem ihm angezeigt wird, welche Daten er von einer Komponente #publishen kann. Er kann auch angeben, in welchem Intervall eine Nachricht #gepublished und #subscribed werden soll.

Könnt ihr das wichtigste nochmal zusammenfassen? 

Consolinno: Unsere Implementierung unterstützt eine andere MQTT-Version (3.1.1 und mit leichter Abänderung 3.1). Alle Komponenten sind individuell konfigurierbar und in unterschiedlichen Zeitabständen können mehrere #Payloads an mehrere/ unterschiedliche Topics bei unterschiedlicher #Quality of Services verschickt werden.

Die Komponenten können auf bestimmte Kommandos individuell reagieren. Es werden also Nachrichten abonniert und Fahrpläne entgegen genommen, welche eine KI-optimierte Steuerung, etwa von Energieerzeugern, ermöglicht.  

Als Verbesserungen stehen das Speichern einer geupdateten Konfiguration und die Unterstützung von MQTT v.5 an. Die Implementierung von Fenecon ermöglicht es, über MQTT v.5 alle Daten des OpenEMS an festgeschriebene #Topics zu erhalten, was den Konfigurationsaufwand minimiert. Doch wie bereits Stefan Feilmeier sagte, ist die Implementierung von Fenecon noch am Anfang.

Begriffserklärungen: 

#Broker:  
Die Cloud/der Server, der die ankommenden Daten von #Publishern entgegennimmt und verwaltet bzw. dafür zuständig ist, Abonnenten/ #Subscribern die Topics, die sie abonniert haben, zukommen zu lassen. Der Broker ist also die Brücke der Kommunikation zwischen #Publishern und #Subscribern: Er ist das „Gebäude“, in dem sich „Sprecher“ und „Zuhörer“ bewegen; die Sprecher (#Publisher) sagen ihren Inhalt (#Payload) in einem Raum (#Topic), die Zuhörer (#Subscriber) bewegen sich in dem Gebäude und suchen sich Räume (#Topics) aus, in denen sie zuhören möchten.

#Payload:  
Nachrichteninhalt. 

#Publish/#Subscribe:  
Nachrichten veröffentlichen (publish)/abonnieren (subscribe) bzw. erhalten. 

#QoS/#Quality of Service:  
Art und Weise, mit welcher Garantie eine Nachricht beim Broker ankommt. 

#Topic:  
Eine Art URI oder URL (quasi etwas wie https://openems.io/), die innerhalb von MQTT eine eindeutige Adresse darstellt.