In den letzten Folgen habe ich mehrere MQTT-Clients verwirklicht, die über das Internet Nachrichten versenden und empfangen konnten. Ich habe hierfür Software für den PC und ein Android-Smartphone geschrieben und auch zwei WLAN-fähige Mikrocontrollerboards eingesetzt. Als Demo-Applikationen haben wir Sensorwerte versandt und eine LED geschaltet. Jedes Mal liefen die Nachrichten aber von einem der selbstgestrickten MQTT-Clients zu einem anderen, nur der MQTT-Broker befand sich „da draußen“, sprich in der Cloud.

Nach der Sommerpause wollen wir deshalb nun einen größeren Schritt vorangehen und endlich einmal eine Plattform ausprobieren, die unsere Daten in der Cloud speichern und visualisieren kann. Ich habe mir das Portal AllThingsTalk herausgesucht – nicht zuletzt weil dieses auch im Artikel „GoNotify“ (Elektor 9/10 2017) empfohlen wird. In der Maker-Version kann die Plattform kostenlos nach Registrierung genutzt werden. Sie ist komfortabel bedienbar, bringt viele nützliche Funktionen und nicht zuletzt auch eine gute Doku mit.

Hier nur in wenigen Sätzen zusammengefasst, was AllThingsTalk kann: Nach der Registrierung lassen sich auf einer personalisierten Webpage eigene Devices (Geräte) eintragen, mit denen man weltweit Daten austauschen will. Das können klassische Mikrocontrollerboards sein, aber auch Smartphones und selbstverständlich Einplatinencomputer wie der Raspberry Pi. Jedem Device kann man wiederum mehrere Assets (Gerätefunktionen) zuordnen. Falls an ein Board zum Beispiel ein Licht-, ein Temperatur- und ein Feuchtigkeitssensor angeschlossen sind, legt man die drei Assets light, temperature und humidity an. Für jede dieser Größen kann man nun Messwerte in verschiedenen Intervallen vom Board zum AllThingsTalk-Server schicken, der sie (auf einer vom User selbst gestalteten Oberfläche) darstellt. Auch die umgekehrte Richtung funktioniert: So lassen sich von der Webpage aus Board-Pins schalten und dergleichen mehr.
 

Mein erstes AllThingsTalk-Device

Die Registrierung verläuft mit Benutzername, E-Mail-Adresse und einem selbstgewählten Passwort sehr einfach. Wer einen bequemen Einstieg sucht, legt sich eines der direkt unterstützten Boards oder Internet-Kits zu; doch ich selbst wollte nach Möglichkeit die Hardware aus der letzten Folge weiter nutzen. Beim Anlegen eines neuen Devices (+ Connect a Device) wählte ich deshalb WIFI/LAN devices und dann Your own. Auf der nun erscheinenden Webpage des neues Devices, das ich MyJourneyIoT_Sensor nannte, legte ich zu Testzwecken noch ein Asset temperature an (siehe Screenshot). Jetzt musste ich eigene Firmware schreiben, doch das war gar nicht so schwierig, wie es auf den ersten Blick schien. Denn – Sie ahnen es – AllThingsTalk stellt im Netz einen MQTT-Broker zur Verfügung, mit dem sich mein Board als MQTT-Client verbinden musste, um Nachrichten mit Messwerten zur Cloud-Plattform zu übermitteln.

MQTT ist aber ein ziemlich simples Protokoll, und ich hatte ja bereits eine kleine MQTT-Library für die letzten Folgen geschrieben. Genauer gesagt müsste es reichen, an den AllThingsTalk-Server die richtigen Bytes für eine MQTT-CONNECT-Anfrage und eine MQTT-PUBLISH-Nachricht zu schicken. Nach etwas Studium der Dokumentation und ein wenig Probiererei hatte ich den Dreh raus:

1. Zuerst verbindet man sich über TCP/IP mit dem AllThingsTalk-MQTT-Testbroker unter der Adresse api.allthingstalk.io, Port 1883.
2. Danach folgt die CONNECT-Anfrage. Als MQTT Client ID gibt man die Device ID des jeweiligen Geräts mit. Die Device ID ist der letzte Teil der URL, die zur Device-Webpage gehört; bei mir waren das 23 Zeichen. Zusätzlich muss man innerhalb der CONNECT-Bytes noch einen Usernamen mitgeben (das hatte ich in meiner MQTT-Library noch nicht implementiert, siehe unten). Als Usernamen verwendet man das Device Token, das zur Authentifizierung für jedes Gerät neu von AllThingsTalk generiert wird und auf der Device-Webpage unter Settings zu finden ist. Verschiedene MQTT-Bibliotheken verlangen, dass man beim Mitsenden eines Usernamens auch ein Passwort mitgibt. AllThingsTalk wartet allerdings auf keines, so dass man hierfür zum Beispiel einfach „abc“ wählen kann.
3. Zum Übermitteln eines Messwertes muss man eine PUBLISH-Nachricht senden, die ja immer das jeweilige Topic und die eigentlichen Daten (Payload) enthält. Das Topic wird folgendermaßen zusammengesetzt:
   Topic = "device/" + Device ID + "/asset/" + Asset Name + "/state"
   Der Asset Name würde bei mir „temperature“ lauten.
   Nun zur Payload: Um einen Messwert als Fließkomma-Zahl zu übermitteln, muss man ein Asset vom Typ „number“ angelegt haben. Will man den Wert „10,0“ verschicken, so muss man als Payload folgende Zeichenkette übermitteln:
   {"value": 10.0}

 
Sensorwerte in die Cloud
Jetzt musste ich das Ganze noch mit einer einfachen Demo testen. Wie schon erwähnt, benutzte ich die Hardware aus der letzten Folge, nämlich das ESP32 DevKitC, auf einem kleinen Steckbrett und mit angeschlossener RGB-LED. Als Basis für meine Firmware verwendete ich den Arduino-Sketch aus der letzten Folge, inklusive der kleinen TCP/IP- und der rudimentären MQTT-Library. Zuerst bohrte ich die Funktion
 
int MQTTClient_Connect(String clientid)
 
auf zu
 
int MQTTClient_Connect(String clientid, String username, String password)

Die Funktion kann weiterhin auch für Applikationen verwendet werden, bei denen (wie in den letzten Folgen) innerhalb der CONNECT-Anfrage kein Username/Passwort mitgeschickt werden soll, dann übergibt man als Username einfach einen Leerstring.
 
Die Setup-Funktion blieb gleich: Der ESP32 meldet sich im heimischen WLAN an, danach leuchtet die LED grün auf.
In der Loop-Funktion wird nun statt ConnectAndSubscribeToTopic() eine Funktion ConnectToATT() aufgerufen. Hier verbindet sich das Board mit dem AllThingsTalk-Broker über TCP/IP, dann folgt die CONNECT-Anfrage mit den oben beschriebenen Daten.
 
Für eine erste Demo genügte es mir, einmal pro Sekunde einen Messwert eines virtuellen Temperatursensors zu verschicken. Um Messwerte zu generieren, lasse ich einfach einen Zähler zyklisch von 10 bis 40 hochzählen. Jede Sekunde wird die Funktion
 
void SendSensorDateToATT(byte SensorDate)
 
durchlaufen. Hier wird das Topic und die Payload entsprechend den oben geschilderten Vorgaben zusammengesetzt und schließlich die Funktion
 
MQTTClient_Publish(ATT_SensorTopic, MQTTClient_PayloadBuffer, Slength);
 
zum Versenden der PUBLISH-Bytes aufgerufen.

Hurra, es klappte (siehe Screenshot). AllThingsTalk erlaubt auch das Visualisieren von (gemittelten) Messwerten in einem Diagramm, was ich ebenfalls getestet habe.

Falls Sie ein ESP32 DevKitC besitzen (gibt es im Elektor-Shop), sollten Sie das Ganze natürlich gleich ausprobieren. Laden Sie den Arduino-Sketch herunter und vergleichen Sie den Code zuerst einmal mit dem Sketch aus der letzten Folge. Dann tragen Sie im Code neben Ihrer WLAN-SSID und dem WLAN-Passwort (so wie in den letzten Folgen) auch die Device ID, das Device Token und einen Asset Namen Ihres persönlichen AllThingsTalk-Accounts in den Sketch ein, kompilieren das Ganze und laden es auf das Board.
Wer schon etwas Erfahrung mitbringt, dem fällt es sicher auch nicht schwer, das Ganze an einen richtigen Sensor anzupassen, der an das ESP32-Board angeschlossen wird.
 
Weiter geht es in den nächsten Folgen!