Montag, 4. November 2019

MQTT - ich will das testen

... und aufschreiben. Das ist alles ziemlich spannend.
Entstanden ist letztendlich ein kleiner Workshop als Trockentest - Es wird keine extra Hardware benötigt!

Testumgebung

Ein frisches (oder gut gebrauchtes) FHEM und dann
define mqtt2s MQTT2_SERVER 1883 global
attr mqtt2s room MQTT_IO
Ein Linux oder Windows mit mosquitto installiert (install mosquitto-clients oder Windows )
Dort Terminal oder CMD Fenster und folgende Zeile eingeben:
mosquitto_pub -h raspib2 -i COMPUTER -t CPU/raspib/temperature -m 22
Was passiert? Es entsteht sofort ein Device in FHEM:
defmod MQTT2_COMPUTER MQTT2_DEVICE COMPUTER
attr MQTT2_COMPUTER IODev mqtt2s
attr MQTT2_COMPUTER readingList COMPUTER:CPU/raspib/temperature:.* temperature
attr MQTT2_COMPUTER room MQTT2_DEVICE

setstate MQTT2_COMPUTER 2019-10-21 12:57:00 temperature 22

Empfänger

Weitere Publish Befehle aktualisieren nur das Reading temperature. 

Hinweis 2023: Ich habe ein universelles Script geschrieben um Daten von einem Linux System zu einem MQTT Server zu senden.

Beispiel: Endlosschleife (Abbruch ctrl+c) die alle 30 sec die aktuelle CPU Temperatur schreibt:
while [ true ] ; do mosquitto_pub -h raspib2 -i COMPUTER -t CPU/$(hostname)/temperature -m $(($(</sys/class/thermal/thermal_zone0/temp)/1000)) ; sleep 30 ; done
Der wird sogar geloggt, autocreate hat gleich ein FileLog mit angelegt.
Diese Device bedient jetzt eine wesentliche Funktion: den MQTT Empfänger.

Hinweis: Die autocreate Funktion erzeugt ein Device mit der CID (COMPUTER).
Wird die while Schleife auf einem anderen Computer gestartet, ändert sich die Topic Liste (wegen CPU/$hostname). Dadurch wird die readingList ergänzt aber das Reading bleibt das Gleiche (temperature) d.h. alle Werte von unterschiedlichen Quellen kommen in das gleiche Reading! Weiter unten zeige ich wie man das manuell ändert.

Man wird in der Praxis nicht umhin kommen die automatisch erzeugten MQTT_Geräte manuell zu bearbeiten! (Stand November 2019)

Monitor

Ich kann die Nachrichten auch ganz andere Stelle sehen, z.B. in einem Terminal. Dort einfach als Subscriber für alle Topics registrieren:
mosquitto_sub -h raspib2 -v -t '#'
Damit wird jede Nachricht vom Terminal 1 an den MQTT Server auch in Terminal 2 empfangen. Im mqtt2s sieht man im reading nrclients die Verbindung. Das eigene Device wird dort nicht angezeigt.

Sender

Als nächstes will ich von dem Device etwas publishen (eigentlich ein unnützer Versuch)
attr MQTT2_COMPUTER setList off:noArg cmnd/raspib/POWER off\
on:noArg cmnd/raspib/POWER on
Damit bekomme ich im Device ein on und off "Button" und sehe in meinem Terminal 2 zwischen den Temperaturen die ankommende Nachricht. Die aber jetzt nichts bewirkt.
CPU/raspib/temperature 53
cmnd/raspib/POWER on
cmnd/raspib/POWER off
CPU/raspib/temperature 52

Gerät steuern

Versuch: Simulation und Steuerung eines externen mqtt Gerätes
Ich erzeuge in einer zweiten FHEM Instanz ein Gerät (MQTT2_DEVICE) und einen IO (MQTT2_CLIENT).
Über die readingList will ich die Nachricht POWER (von dem Publish Versuch eben) in das Reading state schreiben:
define mqtt2c MQTT2_CLIENT raspib2:1883
attr mqtt2c room MQTT_IO

define MQTT2_Test MQTT2_DEVICE Test
attr MQTT2_Test IODev mqtt2c
attr MQTT2_Test readingList cmnd/raspib/POWER:.* state
attr MQTT2_Test room MQTT2_DEVICE
Ergebnis: Ich kann jetzt sowohl von FHEM (MQTT2_COMPUTER) als auch von extern das Gerät MQTT2_Test schalten:
mosquitto_pub -h raspib2 -t cmnd/raspib/POWER -m off
Damit das Gerät sich selbst "steuern" kann und mqtt Nachrichten erzeugt erweitere ich es noch um die setList:
attr MQTT2_Test setList off:noArg cmnd/raspib/POWER off\
on:noArg cmnd/raspib/POWER on
Funktion
  • Das ursprünglich automatische Gerät "COMPUTER" kann das Gerät "Test" in der zweiten Instanz steuern.
  • Über eine separate Publish Nachricht kann das Gerät "Test" ebenfalls gesteuert werden 
  • Das Gerät COMPUTER reagiert selbst nicht auf die Nachrichten des Gerätes Test oder von "außen". 
Mit dem attr mqtt2s rePublish 1 oder mit einem zusätzlichen IO (MQTT2_CLIENT) funktioniert dies auch in der ersten FHEM Instanz.
Ich bin nicht sicher ob es einen gutem Grund(Schleifen?) gibt, die eigenen Publish-Nachrichten nicht per default an die eigenen Devices zu verteilen.

Erweiterung des Versuches:
Man kopiert die komplette Definition von "Test" inklusiver der Definition mqtt2c in die erste Instanz.
Ergebnis: Beide FHEM Instanz haben jetzt ein Gerät "Test" welches synchron schaltet.
Zusätzlich können beide Geräte von "außen" und über das Gerät "COMPUTER" gesteuert werden. Durch Manipulation der IOs mit disable 1/0 und beim mqtt2s mit rePublish 1/0 kann man das Verhalten und die Auswirkungen gut testen.

MQTT über Internet

Steve hat hier eine Übersicht über kostenfreie MQTT Broker erstellt.
Bei myqtthub.com gibt es einen "open Plan" der kostenfrei einen MQTT Broker bietet (Oktober 2020).
Bei cloudmqtt.com gab es mal die "cute cat" kostenfrei. 
Nachtrag Juli 2020:  Mein Account funktioniert weiter, obwohl das Angebot nicht mehr existiert:
  • den Zugang "normal", 
  • SSL/TLS, Websocket und 
  • API Zugriff! 
  • 5 User Connections und 10 kbit/s Datentransfer Volumen. 
Achtung: Die CID muss beim Zugriff auf cloudmqtt einmalig sein, eine zweite Verbindung mit gleicher CID beendet die Erste!
So bekommt die Testumgebung (2. Instanz) einen weiteren IO.
define mqtt2Cloud MQTT2_CLIENT xxxxxx.cloudmqtt.com:21234
attr mqtt2Cloud SSL 1
attr mqtt2Cloud room MQTT_IO
attr mqtt2Cloud username uuuuuuu
set mqtt2Cloud password pppppppppppp
Um die Verbindung zum cloudmqtt zu testen habe ich mosquitto_pub oder auch ein Android App MyMQTT ausprobiert. Die Android App kann leider keine SSL Verbindung.
Hinweis: Will man mit mosquitto eine SSL Verbindung machen, muss man die Option --insecure verwenden?! (leider weiß ich nicht warum)
mosquitto_sub -h xxxxxx.cloudmqtt.com -p 21234 -u uuuuuuu -P pppppppppppp -v -t '#' --capath /etc/ssl/certs --insecure
Um eine Reaktion im System zu erhalten, habe ich noch ein MQTT2_Test1 Device in der 2. Instanz erstellt:
define MQTT2_Test1 MQTT2_DEVICE Test1
attr MQTT2_Test1 IODev mqtt2Cloud
attr MQTT2_Test1 readingList mobil/POWER:.* state
attr MQTT2_Test1 room MQTT2_DEVICE
attr MQTT2_Test1 setList off:noArg mobil/POWER off\
on:noArg mobil/POWER on
Das reagiert jetzt auf den Topic mobil/POWER (analog zu dem vorhanden MQTT2_Test) Device und ist "mobil" steuerbar.

Nach kurzer Zeit ist mir etwas aufgefallen:
Erweitert man die readingList um den topic vom Gerät MQTT2_Test:
attr MQTT2_Test1 readingList mobil/POWER:.* state\
cmnd/raspib/POWER:.* Teststate
wird das Reading Teststate analog zum Reading state von Gerät MQTT2_Test aktualisiert.
  • Mehr noch: Ich kann den topic cmnd/raspib/POWER über den cloudmqtt Server publishen und das Gerät Test in der 2. Instanz schalten. Das attr IODev muss dazu nicht verändert werden: MQTT2_Test hat IODev mqttc und 
  • MQTT2_Test1 hat IODev mqttCloud! 
  • Das IODev hat ausgehend Bedeutung, eingehend verarbeiten die MQTT2_DEVICEs nur den Topic!

Brücke schlagen

Ich will den Versuch erweitern und Werte zwischen FHEM Instanzen übertragen, die gar nicht aus dem mqtt Umfeld kommen.
Dazu erzeuge ich in meiner zweiten Instanz ein paar "manuelle Temperaturfühler":
define fuehler1 dummy
attr fuehler1 readingList temperature humidity
attr fuehler1 room Fühler
attr fuehler1 setList temperature:25,25.5,26,26.5,27,27.5,28 humidity:50,55,60,65,70,75,80
attr fuehler1 userReadings state {my $temp=ReadingsVal($name,"temperature",99);;my $hum=ReadingsVal($name,"humidity",99);;sprintf "T: $temp H: $hum"}
Zur Übertragung nehme ich ein notify (die Idee ist von hier). Das notify macht folgendes:
  • es reagiert auf Events der Geräte fuehler1 oder fuehler2 usw. sowie deren Readings temperature und humidity
  • es verwendet set magic
  • es befreit den Readingnamen im Event vom ":" (wobei ich nicht sicher bin ob das wirklich sein muss). Die Idee stammt von hier.
define n_publish3 notify fuehler.:(temperature:|humidity:).* set mqtt2c publish -r home/states/$NAME/{((split(":","$EVTPART0"))[0])} $EVTPART1
attr n_publish3 room Fühler
In der ersten Instanz ensteht jetzt durch autocreate eine Art Sammeldevice MQTT2_mqtt2c.
Aus diesem erzeugt man sich die passenden Devices. Wichtig hier ist die Anpassung der Topic "Kette"
define fuehler1 MQTT2_DEVICE mqtt2c
attr fuehler1 readingList home/states/fuehler1/temperature:.* temperature\
home/states/fuehler1/humidity:.* humidity
attr fuehler1 room Fühler
attr fuehler1 userReadings state {my $temp=ReadingsVal($name,"temperature",99);;my $hum=ReadingsVal($name,"humidity",99);;sprintf "T: $temp H: $hum"}

Modifikation

Die attr readingList wird schnell unübersichtlich und schwierig zu warten. Mit nur zwei Modifikationen stellt man die Übertragung auf das JSON Format um.

  • Die Definition der mqtt Geräte wird einheitlicher und einfacher.
  • Man kann auch leicht mehrere Readings in einer Nachricht übertragen.

Erste Instanz
Die readingList reagiert so auf alle Nachrichten die mit dem Topic home/states/ beginnen und wo im Topic der eigene Gerätename vorkommt.
attr fuehler. readingList home/states/.* { if ($TOPIC=~m/$NAME/) { json2nameValue($EVENT) } }
Zweite Instanz
Das notify erzeugt ab sofort Nachrichten im JSON Format.
defmod n_publish3 notify fuehler.:(temperature:|humidity:).* set mqtt2c publish -r home/states/$NAME { "{((split(":","$EVTPART0"))[0])}": $EVTPART1 }

Alle Readings auslesen

Ich habe mal noch zwei Codezeilen gebaut, die entweder alle Readings eines Gerätes oder bestimmte Readings (Array) als JSON String ausgeben. Dieser Code ist zum Test in der Kommandozeile gedacht!
# Für Kommandozeile - alle Readings
{my $d="fuehler1";;my $hash = $defs{$d};;my $readings = $hash->{READINGS};;my $message="{ ";;foreach my $a ( keys %{$readings} ) {my $val=ReadingsVal($d,$a,"error");;$message .= toJSON($a)." : ".toJSON($val)." ," };;chop($message);;$message.="}"}

# Für Kommandozeile - nur zwei Readings
{my $d="fuehler1";;my @readings = ("temperature","humidity");;my $message="{ ";;foreach my $a ( @readings) {my $val=ReadingsVal($d,$a,"error");;$message .= toJSON($a)." : ".toJSON($val)." ," };;chop($message);;$message.="}"}
Will man im obigen set ... publish eine JSON formatierte Nachricht mit allen Readings des triggernden Gerätes absetzen, sieht das wie folgt aus (Dieser Code ist für die DEF!):
{(my $d="$NAME";;my $hash = $defs{$d};;my $readings = $hash->{READINGS};;my $message="{ ";;foreach my $a ( keys %{$readings} ) {$message .= toJSON($a)." : ".toJSON(ReadingsVal($d,$a,"error"))." ," };;chop($message);;$message.="}")}
Ich habe bewusst auf Formatierung verzichtet, in der DEF kann man den Code "lesbarer" formatieren.
Achtung: Die FHEM Kommandozeile und set magic haben gegenüber dem normalen Perl Code immer ein paar Besonderheiten. -> ;; {(...)} "$NAME"

Tipp:

Nimmt man als MQTT Server einen Server in der Cloud, kann man damit die FHEM Instanzen ziemlich simpel übers Internet koppeln, ohne irgendeine Portfreigabe!

Allgemeine Brücke

Das Modul MQTT_GENERIC_BRIDGE scheint für die Kopplung der MQTT- und Nicht-MQTT Welt designed zu sein - eigentlich wollte ich dies als nächstes testen. Die Installation ist deutlich aufwendiger, deswegen sehe ich erstmal davon ab.

Ganz verrückt

Man kann aber auch mit einem kleinen  Shell Script mqtt Nachrichten auf System Ebene verarbeiten.

Notizen und Infos

Die mosquitto Windows Version installiert Server und Clients in einem Setup, man kann den Service aber "aushaken". Unter Linux installiert das Paket mosquitto den Server und mosquitto-clients nur die Client Tools.

Achtung: Alle MQTT Server laufen per default auf Port 1883! (Auch Mosquitto Server und MQTT2_SERVER) Es kann nur einen geben!

Gibt man bei mosquitto_pub keine CID an (Option -i) dann wird dies per default so gesetzt: "Defaults to mosquitto_pub_ appended with the process id." MQTT2_DEVICE ignoriert diese CID und legt dafür kein neues Device an!

Topic: Nach ersten Versuchen habe ich irgendwie gelesen, man soll bei den Topics keine führenden Slash's nehmen. Dadurch entsteht eine leere Ebene (bad practise).
Man kann jeden beliebigen Topic monitoren, das # gibt alle weiteren Level zurück. Das # allein liefert alle Topics, damit die Shell das nicht als Kommentar interpretiert muss man '#' schreiben!

Von steves-internet-guide habe ich mir auch ein paar Anregungen geholt.
Eingestellt von um 2 Kommentare:
Labels: , ,
Abonnieren Posts (Atom)