MQTT mit Sparkplug B, Erfahrungen, Alternativen?

Zuviel Werbung?
-> Hier kostenlos registrieren
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 :p
Netzwerkbandbreite war locker ausreichend und die paar Daten von und zur Steuerung ... Pille Palle :p
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.
 
Vor Jahren war Polling gar kein Problem :p
Netzwerkbandbreite war locker ausreichend und die paar Daten von und zur Steuerung ... Pille Palle :p
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. :p

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. :p
 
Zuletzt bearbeitet:
Zurück
Oben