MQTT mit Sparkplug B, Erfahrungen, Alternativen?

Jean-Luc

Level-1
Beiträge
19
Reaktionspunkte
0
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
Hallo,

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

Vg
NSN

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​
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
@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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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:


  1. Sparkplug würde die Variablennamen verwalten und ich müsste mich (hoffentlich) im SPS-Code nicht mit Zeichenkette für Variablen herumschlagen.
  2. 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
 
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.
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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
 
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
 
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

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 :p
 
Ich nutz die node-red-contrib-iiot-opcua.
Danke, probiere ich heute Abend aus. Bin mit node-red-contrib-opcua gestartet.

Anbindung zu Influx ist mit Node-RED eine Sache von ein paar Minuten.
Und dann von Influx zu Grafana :p
Genau!!! :D

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...
 
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
 
Zuviel Werbung?
-> Hier kostenlos registrieren
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.....?
 
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.
 
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 :D

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... :rolleyes: )

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
 
Zurück
Oben