MQTT-Subscribe (Trigger)

MQTT-Subscribe ist der MQTT-Trigger zum Überwachen konfigurierter Topics. Bei eingehenden MQTT-Nachrichten löst er den nachfolgenden Transfer aus. Der empfangene Nachrichteninhalt steht dem Flow anschließend zur Weiterverarbeitung zur Verfügung.

In der Eigenschaftsmaske legen Sie fest, über welche Brokeranbindung die Subscription erfolgt und wie empfangene Nachrichten interpretiert werden:

Dasselbe Topic darf in mehreren Flows überwacht werden. Jeder dieser Flows wird je eingehender Nachricht genau einmal ausgelöst; das ist der vorgesehene Fall und keine Doppelauslösung.

Mit „Warte auf Transfer“ lösen mehrere Flows am selben Topic gar nicht mehr aus

Treffen diese drei Bedingungen zusammen, wird kein Transfer mehr ausgelöst:

• Mehrere Flows überwachen dasselbe Topic über dieselbe Brokeranbindung.
• Bei mindestens einem dieser Trigger ist „Warte auf Transfer“ eingeschaltet, auch wenn der Wert aus der Plug-in-Einstellung übernommen wird.
• Die Nachricht trifft mit einer Servicequalität über 0 ein.

Das ist kein Randfall: Sobald die drei Bedingungen zusammentreffen, gilt es für jede Nachricht auf diesem Topic und unabhängig vom eingesetzten Broker. Alle beteiligten Trigger wechseln in den Zustand Konfigurationsfehler und melden das betroffene Topic.

Lösen Sie eine der drei Bedingungen auf: Schalten Sie „Warte auf Transfer“ bei allen Triggern dieses Topics aus, oder überwachen Sie das Topic nur noch in einem Flow, oder stellen Sie die Servicequalität auf 0. Ein einzelner wartender Trigger genügt, um den Fehlerzustand für alle herbeizuführen.

Aktivieren Sie anschließend die geänderte Projektierung; erst damit verlassen die Trigger den Fehlerzustand. Nachrichten, die währenddessen eingegangen sind, werden nicht nachgeholt.

Wann eine Nachricht mehrfach ankommt

Mehrfach ausgelöst wird ein Flow nur, wenn ihn dieselbe Nachricht mehrfach erreicht. Dass mehrere Flows dasselbe Topic überwachen, genügt dafür nicht. Ursache ist immer eine mehrfache Zustellung:

• Überlappende Subscriptions. Ein Flow auf anlage/# und ein zweiter auf anlage/1/temp werden beim Broker als zwei getrennte Subscriptions angemeldet; der OPC Router fasst überlappende Muster nicht zusammen. Ob der Broker eine passende Nachricht daraufhin einmal oder je passender Subscription einmal zustellt, lässt die MQTT-Spezifikation offen, in MQTT 3.1.1 wie in MQTT 5. Das hängt also vom eingesetzten Broker ab und ist vor der Inbetriebnahme zu prüfen.
• Mehrere Brokeranbindungen zum selben Broker, die dasselbe Topic abonnieren: Jede Anbindung erhält die Nachricht, und jeder daran hängende Flow löst aus.
• Aktive MQTT-Datenspeicherung. Deren Topic-Muster werden zusätzlich abonniert. Da werkseitig das Muster # eingetragen ist, überlappt es mit jedem Trigger-Topic; es gilt dann der erste Punkt. Beschränken Sie die Muster auf die tatsächlich benötigten Topics.

Läuft die Brokeranbindung mit MQTT 5 und liefert der Broker die Subscription-Kennung mit, ordnet der OPC Router jede Zustellung ihrer Subscription zu; ein Flow wird dann auch bei überlappenden Mustern nur einmal ausgelöst. Unter MQTT 3.1.1 fehlt diese Zuordnung, und bei aktiver MQTT-Datenspeicherung wird sie nicht ausgewertet.

Gegen mehrfache Zustellung hilft die Nachrichtendeduplizierung in der Brokeranbindung. Beachten Sie ihre zwei Grenzen: Sie wirkt je Brokeranbindung und hilft daher nicht gegen den zweiten Punkt, und da der Inhalt in den Vergleich eingeht, verwirft sie auch echte Wiederholungen mit gleichem Inhalt. Deshalb ist sie werkseitig ausgeschaltet.

Unabhängig davon darf ein Broker bei Servicequalität 1 dieselbe Nachricht wiederholt zustellen. Flows an solchen Triggern müssen eine mehrfache Ausführung vertragen; wo das nicht möglich ist, verwenden Sie Servicequalität 2.

Die einzelnen Eigenschaften sind:

Eigenschaft	Beschreibung
Brokeranbindung	Wählen Sie die konfigurierte MQTT-Brokeranbindung aus, über die das Topic abonniert werden soll.
Topic	Name des zu überwachenden Topics. Je nach Broker können auch Topic-Muster mit Wildcards verwendet werden. Über Start Browsing kann zusätzlich eine Topic-Auswahl ausgehend von der aktuellen Brokerverbindung angestoßen werden.
Servicequalität	Legt den Quality-of-Service-Wert für die Subscription fest. 0 verarbeitet Nachrichten ohne zusätzliche Bestätigung, 1 mit einfacher Empfangsbestätigung und 2 mit vollständiger Zustellabsicherung. Mit Plug-in-Einstellung verwenden wird der im MQTT-Plug-in hinterlegte Standardwert übernommen.
Warte auf Transfer	Legt fest, ob der Trigger auf die Ausführung des nachfolgenden Transfers wartet, bevor die Nachricht intern als verarbeitet gilt.
Payload-Datentyp	Legt fest, ob der empfangene Payload als Byte Array oder als String an den Flow übergeben wird.
Payload-Kodierung	Legt die Zeichencodierung fest, mit der String-Payloads interpretiert werden.
Nullwerte	Legt fest, wie empfangene Nullwerte behandelt werden. Im Screenshot ist beispielhaft Nullwerte verbieten ausgewählt.

hinweis

Im Reiter Allgemein sind nicht immer alle Eigenschaften verfügbar. Welche zusätzlichen Optionen angezeigt werden, hängt vom gewählten MQTT-Profil der ausgewählten Brokeranbindung ab.

Eigenschaft	Beschreibung
Antwort-Topic- und Korrelationsdaten-Ausgabe aktivieren	Aktiviert zusätzliche MQTT-5-Angaben für Antwort-Topic und Korrelationsdaten in der Triggerausgabe. Diese Option ist relevant, wenn eingehende Nachrichten nach dem Request-Response-Muster verarbeitet und die zugehörigen MQTT-5-Informationen im Flow weiterverwendet werden sollen.

---

Auslöseverhalten

Das Diagramm zeigt die ereignisgetriebene Auslösung je eingehender Nachricht; mit „Warte auf Transfer“ werden dichte Folgen nacheinander abgearbeitet.

Zusammenspiel mit dem Broker

Wie diese Darstellung zu lesen ist, erklärt der Abschnitt Sequenzdiagramme.

Der MQTT-Subscribe-Trigger löst je eingehender Nachricht einen Transfer aus. Die Einstellung „Warte auf Transfer“ ändert dabei nicht, ob der Router auf den Transfer wartet, sondern wann die Nachricht gegenüber dem Broker quittiert wird: ohne die Option quittiert die MQTT-Clientbibliothek, sobald der Trigger die Nachricht geprüft und den Transfer eingereiht hat, mit der Option wird die Quittung zurückgehalten und erst nach dem Ende des Transfers gesendet. Der Empfangsweg des Routers blockiert in keinem der beiden Fälle; weitere Nachrichten werden weiterhin angenommen und reihen sich in die Warteschlange des Triggers ein. Beachten Sie, dass die Quittung lediglich meldet, dass der Router die Nachricht abgeschlossen hat - ob der Transfer erfolgreich war, erfährt der Broker nicht.

Der Schalter ist dreiwertig. „Standard“ übernimmt die Einstellung der Anbindung, „Aktiv“ und „Inaktiv“ überstimmen sie für diesen einen Trigger. Die beiden Diagramme zeigen das Ergebnis der Auflösung, nicht die Stellung des Schalters.

Warte auf Transfer: aus

Die Quittung an den Broker steht vor dem Transferergebnis, aber hinter der Übergabe: der Trigger prüft Retain-Merker und Paketkennung, reiht den Transfer ein und kehrt zurück - erst dann bestätigt die Clientbibliothek. Der Transfer läuft danach ohne jeden Bezug zum Broker ab, sein Ergebnis wird nicht zurückgemeldet. Weitere Nachrichten werden auf demselben Weg quittiert und reihen sich in die Warteschlange des Triggers ein.

Warte auf Transfer: ein (QoS 1 oder 2)

Die Quittung steht jetzt hinter dem Transfer: der Router hält sie zurück und sendet sie erst, wenn der Transfer beendet ist. Gewartet wird dabei nicht im Empfangsweg, sondern in der offenen Quittung. Der Inhalt der Quittung ist in jedem Fall derselbe, ein fehlgeschlagener Transfer wird dem Broker nicht als Fehler gemeldet. Kommt gar kein Transfer zustande, bleibt die Quittung aus, und der Broker stellt die Nachricht erneut zu.

Lage der Broker-Quittung gegenüber dem Transfer: ohne „Warte auf Transfer“ wird nach dem Einreihen des Transfers quittiert, mit der Option erst nach dessen Ende.

Shared Subscriptions (MQTT v5)

MQTT Version 5 erforderlich

Shared Subscriptions sind ein Feature von MQTT Version 5 und erfordern die Unterstützung durch Broker und Client.

Mit Shared Subscriptions können mehrere Clients einer gemeinsamen Consumer-Gruppe beitreten und eingehende Nachrichten gleichmäßig unter sich aufteilen. Dies ermöglicht eine horizontale Skalierung auf der Empfängerseite.

Topic-Format

$shared/[groupName]/[topic]

Beispiel:

$shared/inrayTest/SharedSubscriptionTest

Verhalten

• Die Verteilung der Nachrichten erfolgt nach dem Round-Robin-Prinzip bzw. brokerabhängig (häufig „fair dispatch"). Ziel ist eine möglichst gleichmäßige Lastverteilung zwischen den Clients innerhalb einer Gruppe.
• Jeder veröffentlichte Datensatz wird genau einmal an einen Subscriber der Shared Group zugestellt (unter Berücksichtigung der jeweiligen QoS-Stufe).
• Clients mit unterschiedlichem groupName erhalten die Nachrichten unabhängig voneinander – jede Gruppe arbeitet isoliert.

Voraussetzungen

• Unterstützung von MQTT Version 5 durch Broker und Client.
• Alle beteiligten Clients müssen sich mit dem identischen Shared Subscription Topic (inkl. gleichem groupName) verbinden, um Teil derselben Consumer-Gruppe zu sein.

QoS-Verhalten

Aspekt	Beschreibung
QoS-Unterstützung	QoS wird weiterhin wie gewohnt angewendet (0, 1 oder 2).
Einfluss auf Verteilung	Die Shared Subscription beeinflusst nur die Verteilung, nicht die Zustellgarantie.
Wiederholversuche	Bei QoS > 0 kann es je nach Broker-Implementierung zu erneuten Zustellversuchen kommen, falls ein Client nicht bestätigt.

Einschränkungen und Besonderheiten

Aspekt	Beschreibung
Nachrichtenreihenfolge	Die Reihenfolge ist nicht garantiert, da unterschiedliche Clients Nachrichten verarbeiten.
Stateful Processing	Falls Zustände oder Reihenfolgen relevant sind, müssen diese extern verwaltet werden.
Broker-Abhängigkeit	Das exakte Verhalten (z. B. Verteilungsstrategie) kann je nach MQTT-Broker variieren.

Beispiel

Publisher sendet an:

SharedSubscriptionTest

Subscriber verwenden:

$shared/inrayTest/SharedSubscriptionTest

Mit drei aktiven Clients in der Gruppe inrayTest werden eingehende Nachrichten verteilt, z. B.:

Nachricht	Zugestellt an
Nachricht 1	Client A
Nachricht 2	Client B
Nachricht 3	Client C
Nachricht 4	Client C

MQTT 5 Benutzer-Eigenschaften

Der Reiter MQTT 5 Benutzer-Eigenschaften dient dazu, MQTT-5-Benutzer-Eigenschaften aus empfangenen Nachrichten im Flow verfügbar zu machen.

MQTT-5-Benutzer-Eigenschaften sind frei definierbare Schlüssel-Wert-Paare, die zusätzlich zum eigentlichen Payload übertragen werden. Sie enthalten also keine Nutzdaten im engeren Sinn, sondern ergänzende Metadaten zur Nachricht.

Typische Einsatzfälle sind:

• Kennzeichnung der Herkunft einer Nachricht, zum Beispiel Quelle=Anlage 3
• Übergabe fachlicher Zusatzinformationen, zum Beispiel Nachrichtentyp=Alarm oder Bereich=Abfüllung
• Weitergabe technischer Zusatzangaben, zum Beispiel SchemaVersion=1.0
• Auswertung in nachfolgenden Transfers oder Zielsystemen, die MQTT-5-Benutzer-Eigenschaften gezielt berücksichtigen

Verwenden Sie diesen Reiter nur, wenn das empfangende oder nachfolgend verarbeitende System MQTT-5-Benutzer-Eigenschaften tatsächlich benötigt. Wenn diese Metadaten in Ihrem Ablauf keine Rolle spielen, kann der Reiter ungenutzt bleiben.

hinweis

Wie beim MQTT-Transferobjekt ersetzen MQTT-5-Benutzer-Eigenschaften nicht den eigentlichen Nachrichteninhalt. Inhalte, die fachlich verarbeitet werden müssen, sollten weiterhin im Payload oder in einer klaren Topic-Struktur übertragen werden.