Hallo, in diesem WAGO-Tutorial zeigen wir, wie man im WAGO Load Management Daten über MQTT bereitstellt. Wie schon in den bisherigen Tutorials zum WAGO Load Management, arbeiten wir auch hier wieder mit einem CC100 auf dem das WAGO Load Management installiert und lizensiert ist und einem PFC 200, auf dem eine Ladepark Simulation als CODESYS 3.5 Visualisierung läuft. Für eine MQTT Verbindung benötigt man zudem, einen übers Netzwerk erreichbaren MQTT Broker. In unserem Fall läuft dieser auf einem Edge Device in einem Docker Container. Die Funktionsweise einer MQTT Verbindung ist recht einfach und im Betrieb auch durchaus robust. Im MQTT Broker werden alle Kommunikationseinstellung definiert. Es lassen sich auch passwortgeschützte und verschlüsselte Verbindungen aufbauen. In unserem Fall belassen wir alles bei den Standardeinstellungen. Das WAGO Load Management kann als Publisher Daten bereitstellen. Das heißt, das Load Management sendet Daten an den Broker, in Form eines JSON Strings. Möchte ein anderes Gerät Daten aus diesem String haben, kann es sich beim Broker als Subscriber anmelden und erhält dann jeden neu gesendeten JSON String. Da in vielen Fällen MQTT Geräte sowohl Daten senden als auch empfangen können verwendet man in diesem Zusammenhang auch oft die Bezeichnung Client. In diesem Video konzentrieren wir uns auf die Verbindung zwischen dem WAGO Load Management und dem Broker, Also wie das WAGO Load Management, als Publisher Daten an den Broker sendet. Um zu sehen ob und welche Daten beim Broker ankommen, verwenden wir das kostenlose Softwaretool MQTT Explorer. Die Einstellungen für die MQTT Verbindung finden wir im Menü Konfiguration und dann Schnittstellen. In diesem Bereich finden wir dann alle Einstellungen für die MQTT Verbindung. Zunächst müssen wir MQTT aktivieren. Dann geben wir die IP Adresse und den Port des Brokers an. Der Standard Port ist 1883, bei verschlüsselter Kommunikation wird der Port 8883 verwendet. Falls im Broker ein Passwortschutz aktiv ist, muss hier der entsprechende Benutzername und das Passwort eingetragen werden. Darunter geben wir das Sendeintervall in Sekunden an. Dann geben wir die IP Adresse und den Port des Brokers an. Falls im Broker ein Passwortschutz aktiv ist, muss hier der entsprechende Benutzername und das Passwort eingetragen werden. Darunter geben wir das Sendeintervall in Sekunden an. In diesem Fall wird jetzt alle 2 Sekunden ein neuer JSON String an den Broker gesendet. Bei Quality of Service können wir eine von drei verschiedenen Kommunikations Qualitätsstufen auswählen. „Null“ ist die geringste Stufe die sich am leichtesten mit „Fire and Forgett“ beschreiben lässt. Der Publisher sendet also einfach nach Ablauf der Zykluszeit den JSON String womit für ihn der Fall erledigt ist und die Zykluszeit erneut startet. Bei einem Quality of Service von 1 fordert der Publisher bei jedem Versand eine Eingangsbestätigung beim Broker an, kommt keine Eingangsbestätigung, sendet der Publisher das Telegramm nochmal, solange bis er eine Eingangsbestätigung erhält. Daraus ergibt sich, dass das Telegram auch wirklich ankommt es aber zu Telegramm Doubletten kommen kann, wenn das Antwort Telegramm verloren geht oder sich verzögert. Bei Quality of Service 2 wird ein sogenannter vierfach Handshake durchgeführt, womit sichergestellt ist, dass es genau ein Telegramm gibt, das sicher angekommen ist. Das erhöht natürlich erheblich die Netzwerklast und wird daher nur bei kritischen Anwendungen genutzt, bei denen es keine Doubletten geben darf, wie z.B. bei Finanz Transaktionen. Der Quality of Service wird ausschließlich in den Clients konfiguriert, der Broker kann alle Qualitätsstufen und reagiert dann entsprechend. Wichtig ist noch zu wissen, dass bei unterschiedlich eingestellten Quality of Service Leveln bei Publisher und Subscriber, die MQTT-Spezifikationen vorsehen, dass das niedrigste Quality of Service -Level für die gesamte Kommunikationskette verwendet wird. Ist beim Broker eine TLS-Verschlüsselung konfiguriert oder werden Brokerzertifikate verwendet, kann das hier entsprechend für den Client aktiviert werden. Sind die Ladesäulen über OCPP angebunden und ist eine Benutzerverwaltung aktiv, kann die am Ladepunkt verwendete RFID Nummer auch mit im JSON String übertragen werden. Die Client ID ist insbesondere relevant, wenn wir im Broker eine persistente Sitzungssteuerung aktiviert haben. Erst durch die Client ID kann der Broker, nach einer Verbindungsunterbrechung, den erneut angemeldeten Client dem „alten“ Datenstand wieder zuordnen. Jeder erfasste Wert wird im JSON String als sogenanntes Topic hinterlegt. All Topics werden dann unter einem Haupt Topic zusammengefasst. Den Namen des Haupt Topics können wir hier vergeben. Loggen wir uns mit dem MQTT Explorer auf den Broker ein werden uns alle Datensätze angezeigt, die an ihn gesendet werden. Auch unser angelegtes Haupt Topic WALM wird aufgelistet. Klappen wir den Baum einmal auf werden uns zwei Topics angezeigt die alle zwei Sekunden neu empfangen werden. Doch irgendwie haben wir da andere und vor allem mehr Daten erwartet. Das liegt daran, dass es in den verfügbaren Daten noch keine Änderung gab. Wechseln wir in die Simulation und erhöhen den Gebäudeverbrauch, wird uns im MQTT Explorer jetzt auch das Topic mit dem Gebäudeverbrauch und das Topic Gesamtleistungsaufnahme angezeigt, da es bei beiden Werten eine Wertänderung gab. Steigt die PV Produktion wird auch hierfür ein weiteres Topic übertragen. Kommt ein Ladevorgang dazu, erscheint ein weiteres Topic, die Ladeleistung, die sich mit jedem weiteren Fahrzeug erhöht. Dieses Verhalten, dass die Topics erst bei Wertänderung gesendet werden, hat man dann auch nach einem Controller Neustart oder wenn sich ein weiterer Client anmeldet. Damit bei Initialisierung der Verbindung, alle verfügbaren Topics mit übertragen werden kann man hier das Häckchen bei „Aufbewahrte Nachrichten“ setzten, dann werden die Werte in den Retain Speicher gespeichert und sind auch nach einem Neustart verfügbar. Einmal speichern und wir starten den Controller neu …und wenn alles wieder hochgefahren ist, empfangen wir – auf einmal jede Menge Daten… Das sind jetzt alle über MQTT verfügbare Topics des WAGO Load Management. Durch das gesetzt Retain Häckchen hat das WAGO Load Management alle verfügbaren Werte in den Retainspeicher geschrieben und dann bei Initialisierung der Verbindung einmal gesendet. Der hintere Wert „tst“ ist der Zeitstempel im Format UNIX Zeit. Somit können wir jetzt einfach mit einem weitern Client den Datensatz abholen, den JSON String auswerten und uns die benötigten Werte aus dem JSON String extrahieren. Dazu gibt es unzählige Möglichkeiten und Geräte mit denen das möglich ist. Wie man das mit einem WAGO Controller und CODESYS 3.5 macht zeigen wir in einem weiteren Tutorial. Damit sind wir am Ende vom Tutorial wie man im WAGO Load Management Daten über MQTT bereitstellt. Hinterlasst uns gerne einen Daumen hoch, wenn euch das Video geholfen hat, abonniert den Kanal und meldet euch im WAGO Support Center wenn ihr noch Fragen habt.