Internet der Dinge für den Funkamateur: MQTT am Beispiel des Yaesu FT857
Bild 1: Das MQTT-Protokoll wurde nach dem Client-Server-Modell umgesetzt. Der Server wird Broker genannt und dient als Vermittler. Clients dürfen Daten senden und abonnieren.
Features:
Abfrage über das LAN / Internet
Schalten von Relais und LEDs aus der Ferne
Temperatur abfragen
Helligkeit abfragen
Das Internet der Dinge wird zukünftig Teil des normalen Alltags sein. Wie der Funkamateur schon heute ein wenig damit experimentieren kann, zeigt dieser Beitrag.. Das Maschine-zu-Maschine-Protokoll MQTT wird hier benutzt, um die am Transceiver eingestellte Empfangsfrequenz in das Internet zu übertragen. Allen YL / OM, welche diese Information abonniert haben, wird die Frequenz „geliefert“.
Das Triggererlebnis zum Basteln mit dem MQTT-Protokoll trat ein, als die Meldung die Runde machte, dass es im HAMNET neuerdings einen MQTT-Broker unter der Adresse mqtt.hc.r1.ampr.org gäbe. Leider funktionierte der hiesige VPN-Zugang zum Hamnet nicht (mehr) und damit war erst einmal der Weg zum HAMNET-MQTT-Broker versperrt. Die Alternative – um es testen zu können – ist ein öffentlicher MQTT-Broker im Internet.
Was aber ist ein MQTT-Broker? MQTT [1] steht für „Message Queuing Telemetry Transport“ und ist ein Protokoll zur Verteilung von Telemetriedaten, beispielsweise von Sensoren. MQTT folgt dem Client-Server-Modell. Der MQTT-Broker ist somit ein Server, der von Geräten Daten entgegen nimmt und an andere Geräte verteilt, ganz ähnlich wie ein Paket-Verteilzentrum. Diese Geräte, hier Clients (Kunden, Auftraggeber) genannt, können Sensoren, Aktoren, Mobiltelefone, Mikrocontrollersysteme, industrielle Steuerungen, Anzeigeinstrumente oder auch PCs sein. Der Vorteil von MQTT ist es, dass MQTT nur sehr geringe Ressourcen verbraucht und auf Geräte mit wenig Prozessorleistung wie ein 8-Bit-Mikrocontroller implementiert werden kann.
In unserer Bastelei ist das Funkgerät mit einem Arduino UNO verbunden, welcher wiederum den Kontakt zum lokalen Netzwerk und Internet ermöglicht. Der „Sensor“ ist in diesem Fall das Funklgerät, das per CAT-Befehl die aktuelle VFO-Frequenz an den Arduino liefert. Der Arduino fungiert als MQTT-Client. Auf ihm werkelt ein Programm, das die Übertragung per MQTT übernimmt. Auf der Server-Seite steht irgendwo im Internet der MQTT-Broker unter der Adresse test.mosquitto.org – oder besser im Hamnet der genannte MQTT-Broker. Er nimmt die übermittelte Frequenz entgegen und schaut, ob irgendein MQTT-Client diese Daten abonniert hat. Vorteil: Ein Client muss nicht beim Server ständig fragen: Hast du Daten für mich? Nein, es ist besser gelöst: Hat der Client diese Daten abonniert, bekommt er sie frei Haus geliefert. Mehrere Clients können diese Daten abonnieren – wie in unserem Fall die VFO-Frequenz an mehrere angeschlossene Abonnenten. Als Abonnenten kommen dieselben Geräte infrage, wie sie zuvor als Clients genannt wurden: Smartphones, Webseiten, Mikrocontroller, industrielle Steuerungen, der PC und so fort. Senden Sie ihre VFO-Frequenz zum Broker, können ihre Funkfreunde diese Information dort abonnieren und sind darüber informiert, auf welcher Frequenz sie gerade hören oder funken. Potenzielle QSO-Partner haben die Möglichkeit, mit ihnen auf der richtigen Frequenz in Verbindung zu treten. Praktisch, nicht?
Es sei nebenbei bemerkt, dass es sich geradezu anbietet, neben der VFO-Frequenz weitere Daten wie Raumtemperatur oder die relative Feuchte des Shacks an den Broker zu senden (zu „publishen“). Zudem kann der TRX mittels MQTT-Protokoll leicht in eine evtl. bestehende Heimautomatisierung (Smarthome) integriert werden. Derlei Systeme zur Haussteuerung und –automatisierung (z. B. FHEM) unterstützen neben anderen Protokollen auch MQTT. So lässt sich auf dem Smartphone via Internet neben den Daten der Heizung und dem Zustand der Lampe in der Küche auch die eingestellte Frequenz des TRX in Erfahrung bringen.
Doch kommen wir zurück zu unserem Beispiel. Was benötigen wir an Hardware für unseren MQTT-Client? Zunächst das Funkgerät, als Beispiel steht hier ein kompakter Yaesu FT857 auf dem Shacktisch. Weiterhin wird ein Arduino UNO sowie ein Arduino Ethernet-Shield benötigt. Das Ethernet-Shield ist eine Aufsteckplatine für den UNO, der den Kabelanschluss zum lokalen DSL-Router und damit ins Lokale Netzwerk (LAN) sowie ins Internet ermöglicht.
Die Verbindung zwischen TRX und Arduino UNO besteht aus nur drei Strippen, die zwischen CAT-Buchse und UNO verkabelt sind. Das sind Sendedaten (TX), Empfangsdaten (RX) und Masse (GND) der CAT-Buchse. Was noch fehlt, ist das „richtige“ Programm, beim Arduino „Sketch“ genannt und ein Programm für den PC, um den Datenfluss zu überwachen. Fangen wir mit letzterem an und simulieren ein wenig. MQTTBox
Auf der Suche nach einem MQTT-Client für Windows traf ich bald auf das kostenfreie MQTTBox [2]. Damit ist eine erste Kommunikation mit dem MQTT-Broker test.mosquitto.org auf Port 1883 möglich. Die Software gestattet sowohl das Senden von Daten als auch das Abonnieren von Topics (zur Erklärung der Begriffe rund um MQTT siehe Kasten).
Bild 2: Die Einstellungen für den Test-Broker in der Software MQTTBox.
Nach dem Start des Programms, das Sie nach einer Suche im Internet finden, erzeugen Sie einen neuen MQTT-Client. Die benötigten Einstellungen zeigt Bild 2. Dieser Broker steht öffentlich als Test-Broker jedem zur Verfügung und verzichtet auf eine Anmeldung mit Username und Passwort. Das erleichtert die Kontaktaufnahme. Wenn Sie ins HAMNET gelangen können, versuchen Sie zusätzlich den Kontakt zu mqtt.hc.r1.ampr.org einzurichten, ebenfalls auf Port 1883.
Bild 3: MQTTBox: Frequenz und Status des Arduino fließen ein. Das linke Fenster bietet die Möglichkeit, eine Zeichenkette zu „publishen“.
Das Bild 3 zeigt, wie sich das Programm bei einer Kommunikation zeigt. Links wurde ein „topic to publish“ eingerichtet, rechts zwei Abonnenten-Topics. Sendet man nun einen Text an den Broker, erscheint postwendend dieser Text im Abo-Fenster des jeweiligen Topics. Damit ist der erste Kontakt zum Broker geschafft – nun steht die Programmierung des Arduino an. MQTT mit dem Arduino
Das erste Testprogramm mqtt_ethernet_test2.ino stellt über das Ethernet-Shield eine Verbindung zum Broker test.mosquitto her und sendet zum Broker unter dem Topic outTopic und empfängt mit dem Topic inTopic. Dazu verwendet es zwei Bibliotheken, eine für das Ethernet-Shield und die andere namens PubSub [3] für das MQTT-Protokoll. Es existiert eine weitere MQTT-Lib von Adafruit, die scheint aber speziell für den MQTT-Broker von Adafruit programmiert zu sein und arbeitete mit dem Mosquitto-Broker zumindest auf Anhieb nicht zusammen. Daher wurde die letzgenannte nicht verwendet.
Bild 4: Öffnet man den Seriellen Monitor der Arduino-IDE, kann man den Fortschritt des Programms verfolgen.
Der übertragene Wert entspricht dem des ersten analogen Eingangs (Arduino Pin A0). Den Verlauf des Programms verfolgen Sie mit einem Terminalprogramm oder mit dem Seriellen Monitor bei 115200 Baud, der zur Arduino-IDE gehört (Bild 4). Damt es in ihrem LAN funktioniert sind drei Zeilen anzupassen: Tragen Sie die MAC-Adresse ihres Ethernet-Shield in die erste Zeile ein, ein Aufkleber auf dem Shield informiert über die physikalische Adresse.
Unter IPAddress ip weisen Sie dem Arduino in ihrem Netzwerk eine feste Adresse zu. Bei IPAddress server tragen Sie die Adresse ihres DSL-Routers ein. Nach dem Kompilieren und dem Start des Sketches sollte sich ihr Arduino mit dem Broker verbinden – er versucht dies im Abstand von fünf Sekunden. Ist der Broker stark ausgelastet, kann das schon einmal einige Zeit dauern.
Hat alles zufriedenstellend funktioniert, können Sie damit beginnen, die TRX-Frequenz zu übertragen. Und jetzt richtig!
Das geschieht mit dem Sketch mqtt_ethernet_test3.ino. Dieser Sketch baut auf das vorherige Programm auf und bindet eine weitere Bibliothek für den FT857 [4] mit ein. Sie stammt von James Buck, VE3BUX, und wurde vor einigen Jahren für Arduino 1.0 geschrieben, funktioniert dank sauberer Programmierung in C++ heute noch fehlerfrei mit der hier benutzten Version der Arduino-Entwicklungsumgebung. Neben den oben beschriebenen Anpassungen der IP-Adressen findet man innerhalb der Funktion reconnect() folgende Sequenz:
// Parameter der nächsten Zeile: ClientID, Topic, QoS, Retain, LastWill&Testament if (client.connect("arduinoClient","TRX_status",0,true,"offline")) { Serial.println("connected");
// Wenn mit MQTT-Broker verbunden, Frequenz und Status senden... // --------------------------------------------------------------- num = myFT857.getFreqMode(); Serial.print("num: "); Serial.println(num); freq = (float) num / 100000; dtostrf(freq, 3, 6, cstr); Serial.print("cstr: "); Serial.println(cstr); client.publish("TRX_Freq", cstr, true);
// Wir können auch den aktuellen Status des TRX senden... client.publish("TRX_status","online",true); }
In obigem Programmauszug geschieht folgendes: Die Verbindung zum Broker wird hergestellt mit der ClientID arduinoClient (siehe unten im Lexikon) und dem Last-Will mit dem Wert offline unter demTopic TRX_status. Ist die Verbindung erfolgreich, holt sich das Programm mit myFT857.getFreqMode() die aktuelle Rohfrequenz, bereitet sie auf, sodass diese als MHz-Wert als Zeichenkette an den Broker übermittelt wird. Das geschieht mit der Anweisung client.publish().
Da reconnect() bei jedem Schleifendurchlauf aufgerufen wird, ist das der richtige Ort, um Änderungen bei den zu übertragenden Werten vorzunehmen. Sie können diesen Abschnitt beispielsweise um einen Temperaturwert ergänzen, der unter dem Topic PA_temp an den Broker übermittelt wird. Lassen Sie ihrer Fantasie freien Lauf: welche Sensoren und Informationen möchten Sie noch veröffentlichen?
Wer bereits etwas mit dem Arduino UNO experimentiert hat, wird das Programm leicht an andere Transceiver und Sensoren adaptieren können. Sollte statt des kabelgebundenen Ethernet-Shields ein WLAN-Shield vorhanden sein, ist auch diese Hürde des Umbaus zu meistern.
IoT MQTT Panel für Android
Das Programm MQTTBox für Windows entbehrt leider einer schicken grafischen Präsentation abonnierter Daten. Da gibt es für Geräte mit Android-Betriebssystem im Google Play Store unter dem Suchwort MQTT eine breitere Auswahl. Ich habe mich für die App IoT MQTT Panel entschieden, sie geladen und installiert. Die kostenfreie Software bietet eine Reihe unterschiedlicher Darstellungsweisen abonnierter Informationen wie Linien- und Balkengrafik, Zeigerdarstellung, Textanzeige und viele weitere an. Zunächst legt man ein device an, das ich hier simpel Tablet nannte.
Bild 5: Broker-Einstellungen in der Andriod-App MQTT IoT Panel.
Bild 6: Verschiedene Darstellung der Frequenzanzeige in der App.
Anschließend richtet man eine connection ein, der man eine beliebige ClientID, die IP-Adresse des MQTT-Brokers, den Port und das Netzwerk-Protokoll mitteilt, siehe Bild 5. Zuletzt fügt man ein Panel hinzu, jedes entspricht der Darstellung eines Topic. Funktioniert der Zugang zum Broker und das Abonnement, sieht der Empfang der Frequenz in etwa so aus wie in Bild 6 zu sehen ist. Wie leicht zu erkennen ist, ist es möglich, für ein Topic (die Frequenz) mehrere Panels anzulegen.
Bild 7: Damit der DSL-Router den MQTT-Port 1883 in das Internet leitet, ist möglicherweise eine Portfreigabe nötig, wie hier auf einer FritzBox.
Möglicherweise muss, um den MQTT-Betrieb über Port 1883 zu garantieren, auf dem DSL-Router für den Arduino der Port freigegeben werden, wie hier in Bild 7 bei der FritzBox zu sehen ist.
Wer kein Android-Smartphone besitzt, findet für sein Gerät im jeweiligen Store sicherlich eine Reihe geeigneten Programme – die Hausautomatisierung liegt im Trend. Für iOS bieten sich beispielsweise die Apps MQTT Buddy oder der IoT-Manager an.
Was wäre noch möglich?
Wir haben die Frequenz per MQTT einem Broker zugesandt und jeder, der möchte, kann die Daten abrufen. MQTT bietet zwar eine Verschlüsselung an, hier wurde aber bewusst darauf verzichtet, schließlich soll diese Arduino-Bastelei auch im HAMNET mit dem dortigen MQTT-Broker anwendbar sein. Da jeder MQTT-Client sowohl Publisher als auch Client sein darf (siehe Aufmacherbild), wäre der nächste Entwicklungsschritt der, dass man am Smartphone oder Tablet die Frequenz eintippt und sie zum TRX sendet. Die beschriebene App bietet dazu eine Texteingabe an. Die dann noch fehlende Audioübertragung vom TRX zum Tablet-PC oder Smartphone müsste man jedoch separat realisieren. Auf einem Laptop oder Desktop-PC eignen sich dazu Programme wie Teamviewer etc., ein Arduino UNO ist mit der Audioübertragung leider überlastet.
Eine sinnvolle Erweiterung der hier beschriebenen Bastelei ist sicherlich die Einbindung weiterer Sensoren in das Geschehen. Das kann die Temperatur einer Endstufe oder der Zustand der PTT sein. Sicherlich, manches ist sinnfrei – doch an erster Stelle steht wohl der Spaß an der Sache.
Abseits des hier verwendeten Arduino UNO existieren zahlreiche MQTT-Lösungen für den ESP8266, einer kleinen Platine mit einem 32-Bit-Mikroprozessor mit WiFi an Board. Der ESP8266 ist Arduino-softwarekompatibel und kann mit der Arduino-IDE programmiert werden. Wer sich damit beschäftigen möchte, findet Programmbeispiele beispielsweise bei [5].
Kleines MQTT-Lexikon
ClientID Die ClientId ist eine Kennung des MQTT-Clients, der sich mit einem MQTT-Broker verbindet. Der Wert kann eine beliebige ID sein, und die ClientID sollte für den Client eindeutig bleiben. Es kann immer nur ein Client mit einer bestimmten ClientId verbunden sein. Wenn ein Client bereits verbunden ist, wird die Verbindung zu diesem Client getrennt und der neue Client erhält eine Verbindung. Die ClientId wird vom Client ausgewählt. Es handelt sich also um einen Identifikationsstring, an dem der Broker seine Clients unterscheiden kann.
Publish und Subscribe Sendet ein MQTT-Client Daten an den Broker, wird das als publish (veröffentlichen) bezeichnet. Bezieht ein Client daten vom Broker, nennt sich das im Fachjargon subscribe (abonnieren).
Topic Das ist eine Bezeichnung für Daten und zugleich ein Datenpfad. Ein Client sendet an den Broker Daten unter einem Topic. Kennt ein Client das Topic, kann er diese Daten vom Broker abonnieren. In unserem Beispiel heißen die Topics TRX_Freq und TRX_status. Die Topics darf man sich ausdenken und sollten sinnvolle Begriffe sein. Ein anderes Beispiel für ein Topic wäre haus/keller/lampe/status oder meinHaus/dachgeschoss/shack/trx/frequenz etc. Man erkennt hier, dass ein topic auch ein Pfad darstellt. Mit Hilfe der Topics lässt sich die Hausautomatisierung sinnvoll hierarchisch in einem „Baum“ abbilden, ganz ähnlich, wie wir es vom Verzeichnisbaum der PC-Festplatte kennen.
Retain Als retain – bleibend- werden Daten-Mitteilungen an den Broker bezeichnet, die er zwischenspeichert. Kommt ein Client neu auf den Broker, liefert dieser die gespeicherte Nachricht und der Client muss nicht warten, bis der sendende Client neue Daten an den Broker schickt.
Quality of Service (QoS) MQTT kennt drei Stufen der Übertragungssicherkeit, die mit 0..2 beziffert werden: 0 at most once: die Nachricht wird einmal gesendet und kommt bei Verbindungsunterbrechung möglicherweise nicht an. QoS Stufe 1 at least once bedeutet: die Nachricht wird so lange gesendet, bis der Empfang bestätigt wird und kann möglicherweise beim Empfänger mehrfach ankommen. QoS-Stufe 2 exactly once stellt sicher, dass die Nachricht auch bei Verbindungsunterbrechung genau einmal beim Empfänger ankommt. Für unsere Versuche – sie enthalten nur unwichtige Informationen – wählen wir stets QoS Stufe 0.
Last Will & Testament Während des Verbindungsaufbaus können Clients einen „letzten Willen“ bzw. ein Testament in Form einer Nachricht bestimmen. Falls die Verbindung zum Client ungerwollt verloren geht, wird dieser „letzte Wille“ publiziert und an alle Abonnenten gesendet. In unserem Beispiel besteht der „letzte Wille“ des Topics TRX_status aus dem Text „offline“. Abonniert nun ein Client den Topic TRX_status, erkennt man auf Anhieb, dass das Funkgerät aktuell nicht in Betrieb ist.