In de laatste afleveringen heb ik verschillende MQTT-clients ontwikkeld, die berichten konden verzenden en ontvangen via Internet. Ik heb daarvoor software voor de PC en voor een Android-smartphone geschreven en ook twee microcontrollerkaarten met WLAN-interface gebruikt. Als voorbeeldtoepassingen hebben we sensorwaarden verzonden en een LED geschakeld. Maar daarbij gingen de berichten elke keer van de ene MQTT-client naar de andere, alleen de MQTT-broker bevond zich „daar buiten“, in de cloud.

Na de zomerpauze willen we een grote stap vooruit zetten en eindelijk eens een platform uitproberen, waarmee we onze data in de cloud kunnen opslaan en visualiseren. Ik heb gekozen voor het portaal AllThingsTalk; niet in de laatste plaats omdat dit ook in het Artikel „GoNotify“ (Elektor september/oktober 2017) wordt aanbevolen. De Maker-Version van het platform kan na registratie gratis worden gebruikt. Het is gemakkelijk te bedienen en biedt naast veel nuttige functies ook goede documentatie.

Ik zal proberen hier kort samen te vatten, wat AllThingsTalk allemaal kan: Na registratie kunnen we op een gepersonaliseerde webpagina eigen Devices (apparaten) invoeren, waarmee we wereldwijd data willen uitwisselen. Het kunnen klassieke microcontrollerkaarten zijn, maar ook smartphones en natuurlijk single-board-computers zoals de Raspberry Pi. Aan elk device kunnen we meerdere Assets (apparaatfuncties) toewijzen. Als aan een kaart bijvoorbeeld een licht-, een temperatuur- en een vochtigheidssensor zijn aangesloten, maken we de drie assets light, temperature en humidity aan. Voor elk van deze grootheden kunnen we nu meetwaarden met verschillende tussentijden van de kaart naar de AllThingsTalk-server sturen, die ze weergeeft (in een door de gebruiker zelf vormgegeven formaat). Het werkt ook in de omgekeerde richting: zo kunnen we vanuit de webpagina I/O-pennen van de kaart schakelen en dergelijke.
 

Mijn eerste AllThingsTalk-device

De registratie gaat heel eenvoudig met een gebruikersnaam, email-adres en een zelfgekozen wachtwoord. Wie een comfortabele instap wil, schaft één van de rechtstreeks ondersteunde kaarten of internet-kits aan, maar ikzelf wilde als het even kon gebruik maken van de hardware uit de vorige aflevering. Bij het aanmaken van een nieuw Device (+ Connect a device) koos ik dus WIFI/LAN devices en dan Your own. Op de nu verschenen webpagina van het nieuwe Device, dat ik MyJourneyIoT_Sensor heb genoemd, maakte ik voor mijn tests nog een asset temperature aan (zie screenshot). Nu moest ik eigen firmware schrijven, maar dat was helemaal niet zo moeilijk als het op het eerste gezicht leek. Want, u had het waarschijnlijk al geraden, AllThingsTalk stelt een MQTT-broker ter beschikking op het Internet, waarmee ik mijn kaart als MQTT-client aan kon koppelen om berichten met meetwaarden naar het cloud-platform te versturen.

MQTT is maar een vrij simpel protocol, en ik had zelfs al een kleine MQTT-library geschreven voor de eerdere afleveringen. Het zou voldoende moeten zijn om de juiste bytes voor een MQTT-CONNECT-aanvraag en een MQTT-PUBLISH-bericht naar de AllThingsTalk-server te sturen. Na wat bestuderen van de documentatie en een beetje ge-experimenteer had ik het voor elkaar:

1. Eerst verbinding maken met de AllThingsTalk-MQTT-testbroker via TCP/IP op het adres api.allthingstalk.io, poort 1883.
2. Daarna volgt de CONNECT-aanvraag. Als MQTT Client ID geven we het Device ID van het betreffende apparaat mee. De Device ID is het laatste deel van de URL voor de device-webpagina; bij mij waren dat 23 tekens. Verder moeten we binnen de CONNECT-bytes nog een gebruikersnaam meegeven (dat had ik in mijn MQTT-library nog niet geïmplementeerd, zie onderaan). Als gebruikersnaam gebruiken we het Device Token, dat voor het authentiseren voor elk apparaat door AllThingsTalk nieuw gegenereerd wordt en te vinden is op de device-webpagina onder Settings. Verschillende MQTT-bibliotheken eisen, dat we bij het meesturen van een gebruikersnaam ook een wachtwoord meegeven. AllThingsTalk verwacht dat niet, zodat we hiervoor bijvoorbeeld gewoon „abc“ kunnen gebruiken.
3. Voor het doorgeven van een meetwaarde moeten we een PUBLISH-bericht sturen, dat natuurlijk altijd het betreffende Topic en de eigenlijke data (Payload) bevat. Het topic wordt als volgt samengesteld:
   Topic = "device/" + Device ID + "/asset/" + Asset Name + "/state"
   De Asset Name zou bij mij „temperature“ zijn.
   En dan de Payload: Om een meetwaarde over te dragen als een drijvend komma-getal, moeten we een asset van het type „number“ hebben aangemaakt. Als we de waarde „10,0“ willen verzenden, dan moeten we als Payload de volgende tekenreeks sturen:
   {"value": 10.0}

 
Sensorwaarden naar de cloud
Nu moest ik het geheel nog testen met een eenvoudige demo. Zoals al vermeld, gebruikte ik de hardware uit het vorige deel, namelijk de ESP32 DevKitC, op een klein breadboard en met een aangesloten RGB-LED. Als basis voor mijn firmware gebruikte ik de Arduino-sketch uit de vorige aflevering, inclusief de kleine TCP/IP- en de rudimentaire MQTT-library. Om te beginnen veranderde ik de functie
 
int MQTTClient_Connect(String clientid)
 
in
 
int MQTTClient_Connect(String clientid, String username, String password)

De functie kan verder ook worden gebruikt voor toepassingen, waarbij (zoals in de vorige delen) binnen de CONNECT-aanvraag geen Username/Password meegezonden hoeft te worden, dan geven we als gebruikersnaam gewoon een lege string.
 
De setup-functie bleef onveranderd: de ESP32 meldt zich aan bij het WiFi-netwerk thuis, daarna licht de LED groen op.
In de Loop-functie wordt nu in plaats van ConnectAndSubscribeToTopic() een functie ConnectToATT() aangeroepen. Hier maakt de kaart verbinding met de AllThingsTalk-broker via TCP/IP, dan volgt de CONNECT-aanvraag met de zojuist beschreven data.
 
Voor een eerste demo vond ik het voldoende om een keer per seconde een meetwaarde van een virtuele temperatuursensor te verzenden. Om meetwaarden te genereren, laat ik gewoon een teller cyclisch van 10 tot 40 omhoog tellen. Elke seconde wordt de functie
 
void SendSensorDateToATT(byte SensorDate)
 
doorlopen. Hier worden het Topic en de Payload ingevuld op de boven beschreven manier en uiteindelijk wordt de functie
 
MQTTClient_Publish(ATT_SensorTopic, MQTTClient_PayloadBuffer, Slength);
 
aangeroepen voor het verzenden van de PUBLISH-bytes.

Hoera! Het lukte (zie screenshot). Met AllThingsTalk is ook de visualisatie van (gemiddelde) meetwaarden in een diagram mogelijk, wat ik natuurlijk ook heb getest.

Als u een ESP 32 DevKitC hebt (verkrijgbaar in de Elektor-shop), kunt u dit alles natuurlijk meteen uitproberen.
 Download de Arduino-sketch en vergelijk de code eerst eens met de sketch uit het vorige deel. Voer dan in de code naast uw WLAN-SSID en het WLAN-wachtwoord (net als in de eerdere delen) ook het device ID, het Device Token en een Asset Name uit uw persoonlijke AllThingsTalk-account in in de sketch, compileer het geheel en upload het naar de kaart.
Wie al wat ervaring heeft, zal het vast ook niet moeilijk vinden, om dit alles aan te passen voor gebruik met een echte sensor, die wordt aangesloten aan de ESP 32-kaart.
 
In de volgende delen gaan we weer verder!