Dans l'épisode précédent de Mon voyage dans le nuage IoT, j'avais porté ma minibibliothèque de publication de messages MQTT sur la carte Pretzel. Celle-ci réunit un ATmega328 et une puce WLAN ESP8266 (Wireless LAN ou réseau local sans fil). Je n'avais pas encore écrit de routine de gestion des erreurs. Pour la rendre plus autonome, j'ai ajouté une LED RGB et un phototransistor sur la carte de mon capteur autonome.
Nous avons constaté que l'ATmega est facile à programmer avec l'IDE d'Arduino et que des commandes ASCII simples permettent de piloter l'ESP8266, par exemple pour se connecter sur un réseau WLAN, pour communiquer via un serveur TCP et pour y envoyer des caractères. Grâce aux fonctions (TCPClient_Connect, TCPClient_Close, TCPClient_Send) de ma minibibliothèque TCP Arduino, les commandes ASCII correspondantes sont élaborées puis envoyées à l'ESP8266. Pour la bibliothèque TCP, j'ai pu reprendre presque à l'identique les fonctions de ma bibliothèque MQTT rudimentaire version PC.

Pour les essais, j'avais imaginé une application toute simple. À la mise sous tension, l'ESP8266 se connecte à mon réseau sans fil privé ; une LED raccordée à la carte s'allume. J'actionne un bouton également câblé sur une plaque d'essai, l'ESP8266 communique avec mon serveur d'essai HiveMQ dans le nuage via TCP. Ensuite, la commande de connexion MQTT est envoyée via TCP, suivie par la commande MQTT de publication. Comme message MQTT, j'avais juste utilisé le texte Button (plus un chiffre), et comme Topic (= sujet), /ElektorMyJourneyIoT/TestTopic/test. Le résultat était vérifiable à volonté à l'aide d'un client MQTT.

Il y a deux semaines, quand je me suis mis au travail pour préparer le présent épisode, plus moyen d'obtenir ce résultat. J'ai rapidement compris que l'adresse IP du serveur d'essai avait changé. Tout s'est remis à fonctionner quand, dans mon croquis Arduino, j'ai remplacé l'IP 52.29.193.216 par l'URL broker.hivemq.com.

Ce qui manquait encore totalement est la gestion des erreurs – la LED s'allumait même si le SSID et le mot de passe (présents dans le code Arduino) étaient incorrects et que, par conséquent, la carte ne pouvait pas se connecter à mon réseau sans fil. J'ai remplacé la LED monochrome par une LED RVB du Maker Kit afin de pouvoir l'allumer en rouge en cas d'échec et en vert en cas de réussite. D'après son manuel, la bibliothèque de la carte Pretzel contient une fonction pratique permettant de détecter les messages ASCII retournés par l'ESP8266. Outre quelques autres caractères, ce dernier envoie le texte « ERROR » lorsque la commande provenant de l'ATmega ne peut pas être exécutée correctement et « OK » dans le cas contraire. La chaîne

Boolean success = esp8266.findUntil(“OK“, “ERROR“);

intime à l'ATmega l'ordre d'attendre jusqu'à ce que l'ESP8266 lui renvoie « OK » ou « ERROR » (ou jusqu'à la fin d'une temporisation TimeOut réglable). J'avais négligé cette précaution élémentaire dans la première version du programme qui se contentait de stipuler un délai d'attente.

C'est ce que je pensais en tout cas. Car lorsque j'ai voulu coder la fonction dans la routine Setup de mon croquis pour signaler les erreurs de connexion sur le réseau sans fil, j'en ai eu pour une bonne heure d'essais infructueux. La LED verte s'allumait à chaque fois, indépendamment du mot de passe que j'indiquais. Pourquoi, après la commande de connexion, l'ESP8266 renvoyait-il systématiquement OK ? Je me suis finalement aperçu que le traitement de la réponse à la commande précédente n'était pas encore clos lors de l'envoi d'une nouvelle commande. Une simple instruction d'attente a résolu ce problème.

Nous voici sur la voie de la réalisation d'un capteur autonome. Dans le Maker Kit, on trouve un phototransistor. Sur la broche A6 de la carte Pretzel je fais numériser la tension mesurée. J'ai modifié le bouton pour passer du mode Essai au mode Capteur et vice versa, comme l'indique la LED D3 bleue de la carte. À la mise sous tension, l'ESP8266 se connecte sur le WLAN (à condition que les identifiants figurent toujours dans le code) : la LED RGB s'allume en vert. En appuyant sur le bouton, on peut maintenant passer au mode Capteur. La carte numérise alors la luminosité en continu, transforme la valeur correspondante, issue du CAN et codée sur 10 bits, en une chaîne de caractères (nombres hexadécimaux) et les envoie au serveur d'essai via MQTT sous le Topic mentionné précédemment. Ma fonction

void SendValueOverMQTT(int TenBitValue)

est par ailleurs plutôt spartiate : la communication TCP est d'abord fermée puis rétablie. J'ai également ajouté ici une routine de gestion d'erreur avec LED témoin. Lorsque la communication avec le serveur TCP ne s'établit pas, la LED RVB s'allume en rouge. Dans le cas contraire, la LED RVB s'allume en jaune (rouge + vert) ; ensuite, les commandes MQTT sont envoyées. La LED RVB repasse alors au vert (je garde la routine de gestion d'erreur MQTT pour le prochain épisode). Le système diffuse ensuite une nouvelle mesure. On revient au mode Essai en appuyant de nouveau sur  le bouton (le maintenir enfoncé jusqu'à ce que la LED D3 de la carte s'éteigne). Dans ce mode, on peut piloter facilement l'ESP8266 depuis un programme de terminal.

Vous trouverez mon code en téléchargement – en même temps qu'une version du client d'essai MQTT adaptée pour la réception des mesures sur PC (il suffit de saisir « TestTopic » dans la boîte de texte intitulée Topic to subscribe). Pour vous permettre de mieux comparer ce code à celui de l'épisode précédent, je n'ai pas cherché à le structurer pour l'instant. J'y reviendrai, de sorte que cette petite application de référence sera plus facile à adapter à une autre carte.
La suite au prochain épisode !