| | 1 | = MQTT Topic-Struktur |
| | 2 | |
| | 3 | [[PageOutline(2-6)]] |
| | 4 | |
| | 5 | == Topics eines Gerätes |
| | 6 | |
| | 7 | Jedes Gerät meldet sich bei seinem Location-Broker an. Die Location-Broker sind für die verschiedenen Etagen aufgeteilt. Es sind folgende Location-Broker definiert: |
| | 8 | |
| | 9 | * Keller: `ug-broker.mqtt.p21.net:1884` |
| | 10 | * Erdgeschoss: `eg-broker.mqtt.p21.net:1885` |
| | 11 | * 1. Obergeschoss: `og1-broker.mqtt.p21.net:1886` |
| | 12 | * 2. Obergeschoss: `og2-broker.mqtt.p21.net:1887` |
| | 13 | * !Hof/Garten: `yard-broker.mqtt.p21.net:1888` |
| | 14 | * tragbare Geräte: `moving-broker.mqtt.p21.net:1889` |
| | 15 | |
| | 16 | Diese Broker sind vorerst alle auf dem selben Host realisiert, daher benötigen sie entweder unterschiedliche IP-Aliase (knappe Ressource IP-Adressen) oder unterschiedliche Port-Nummern (gewählte Option). Mehr in MqttBroker. |
| | 17 | |
| | 18 | Diese Location-Broker werden durch (Self-)Bridging in die Gesamtstruktur abgebildet. Daher darf jedes Gerät eine sehr einfache Topic-Struktur verwenden. |
| | 19 | |
| | 20 | Die Topic-Struktur orientiert sich an den Möglichkeiten der Tasmota-Software, weil diese die ersten Geräte stellt und bereits bewährte Strukturen abbildet. |
| | 21 | |
| | 22 | Geräte-Topics sind folgendermaßen strukturiert: \\ |
| | 23 | `%prefix%/%topic%/%keyword%` \\ |
| | 24 | `%prefix%/%topic%/%keyword%/%metadata%...` |
| | 25 | |
| | 26 | `%prefix%`:: beschreibt die Datenart, es sind folgende Datenarten definiert: |
| | 27 | * `cmd`: Kommandos an das Gerät |
| | 28 | * `log`: Meldungen vom Gerät, z.B. Sensor-Werte |
| | 29 | * `feedback`: Status-Meldungen des Gerätes, i.d.R. als Reaktion auf Kommandos |
| | 30 | * `actuator`: direkter Zugriff auf einen Aktor eines Gerätes, benannt durch `%keyword%` |
| | 31 | * `sensor`: direkte Meldungen eines Sensors eines Gerätes, benannt durch `%keyword%` |
| | 32 | `%topic%`:: benennt das Gerät, den !Sensor/Aktor, die angesprochene Gruppe etc., welches auch Ort-Informationen tragen darf, ggf. mit Topic-Separator `/`, so daß sich evtl. (noch ungern gesehen) tiefere Topic-Strukturen bilden |
| | 33 | `%keyword%`:: ist spezifisch für das Gerät, den Sensor, den Aktor, die Gruppe etc. |
| | 34 | `%metadata%`:: ist optional bzw. noch in Entwicklung, als Ideen stehen hier Konventionen anderer Systeme Pate, so z.B.: |
| | 35 | * https://homieiot.github.io/ |
| | 36 | * https://tinkerman.cat/post/mqtt-topic-naming-convention |
| | 37 | |
| | 38 | Mehr Betrachtungen zum Topic-Tree unter folgenden URLs: |
| | 39 | * https://pi3g.com/2019/05/29/mqtt-topic-tree-design-best-practices-tips-examples/ |
| | 40 | * https://raspberry-valley.azurewebsites.net/MQTT-Topic-Trees/ |
| | 41 | * https://d1.awsstatic.com/whitepapers/Designing_MQTT_Topics_for_AWS_IoT_Core.pdf |
