# MQTT mit Sparkplug B, Erfahrungen, Alternativen?



## Jean-Luc (29 Juli 2019)

Guten Abend,

ich bin gerade dabei meine Haussteuerung, die bisher mit einem Beckhoff CX8090 unter TC2 lief, auf Wago und e!Cockpit zu migrieren (und bei der Gelegenheit den Code etwas aufzuräumen). Was mich "damals" auf der Messe in Nürnberg von e!Cockpit/Wago so begeisterte war der abstrahierte Umgang mit externen Komponenten, im konkreten Fall: Modbus-Anbindung. Man legt einen Modbus-Slave an, stellt die Hardwareparameter ein, konfiguriert die Variable in der Modbus-Slave-Komponente und das Programm für den Master in der PLC besteht nur noch aus einer einzigen Zeile. Ich habe heute meine Elsner P03/3 Wetterstation so angebunden und kann nur sagen: Klasse. Genau so gefällt mir das. Das Hauptprogramm für den Prototyp hatte genau eine Zeile.

Zur Sache: Zur Anbindung weiterer Komponenten (Datalogging, Sprachsteuerung, Metaeventsteuerung durch Node Red) erscheint mir eine Kommunikation über MQTT sehr sinnvoll. Ich war sehr positiv überrascht, dass inzwischen - der Messbesuch war Ende 2016 - MQTT als Protokoll unterstützt wird. Wenn man allerdings eine große Liste von Variablen aktuell halten will und nicht geschwätzig einmal pro Sekunde den kompletten Istwertbestand übertragen will, wird es ziemlich lästig mit dem Code in der SPS, vermute ich. Nun habe ich gesehen, dass es hier ein Plugin für Sparkplug B (Apache Tahu) gibt, das die Kommunikation (potentiell) genauso einfach macht wie die oben genannte Modbus-Anbindung. Meine Fragen: 



Hat von euch jemand Erfahrung mit dem Plugin?
Setzt es jemand für die Hausautomatisierung ein?
Nutzt es jemand mit einem simplen Mosquito MQTT Broker?

Leider wird das Ganze nur auf der PFC200 Serie unterstützt, und ich habe natürlich einen PFC100...  Könnte man alternativ ein eigenes Programm auf dem PFC100 laufen lassen, das Einsicht (also lesend) in die Variablen der PLC hätte und diese ohne "Echtzeitstress" verarbeiten und ggf. in die Queue werfen könnte?

Viele Grüße,
Jean-Luc


----------



## NeuerSIMATICNutzer (30 Juli 2019)

Hallo,

schau doch mal auf https://github.com/WAGO/pfc-howtos ob du hier was findest.

Vg
NSN


----------



## Blockmove (30 Juli 2019)

Auf der PLC überzeugt mich MQTT nicht wirklich.
OPC-UA ist deutlich einfacher auf der Wago.
Wenn ich MQTT brauche, dann nehm ich Node RED als Gateway


----------



## Jean-Luc (30 Juli 2019)

NeuerSIMATICNutzer schrieb:


> Hallo,
> 
> schau doch mal auf https://github.com/WAGO/pfc-howtos ob du hier was findest.
> 
> ...



Danke! Sehr interessant, dieser K-Bus Slave. Allerdings kann man es nicht dem "PLC_PRG" zusammen betreiben:



> *CAUTION*
> Take care that there is no other ADI/DAL-Application(like  PLC-Runtime) active while using this application. Because  ADI/DAL-Interface offer a single process support only!
> ​


Man würde die PLC dann auf das reine I/O Abbild reduzieren und müsste sich um jedes Bit selbst kümmern. Nicht so verlockend. Lesender Zugriff auf eine definierte Struktur wäre ganz nützlich. Aber die Reise geht wahrscheinlich in eine andere Richtung. (siehe unten)

Viele Grüße,
Jean-Luc​


----------



## uzi10 (30 Juli 2019)

was kann Sparkplug besser? Das kostet ja extra Lizenzgebühren oder?
Wie macht ihr das weiterleiten über Node red! Habts ihr da eine Beschreibung bzw ein Demoprogramm


----------



## Jean-Luc (30 Juli 2019)

Blockmove schrieb:


> Auf der PLC überzeugt mich MQTT nicht wirklich.
> OPC-UA ist deutlich einfacher auf der Wago.
> Wenn ich MQTT brauche, dann nehm ich Node RED als Gateway



Ja, klingt sinnvoll. Die Kommunikation zu Node RED dann über Modbus? Das Protokoll erschien mir so schwerfällig und es müssten dann alle Daten zyklisch immer transferiert werden (statt nur die sich ändernden Werte zu übertragen). Aber in der Umsetzung wahrscheinlich am besten unterstützt. Ich vermute mal, dass man einen Modbus-Master in e!Cockpit genaus elegant hinbekommen wird wie den Slave. Die Richtung werde ich weiterverfolgen. Danke!

Ich habe gerade gesehen, dass es sogar einen InfluxDB-Connector für Node RED gibt. Perfekt, dann steht die Architektur so langsam:

PLC als Modbus-Slave
Node RED als  Gateway für MQTT, Modbus, InfluxDB
Grafana zur Visualisierung der Messdaten aus der InfluxDB
Spracherkennung z.B. über Raspi und Snips mit MQTT Anbindung
MQTT Broker, Node RED, Grafana, ggf. OpenHAB o.ä. sollen in Docker Containern im NAS (Synology, x86) laufen

Bleibt nur noch zu klären, wo ich die Lüftung (RS-232, Comfoair 350) und die Wärmepumpe (Ethernet, Alpha Innotec) dranhänge, bzw. ob es direkt in Node RED geht oder ein weiteres Gateway (z.B. OpenHab) erforderlich ist. 

Viele Grüße,
Jean-Luc


----------



## Blockmove (30 Juli 2019)

@Jean-Luc

Die Modbus-Implementierung von e!Cockpit ist unflexibler als OPC-UA.
Daher nutze ich OPC UA unter Node RED.
Ich hab hier auf meinen Linux-Server folgende Docker-Container laufen:

Node RED
Influenz-DB
Grafana
Sonos API
TVHeadend
pihole
...

Mosquitto / MQTT  benötige ich aktuell nicht. Läuft aber auch problemlos.

Gruß 
Blockmove


----------



## GLT (30 Juli 2019)

Blockmove schrieb:


> Wenn ich MQTT brauche, dann nehm ich Node RED als Gateway


Auf welcher HW lässt Du das laufen?


----------



## Jean-Luc (30 Juli 2019)

uzi10 schrieb:


> was kann Sparkplug besser? Das kostet ja extra Lizenzgebühren oder?
> Wie macht ihr das weiterleiten über Node red! Habts ihr da eine Beschreibung bzw ein Demoprogramm



Nach meinem Verständnis folgendes:



Sparkplug würde die Variablennamen verwalten und ich müsste mich (hoffentlich) im SPS-Code nicht mit Zeichenkette für Variablen herumschlagen.
Es würde nur Übertragungen gemacht, wenn ich ein Variablenwert ändert.

Wenn es elegant über die Bühne gegangen wäre und es mir einen Arbeitstag erspart hätte, wäre ich bereit gewesen in den sauren Lizenzapfel zu beißen. Sauer deshalb, weil Lizenzen in meinem Alltag eine permanente Quelle von Ärger sind. Die Modbus Integration in e!Cockpit fand ich schon ganz gelungen. Wenn OPC-UA noch besser flutschen soll, wäre das der Kandidat für mich.

Viele Grüße,
Jean-Luc


----------



## Blockmove (31 Juli 2019)

GLT schrieb:


> Auf welcher HW lässt Du das laufen?



Node RED läuft auf div. Hardware.
Vom Raspi über div. IoT-Gateway bis hin zur Cloud.
Egal ob Windows oder Linux.
Hängt einfach vom Anwendungsfall ab.

Gruß
Blockmove


----------



## GLT (31 Juli 2019)

Das war schon klar - aber einen Raspi in Produktivumgebung?
Deshalb war ja gezielt die Frage, ob Du eine spezielle HW für Schaltschrank in petto hast.


----------



## Blockmove (31 Juli 2019)

GLT schrieb:


> Das war schon klar - aber einen Raspi in Produktivumgebung?
> Deshalb war ja gezielt die Frage, ob Du eine spezielle HW für Schaltschrank in petto hast.



Für den Schaltschrank ist z.B. ein Siemens IoT 2040 gut und günstig.
Das IoT-Gateway von Insevis macht auch nen guten Eindruck.
Und wenn's etwas leistungsfähiger sein muss, dann eben ein Hutschienen-PC.

Gruß
Blockmove


----------



## Jean-Luc (13 August 2019)

Hallo Blockmove,

habe mir inzwischen OPC UA etwas anschauen können und bin sehr positiv überrascht. Einfach die Variable freigeben und mit dem UA Browser die "URLs" rauspicken. Genial! Vielen Dank für den Hinweis. Das war genau das, was ich von Sparkplug B erhofft hatte, nur, dass es ohne Lizenz geht (und defaultmäßig auch schon aktiviert ist...).

Die erste Verbinung zu Node Red habe ich auch herstellen können. Welche Nodes verwendest Du? node-red-contrib-opcua oder node-red-contrib-iiot-opcua? Fehlt noch die Anbindung an InfluxDB...

Viele Grüße und nochmals vielen Dank!
Jean-Luc


----------



## Blockmove (13 August 2019)

Jean-Luc schrieb:


> Hallo Blockmove,
> 
> habe mir inzwischen OPC UA etwas anschauen können und bin sehr positiv überrascht. Einfach die Variable freigeben und mit dem UA Browser die "URLs" rauspicken. Genial! Vielen Dank für den Hinweis. Das war genau das, was ich von Sparkplug B erhofft hatte, nur, dass es ohne Lizenz geht (und defaultmäßig auch schon aktiviert ist...).
> 
> ...



Ich nutz die node-red-contrib-iiot-opcua.
Anbindung zu Influx ist mit Node-RED eine Sache von ein paar Minuten.
Und dann von Influx zu Grafana


----------



## uzi10 (13 August 2019)

Blockmove schrieb:


> Ich nutz die node-red-contrib-iiot-opcua.
> Anbindung zu Influx ist mit Node-RED eine Sache von ein paar Minuten.
> Und dann von Influx zu Grafana



läuft das direkt als docker am pfc?


----------



## Jean-Luc (13 August 2019)

Blockmove schrieb:


> Ich nutz die node-red-contrib-iiot-opcua.


Danke, probiere ich heute Abend aus. Bin mit node-red-contrib-opcua gestartet.



Blockmove schrieb:


> Anbindung zu Influx ist mit Node-RED eine Sache von ein paar Minuten.
> Und dann von Influx zu Grafana


Genau!!! 



uzi10 schrieb:


> läuft das direkt als docker am pfc?


Wurde zwar nicht gefragt, habe aber trotzdem eine Meinung:  
Node Red könnte man auf  'nem PFC laufen lassen, und wenn keine weiteren, schwergewichtigen Komponenten eingebunden werden, wäre es einen Gedanken wert, sofern es nicht eine PFC100 ist, die schon aufgrund des SPS-Programms ordentlich unter Last ist. Im Falle einer Datenbank als zusätzlicher Komponente, wie hier mit InfluxDB, würde ich es auf keinen Fall tun. (Ich habe angefangen die Docker Container auf meinem Synology NAS zu nutzen, und bin ganz zufrieden damit, auch wenn ich mir bessere übergreifende Konfigurationsmöglichkeiten wünschen würde à la docker-compose.)

Apropos Performance: Wie clever ist OPC UA eigentlich? Wenn ich mich als Client für eine Variable interessiere, dann kann das technisch über Polling oder Callback realisiert werden. So ein OPC-Subscribe klingt ja nach Callback. Stimmt das? (Ansonsten würde ich heute abend mal den Datenverkehr mitschreiben und nachgucken.) So ein 100ms Polling wäre schon nicht so ganz optimal... Im Red Node wird immer brav nur dann ein neuer Wert ausgegeben (node-red-contrib-opcua), wenn er sich ändert. Das heißt aber nicht, dass im Hintergrund nicht wild gepollt wird...

Viele Grüße,
Jean-Luc

PS: Wir sind ein bisschen vom Thema abgekommen. Vielleicht mache ich noch einen OPC UA Thread auf...


----------



## Blockmove (13 August 2019)

Jean-Luc schrieb:


> Wurde zwar nicht gefragt, habe aber trotzdem eine Meinung:
> Node Red könnte man auf  'nem PFC laufen lassen, und wenn keine weiteren, schwergewichtigen Komponenten eingebunden werden, wäre es einen Gedanken wert, sofern es nicht eine PFC100 ist, die schon aufgrund des SPS-Programms ordentlich unter Last ist. Im Falle einer Datenbank als zusätzlicher Komponente, wie hier mit InfluxDB, würde ich es auf keinen Fall tun. (Ich habe angefangen die Docker Container auf meinem Synology NAS zu nutzen, und bin ganz zufrieden damit, auch wenn ich mir bessere übergreifende Konfigurationsmöglichkeiten wünschen würde à la docker-compose.)



Das Schöne an Node-RED und den meisten Erweiterungen ist dass sie auf den verschiedensten Plattformen laufen.
Man kann das Ganze dann eben vom Einsatzzweck abhängig machen.

Die Kombination mit Docker ist klasse. 
Du kannst dir mal Portainer anschauen. Könnte evtl. auf Synology funktionieren und damit hast du dann (fast) docker-compose


----------



## uzi10 (13 August 2019)

Also schickt ihr die Daten vom PFC zur Synology(hätte auch eine) und die schreibt per Node Red die Daten in die Influx dB! Wie schickt ihr die Daten? Per Modbus, oder per OPC.....?


----------



## Blockmove (13 August 2019)

uzi10 schrieb:


> Also schickt ihr die Daten vom PFC zur Synology(hätte auch eine) und die schreibt per Node Red die Daten in die Influx dB! Wie schickt ihr die Daten? Per Modbus, oder per OPC.....?



Egal ob OPC UA, Modbus, S7, CSV, Rest, ... mit Node RED funktioniert eigentlich alles.
Manchmal brauchst du halt ein paar Zeilen Javascript zum Wandeln und Anpassen.


----------



## Jean-Luc (14 August 2019)

Blockmove schrieb:


> Egal ob OPC UA, Modbus, S7, CSV, Rest, ... mit Node RED funktioniert eigentlich alles.



Klar, ein Aspekt ist aber auch wie effizient es im "Maschinenraum" unterhalb der Node Red Oberfläche zugeht. Wenn ich bei Modbus eine Auflösung von 1s haben will, muss ich mit 1Hz pollen. Effizient wäre es, wenn ich als Node Red Node ein Subscribe o.ä. absetze und im Moment der Änderung informiert werde. Bei der SPS wäre das dann so grob eine zeitliche Auflösung entsprechend der Zykluszeit.

Ich habe gestern 'mal mitgeschrieben, was bei der OPC UA Kommunikation zwischen Node Red und der SPS so über die Leitung geht: Alle drei, vier Sekunden werden da drei, vier Pakete ausgetauscht. Ich hatte dummerweise aber auch einen sich sehr langsam ändernden Parameter (Temperatur, Wetterstation) verwendet. Als Node Red Lib hatte ich die node-red-contrib-opcua verwendet und mit Subscribe angesteuert. Was ich sehr interessant fand, war die Tatsache, dass die SPS immer der Initiator der Paketsequenz war. => Kein Polling  

Die Analyse werde ich bei Gelegenheit noch etwas verbessern indem ich ein sich schneller änderndes Signal verwende und ggf. auch 'mal mit node-red-contrib-iiot-opcua experimentiere. (Eigentlich könnte ich auch über meinen Schatten springen und mich bei opcua registrieren und mir die Protokolldefinitionen runterladen, statt im Nebel zu tappen...  )

Natürlich kann ich das alles auch mit CSV machen. Wir aber schwierig eine zeitliche Auflösung im Subsekundenbereich hinzubekommen. Für eine zeitlich gut aufgelöste Influx-Befüllung wäre es eher nix.

Gruß,
Jean-Luc


----------



## Blockmove (14 August 2019)

Jean-Luc schrieb:


> Klar, ein Aspekt ist aber auch wie effizient es im "Maschinenraum" unterhalb der Node Red Oberfläche zugeht.



Das Thema hast du eigentlich bei jeder Kommunikation / jedem Protokoll.
Eigentlich ist die Diskussion ganz interessant. Vor Jahren war Polling gar kein Problem 
Netzwerkbandbreite war locker ausreichend und die paar Daten von und zur Steuerung ... Pille Palle 
Jetzt bei Industrie 4.0 und IoT sieht es auf einmal wieder ganz anders aus. Da kommen OPC UA Methoden und Subscriptions und was weis ich noch alles. Auf der anderen Seite streamt man aber Netflix oder Youtube mit 4K UHD.


----------



## Jean-Luc (15 August 2019)

Blockmove schrieb:


> Vor Jahren war Polling gar kein Problem
> Netzwerkbandbreite war locker ausreichend und die paar Daten von und zur Steuerung ... Pille Palle
> Jetzt bei Industrie 4.0 und IoT sieht es auf einmal wieder ganz anders aus. Da kommen OPC UA Methoden und Subscriptions und was weis ich noch alles. Auf der anderen Seite streamt man aber Netflix oder Youtube mit 4K UHD.



Ja, genau, und weil man eben nebenher noch Netflix guckt, reicht die Bandbreite nicht mehr für's Polling. 

Mal im Ernst, Polling hat eine inhärente Beschränkung: Entweder ich polle häufig und habe eine hohe zeitliche Auflösung, oder ich benötige weniger Bandbreite auf Kosten der zeitlichen Auflösung. Schön, wenn die Anforderungen an das Projekt so sind, dass es keine Beschränkung dadurch gibt. Noch schöner, dass es durch das Publish/Subscribe-Pattern einen eleganteren Weg gibt, der inzwischen Mainstream geworden zu sein scheint*. 

So, mal schauen, ob ich heute das OPC UA/Influx Gateway prototypisch hinbekomme... 

Viele Grüße,
Jean-Luc

*) PS: , für die man noch nicht einmal Sparkplug B einsetzen muss, um den (nicht mehr vorhandenen) Bogen zum initialen Thema zu schlagen.


----------

