MQTT an drei Beispielen

Was auf einem Display steht und was ein Finger dort schaltet, läuft über den MQTT-Broker. Diese Seite zeigt an drei Beispielen, welche Nachricht wohin geht und was sie bedeutet. Jedes Beispiel baut auf dem vorigen auf.

In den Bildern stehen links die Anlage, in der Mitte der Broker mit seinen Topics und rechts die Displays. Ein Topic ist ein Name, unter dem eine Nachricht auf dem Broker liegt oder durch ihn hindurchgeht. Die Anlage ist hier Pekaway, dessen Werte die VanPi-Brücke auf den Broker legt.

1. Der Wassertank: ein Wert, der liegen bleibt

Pekaway legt den Füllstand ab, jedes Display holt ihn sich, auch eines, das erst später einschaltet.

Der einfachste Fall hat genau ein Topic: schaltli/state/tank/1/level. Pekaway misst den Tank, und die Brücke schickt den Füllstand als Zahl an dieses Topic, zum Beispiel 63. Ein Display, das den Tank zeigt, liest dieses Topic und stellt den Balken auf 63 %. Es selbst schickt nichts.

Die Brücke fragt Pekaway alle zwei Sekunden. Nur wenn der Füllstand sich geändert hat, schickt sie eine neue Nachricht, und bei einem Tank ändert sich oft lange nichts.

Deshalb schickt sie den Wert retained: Der Broker behält die letzte Nachricht und gibt sie jedem, der sich neu für das Topic meldet. In den Bildern steht dafür «bleibt liegen». Schaltest du Display B erst am Abend ein, bekommt es die 63 sofort und muss nicht warten, bis im Tank wieder etwas passiert. Ohne retained bliebe sein Balken leer, bis zur nächsten Änderung.

Alle Werte unter schaltli/state/… bleiben so liegen. Die Liste steht unter VanPi-Brücke.

2. Der Dimmer: Zustand und Befehl

Display A schickt einen Befehl, die Anlage meldet den neuen Zustand, und beide Displays zeigen ihn.

Einen Dimmer willst du auch stellen können. Dafür gibt es zwei Topics:

• schaltli/state/dimmer/1/level ist der Zustand: wie hell das Licht gerade ist. Er kommt von der Anlage und bleibt liegen wie beim Tank.
• schaltli/cmnd/dimmer/1 ist der Befehl: wie hell es werden soll. Er kommt von einem Display.

Die Nummern im Bild zeigen, was passiert, wenn du auf Display A den Regler auf 40 ziehst:

1. Display A schickt 40 an den Befehl schaltli/cmnd/dimmer/1.
2. Die Brücke liest den Befehl, stellt den Dimmer bei Pekaway und legt 40 gleich unter schaltli/state/dimmer/1/level ab.
3. Kurz danach fragt sie Pekaway nach dem neuen Stand. Meldet Pekaway einen anderen Wert, ersetzt sie die 40 damit.
4. Beide Displays lesen dieses Topic und zeigen 40, auch Display B, an dem niemand etwas getan hat.

Ein Display zeigt also, was die Anlage meldet. Während du ziehst, folgt der Regler deinem Finger. Klappt ein Befehl nicht, springt er nach spätestens gut zwei Sekunden auf den gemeldeten Wert zurück. Und wer den Dimmer an Display B oder in Pekaway selbst verstellt, verstellt ihn auch auf Display A. Das Topic für den Zustand ist die eine Stelle, an der der Stand gilt.

Warum ein Befehl nicht liegen bleiben darf

Ein Befehl geht einmal durch und ist weg, im Bild «geht durch». Bliebe er liegen, bekäme ihn die Brücke jedes Mal wieder, wenn sie sich neu mit dem Broker verbindet, etwa nach einem Neustart des Pekaway-Systems. Sie würde ihn dann noch einmal ausführen: Der Dimmer stünde wieder auf 40, auch wenn du ihn inzwischen auf 0 gestellt hast, und das Licht ginge womöglich mitten in der Nacht an.

Die Displays schicken ihre Befehle nie retained. Schreibst du selbst Befehle, etwa aus Node-RED oder mit mosquitto_pub, lass es ebenfalls weg.

Im Designer

Ein Baustein aus einer angekündigten Zahl verdrahtet beides selbst. Bei einem Slider von Hand trägst du den Zustand unter Topic ein und den Befehl unter Write topic, siehe Slider. Für einen Schalter gilt dasselbe mit Read topic und Write topic, siehe Switch.

3. Die Heizung: Soll und Ist

Die Heizung braucht drei Topics: was gemessen wird, was eingestellt ist, und den Befehl, der das Eingestellte ändert.

Beim Dimmer ist der gewünschte Wert eine Sekunde später auch der tatsächliche. Bei einer Heizung nicht: Stellst du 21 °C ein, ist es im Van noch lange 17 °C. Eingestellter und gemessener Wert sind verschiedene Dinge, und beide will man sehen. Deshalb kommt ein drittes Topic dazu:

• schaltli/state/heater/temp ist das Ist: die gemessene Temperatur, 17. Es kommt von der Heizung und bleibt liegen.
• schaltli/state/heater/target ist das Soll: die eingestellte Temperatur, 21. Auch das meldet die Anlage, und auch das bleibt liegen.
• schaltli/cmnd/heater/target ist der Befehl, der das Soll ändert, 12 bis 35. Er geht durch wie beim Dimmer.

Der Befehl ändert also nicht die Temperatur, sondern das Soll. Die Anlage meldet das neue Soll zurück, genau wie beim Dimmer. Das Ist folgt irgendwann von selbst, wenn die Heizung ihre Arbeit tut.

Ein- und ausschalten ist davon getrennt: schaltli/cmnd/heater mit on oder off, gemeldet unter schaltli/state/heater/power.

Im Designer

Am besten zeigt ein Dial beides: Der Ring ist bis zum Ist gefüllt, eine Marke steht beim Soll, und der Finger verschiebt die Marke. Einen Baustein für die Heizung gibt es nicht, du verdrahtest den Dial selbst:

Eigenschaft	Topic
Topic	schaltli/state/heater/temp
Setpoint topic	schaltli/state/heater/target
Write topic	schaltli/cmnd/heater/target

Mit Calibration legst du fest, dass der Ring bei 12 °C leer und bei 35 °C voll ist.

Selbst mithören

Auf dem Pekaway-System siehst du genau diese Nachrichten, während sie passieren:

mosquitto_sub -h localhost -t 'schaltli/state/dimmer/#' -t 'schaltli/cmnd/dimmer/#' -v

Zieh auf einem Display den Dimmer: Zuerst erscheint die Zeile mit cmnd, kurz danach die mit state. Beendest du mosquitto_sub mit Ctrl+C und startest es neu, stehen die state-Zeilen sofort wieder da, weil sie liegen geblieben sind. Die cmnd-Zeilen fehlen, denn Befehle bleiben nicht liegen.

Einen Befehl kannst du auch von Hand schicken:

mosquitto_pub -h localhost -t 'schaltli/cmnd/dimmer/1' -m 40

Mehr zum Broker und zu allen Topics steht unter MQTT-Broker und Topics.