MQTT
Konzept
Der MQTT-Treiber verbindet sich als Client mit einem Broker, abonniert Topics (SUBSCRIBE) und veröffentlicht Nachrichten (PUBLISH). Die Payload wird als JSON interpretiert. PROTOCOL beginnt mit MQTT.
Feste Einstellungen: QoS 1, clean session, automatischer Reconnect.
Parameter
| Key | Beschreibung |
|---|---|
CONNECTION |
DOMAIN |
DOMAIN |
Broker-URL, z. B. tcp://<BROKER_IP>:1883. Wird kleingeschrieben. |
USER, PASSWORD |
Broker-Zugang (setzt der Benutzer) |
CLIENTID |
Default ioDeviceDBDevice_Mqtt_<station>_<device> |
AUTHENTIFICATION |
z. B. NONE oder PASSWORD |
Spalten
| Spalte | Beschreibung |
|---|---|
ALIAS |
Name |
METHOD |
SUBSCRIBE oder PUBLISH |
TOPIC |
Topic. Wildcards + (eine Ebene) und # (Rest). |
POLLING |
ms (bei PUBLISH: Sendeintervall, 0 = nur bei .F) |
FORMULA |
Formel. Bei SUBSCRIBE wird sie beim Empfang einer Nachricht ausgeführt. |
Argumente: ;*ARGS;METHOD;ALIAS;TYPE;NAME;VALUE;ITEM;FORMAT; (Spalte nach ARGS = Funktions-Alias) mit TYPE = topic (Topic-Teil) oder data (Payload-Feld). Es gelten die FORMAT-Werte wie bei REST. Eine PUBLISH-Payload wird in {} gepackt.
Zugriff
| Ausdruck | Bedeutung |
|---|---|
<A>.MQTT_DATA |
Rohpayload |
<A>.MQTT_CONNECTION |
Verbindungsstatus |
<A>.VALUE.<pfad> |
JSON-Wert |
<A>.EXIST.<pfad>, .FIND…, .ASLIST…, .ARRAY.MEDIA|MIN|MAX|LEN… |
wie bei REST |
Realer Auszug: myGEKKO SEAMLESS SENSOR
Datei myGEKKO.Sensor.MQTT (DDF).SEAMLESS SENSOR.1(0x1000000100010100).csv (gekürzt, Namen und IDs geschwärzt):
*GENERAL;
;DEVICE;SEAMLESS SENSOR;
;MANUFACTURER;myGEKKO;
;TYPE;Sensor;
;PROTOCOL;MQTT (DDF);
;VERSION_NR;1;
;MODEL_NR;1;
;ID;0x1000000100010100;
;MIN_CONTROL_VERSION;V10086-00;
;CONNECTION;DOMAIN;
;AUTHENTIFICATION;PASSWORD;
*COMMAND;ID;ALIAS;FORMULA;
;0;SUBSCRIBE;"""SUBSCRIBE.F:=1;""";
;1;PUBLISH;"""PUBLISH.F:=1;""";
;2;LOGIN_A;"""
ITEM.DEVICE_ID:='1';
ITEM.UID:='<UID>';
ITEM.USERNAME:='<NAME>';
PUBLISH.F:=1;
""";
*READ;ALIAS;METHOD;TOPIC;FORMULA;
*WRITE;ALIAS;METHOD;TOPIC;FORMULA;
;SUBSCRIBE;SUBSCRIBE;person_tracker/status/+/poi/+/+;"""
ITEM.EVENT_TYPE:=SUBSCRIBE.VALUE.event_type;
ITEM.PERSON_ID:=SUBSCRIBE.VALUE.person_id;
ITEM.POI_NAME:=SUBSCRIBE.VALUE.poi_name;
ITEM.PEOPLE_IN_POI:=SUBSCRIBE.VALUE.people_in_poi;
ITEM.VISIT_DURATION:=SUBSCRIBE.VALUE.visit_duration_s;
ITEM.TIMESTAMP:=SUBSCRIBE.VALUE.timestamp;
IF ISEQUAL(ITEM.EVENT_TYPE, 'stay') THEN
POI_1_STAY:=1;
TIMER:=TIMER+1;
IF TIMER >=2 THEN
POI_1_STAY:=0;
TIMER:=0;
ENDIF;
ELSE
POI_1_STAY:=0;
ENDIF;
""";
;PUBLISH;PUBLISH;person_tracker/identity;"""
DEBUG(SEND);
""";
;*ARGS;METHOD;ALIAS;TYPE;NAME;VALUE;ITEM;FORMAT;
;ARGS;PUBLISH;;topic;device_id;1;;STRING;
;ARGS;PUBLISH;;data;user_id;<USER_ID>;;STRING;
;ARGS;PUBLISH;;data;name;<NAME>;;STRING;
*GROUP;ID;ALIAS;NAME;
;0;DATA;DATA;
*ITEM;ALIAS;VISIBILITY;ID;UNIT;TYPE;DIR;DEFAULT;WFORMULA;RFORMULA;POLLING;
;EVENT_TYPE;;0;;string;IN;;;"""
SUBSCRIBE.F:=1;
""";1000;
;PERSON_ID;;1;;int;IN;
;VISIT_DURATION;;9;sec;real;IN;
;POI_1_STAY;;14;;int;IN;
Was der Auszug zeigt:
- Jede Anweisung endet mit
;, auch einzeilige Kommandoformeln (SUBSCRIBE.F:=1;). - Die Funktionen stehen hier im
*WRITE-Block (ONCHANGE). DieRFORMULAdes ItemsEVENT_TYPEsetzt jede SekundeSUBSCRIBE.F:=1;und hält die Funktion damit aktiv. - Wildcards
+im Topic. Die Payload wird perSUBSCRIBE.VALUE.<feld>gelesen. - PUBLISH: Topic-Teile mit
TYPEtopic, Payload-Felder mitTYPEdata. Die Payload wird als JSON{…}gesendet. *COMMAND-Formeln lösen Funktionen manuell aus.
Fallstricke
- Der Broker-Host wird kleingeschrieben. Topics sind case-sensitive, bleiben aber unverändert.
- Mit
EXISTprüfen, bevor man liest: Nicht jede Nachricht enthält alle Felder. - Bei Wildcard-Abos landen Nachrichten verschiedener Topics in derselben Formel. Unterscheiden Sie sie über Payload-Inhalte.
- Gleiche
CLIENTIDauf zwei Systemen führt zu gegenseitigem Rauswurf am Broker.
Checkliste
- [ ]
DOMAINmittcp://(bzw.ssl://) und Port - [ ] SUBSCRIBE-Formeln prüfen
EXIST - [ ] PUBLISH-Payload über
data-Argumente - [ ] eindeutige
CLIENTIDbei Bedarf