TIA MQTT Tcp Verbindung bricht ab

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

Hallo zusammen,

TIA V18 Update 3
1212C DC/DC/DC V4.7.0
LMQTT_Client V2.1.1
--
Bei meiner Mqtt Funktion bricht immer wieder die Tcp Verbindung ab.. ich weiß nicht ob ich meiner Cpu zu viel zumute oder ob ich das Netzwerk so überlaste, dass die Tcp Funktionen der Steuerung nicht hinterherkommen

Aktuell sieht es so aus:
Alle Topics subscriben -> Auswerten -> Alle Topics unsubscriben -> Alle publish Nachrichten absetzen -> von vorne

Grund dahinter ist, dass ich einen physischen Quittierbutton auswerten muss, welcher seinen Zustand über Mqtt mitteilt. In ein paar Prozessschritten warte ich deswegen auf das true Signal zum weiterschalten..

Aktuell subscribe und unsubscribe ich so zu ca. 15 Topics.. finde ich noch überschaubar

Hatte schon mal jemand das Problem?

 

[Onkel_Karl]

warum subscribst und unsubscribst du denn dauernd? einmal einen topic abonniert kommt der doch immer bei Änderung

 

[DCDCDC]

Zuviel Werbung?
-> Hier kostenlos registrieren

warum subscribst und unsubscribst du denn dauernd? einmal einen topic abonniert kommt der doch immer bei Änderung

Das war mir neu

 

[DCDCDC]

Wie bekommt denn die Funktion mit, dass ich auf den subscribed Topics etwas ändert? Die Nachricht muss ja auch irgendwo landen?

 

[Blockmove]

Wie bekommt denn die Funktion mit, dass ich auf den subscribed Topics etwas ändert? Die Nachricht muss ja auch irgendwo landen?

Bei Subscribe sollte das automatisch passieren.
Der Client wird bei einer Zustandsänderung vom Broker informiert.
Ich hab's aber mit ner S7 noch nie getestet.

 

[Onkel_Karl]

Zuviel Werbung?
-> Hier kostenlos registrieren

Du subcribst einen MQTT-Topic (auch mit Wildcards) beim Broker und der sendet einen Sting (Array of Bytes) mit der Payload bei jeder Änderung an dem Topic. zusätzlich erhält du noch weitere Infos wie genauen Topicname, Länge etc. Den payload musst Du dann per Stringbehandlung auseinander nehmen (geht bestens mit SCL)

 

[Bsccb]

Am besten nach CPU Neustart zuerst allen Topics subscriben und anschließend die ankommenden Nachrichten im Baustein auswerten. Am Ausgang bekommst du doch die Info von welchem Topic die aktuelle Nachricht gekommen ist. Den ankommenden String/Bytes muss du selbst auseinander nehmen.
Ich hatte auch mal das Problem, dass die "Zyklusbelastung durch Kommunikation" zu niedrig eingestellt war.

 

[DerOnkel]

Ich hatte am Anfang ähnliche Probleme.

Dein aktueller Ansatz mit ständigem Subscriben und Unsubscriben ist wahrscheinlich der Hauptgrund für die TCP-Verbindungsabbrüche. Eine dauerhafte Subscription auf die relevanten Topics wird die Stabilität deutlich verbessern. Achte darauf, die MQTT-Verbindung offen zu halten und die empfangenen Nachrichten effizient in der Steuerung zu verarbeiten

Subscriben und Unsubscriben erzeugt viele zusätzliche Nachrichten auf dem MQTT-Broker und in der CPU. Es ist nötig, die Topics dauerhaft zu subscriben und nur die empfangenen Nachrichten gezielt auszuwerten.

 

[Blockmove]

Zuviel Werbung?
-> Hier kostenlos registrieren

Da ja MQTT meist mit JSON arbeitet, kannst du dir ja auch mal die LStream-Bibliothek anschauen.
https://cache.industry.siemens.com/..._1140079/v1/109781165_LStream_DOC_v1_6_de.pdf
Da sind ein paar JSON-Funktionen drin.

 

[DCDCDC]

Sorry fürs nicht mehr antworten.. unsubscribe ist wieder draussen..

Da ja MQTT meist mit JSON arbeitet, kannst du dir ja auch mal die LStream-Bibliothek anschauen.
https://cache.industry.siemens.com/..._1140079/v1/109781165_LStream_DOC_v1_6_de.pdf
Da sind ein paar JSON-Funktionen drin.

Das wäre tatsächlich etwas umständliche für mich, topics haben bei uns meistens noch ein sub topic welches die Messages als reinen String bereitstellt worüber ich direkt den Bytestream als String abfragen kann