Hackable n°26 est chez votre marchand de journaux

Les vacances sont terminées et après un numéro d’été nous ayant envoyé dans l’espace voici que nous redescendons sur le plancher des vaches pour un sujet bien plus terre-à-terre : MQTT.

Faire communiquer ses projets n’est pas toujours chose facile même avec des fonctionnalités comme celles offertes par des plateformes telles l’ESP8266 ou Raspberry Pi. La liaison est certes facile à établir, mais l’architecture est toujours un casse-tête. Qui doit attendre les connexions ? Qui doit initier la communication ? Mes capteurs doivent-ils attendre qu’on leur demande d’agir ou régulièrement envoyer leur données ? Doivent-ils se connecter à un point d’accès Wifi ou être ce point d’accès ? Comment rendre tout cela plus stable, fiable, modulaire et sûr ?

Voici autant de questions auxquelles MQTT répondra sans le moindre problème, une fois que vous aurez assimilé ses principes de fonctionnement et son jargon. Et c’est précisément ce que le sujet principal de ce numéro de rentrée se propose de faire !

Oubliez donc la complexité de mettre en place un serveur HTTP sur vos ESP8266 ou même de composer des requêtes vers un serveur. MQTT offre une solution parfaitement adaptée avec une approche similaire à un système de messagerie ou un bus logiciel. Tous les acteurs se connectent à un élément central (le broker) et communiquent entre eux en envoyant des messages libellés avec sujet et en souscrivant aux sujets qui les intéressent.

Dans ce numéro, nous traiterons non seulement de l’introduction à MQTT avec quelques codes et configurations simples mettant en oeuvre Raspberry Pi et ESP8266, mais également d’un aspect trop souvent oublié : la sécurité (authentification et chiffrement SSL/TLS).

Et enfin, nous pousserons l’exercice jusqu’à mettre en place une interface web permettant de représenter les données graphiquement (avec Telegraf et Grafana sur Raspberry Pi).

Au sommaire de ce numéro :

  • Equipement
    • p.04 : Test du fer à souder fixe/nomade TS100
    • p.12 : Mes conseils, trucs et astuces pour des impressions 3D de qualité
  • Ardu’n’co
    • p.22 : Transformez vos vieux lecteurs de disquettes en instrument de musique
    • p.30 : Interfaçage d’une radiocommande de modélisme à un simulateur de vol
  • En couverture
    • p.24 : Faites communiquer vos projets simplement avec MQTT
    • p.60 : Sécurisez et protégez votre installation MQTT
    • p.72 : Représentez graphiquement vos données collectées en MQTT
  • Repère & Science
    • p.84 : Solar Hammer : pourquoi les tâches solaires menacent les réseaux ?
  • Retro Tech
    • p.88 : Ajouter de la mémoire à une vieille imprimante laser

Ce numéro 26 de Hackable est d’ores et déjà disponible chez votre marchand de journaux et dans notre boutique en ligne. N’hésitez pas à vous abonner à la version papier ou PDF pour ne rater aucun numéro.

Vous pouvez également accéder à l’ensemble des numéros publiés via un abonnement à notre plateforme de lecture en ligne Connect.

Voici les références de l’article « Solar Hammer » de Simon Descarpentries n’ayant pas été placées dans le magazine faute de place :

 

11 commentaires sur “Hackable n°26 est chez votre marchand de journaux

  1. Bonjour Denis. L’article sur MQTT semble intéressant et j’en commence la lecture. Malheureusement tous ces articles se servent toujours d’ondes radio (Wi-Fi, etc.). Il y a pas moyen d’utiliser des capteurs reliés via les fils du secteur par ex. Ou un autre moyen auquel je n’aurais pas pensé et sans pour autant perturber le CPL ? Si oui cela ferait un très bon article ;).

    • Bonjour,

      MQTT est prévu pour fonctionner sur TCP/IP et donc avec des liaisons Ethernet ou Wifi.
      Réimplémenter MQTT pour reposer sur un autre type de liaison n’est pas impossible, le standard lui-même n’impose pas vraiment TCP/IP, mais cela risque d’être une masse de travail conséquente.

      Ce qu’il est possible de faire, en revanche, c’est de concevoir un pont (bridge) entre un type de réseau exotique « maison » (fils, Bluetooth, liaison série, i2c, autre) et MQTT sur TCP/IP. L’idée est alors d’avoir un élément qui joue le rôle de client MQTT et qui se connecte à ce réseau (le bridge). Il relève les mesures et publie en MQTT les valeurs avec les sujets appropriés.

      Dans l’absolut, une carte Arduino Ethernet, une Pi ou un ESP8266 peut parfaitement le faire avec une série de capteurs DS18B20. Si cette plateforme est un client MQTT, il est relativement simple de « remonter » (publier) les mesures d’une demi douzaine de DS18B20. En pratique, ceci revient à créer un bridge entre MQTT et un réseau exostique qui n’est autre que le bus 1-wire.

      C’est un peu le principe de l’un des articles sur lesquels je travaille actuellement mais avec une petite nuance : utiliser une flottille d’ESP8266 en réseau mesh pour faire des mesures. Un seul de ces ESP8266 est à la fois un élément de ce réseau maillé et client MQTT. Tous les messages qu’il reçoit du réseau maillée sont alors publiés en MQTT et le reste du système fonctionne comme ce qui est décrit dans les articles du numéro 26 (Mosquito, Telegraf, Grafana). La seule différence est que seul le bridge doit être à portée du point d’accès wifi. Le réseau maillé, lui, peut s’étendre bien au delà et on peut alors couvrir une zone plus importante sans installer d’autres point d’accès wifi.

      Remplacez le réseau maillé par des connexions filaires ou autre et vous avez le meilleur des deux mondes.

  2. Bonjour,

    Bien qu’abonné, je n’ai toujours pas reçu ma revue et je n’ai donc pas pu lire l’article en question ;-(( Ma réponse est donc toute théorique.
    Sauf erreur de ma part, MQTT s’appuie sur la pile TCP/IP (comme FTP, HTTP, entre autres).
    TCP/IP ne respecte pas le modèle ISO à 7 couches mais s’en approche.
    Il n’y a donc aucune raison technique à ce que la couche physique soit imposée et MQTT est prévu pour utiliser une liaison peu fiable, à forte latence.
    En théorie, rien ne s’oppose à utiliser une liaison série avec un protocole de la famille PPP .
    La réelle difficulté sera peut-être de programmer cela sur un Arduino (ou ESP).
    Sur un Raspberry (ou SBC sous Linux), cela devrait être plus simple puisqu’on dispose même d’un port Ethernet pouvant être relié en filaire ou via CPL
    Attendons la réponse de Denis qui sera certainement instructive.

    Sylvain

    • Tout d’abord, il n’est pas normal que vous n’ayez pas encore votre exemplaire en tant qu’abonné. Il y a sans doute un problème postal et je vous recommande de contacter notre service abonné (cial@ed-diamond.com, ou 0367100020 ou via le système de messagerie de la boutique).

      Ensuite, concernant MQTT, en effet le fait de reposer sur TCP/IP n’est pas une obligation mais le standard OASIS précise cependant « The protocol runs over TCP/IP, or over other network protocols that provide ordered, lossless, bi-directional connections ».

      Il existe un autre protocole, conçu pour être le plus proche possible de MQTT mais reposant sur des liaisons non orientées connexion : MQTT-SN (MQTT for Sensor Networks). Ceci est destiné à être utilisé, par exemple, sur UDP ou ZigBee. Les spécifications sont ici : http://mqtt.org/new/wp-content/uploads/2009/06/MQTT-SN_spec_v1.2.pdf, mais il existe déjà des implémentations (https://github.com/ty4tw/MQTT-SN et https://github.com/kaz260/ESP8266-MQTT-SN-Temp sont de bonnes pistes).

      • 1) Enfin, la revue est arrivée ce jour. J’ai remonté l’information au service abonnements.
        2) Merci pour la réponse qui, ajoutée à celle directe au PO, devrait lui ouvrir des voies.

        Sylvain

  3. Bonjour Denis,

    Conernant la dernière partie du dossier sur MQTT, je me pose la question de l’apport de la solution basée sur les 3 outils (Telegraf/InfluxDB/Grafana) par rapport a une solution toute intégrée comme Cayenne MyDevice (*) que vous aviez mis en oeuvre dans le Hackable n°19 avec des modules LORA.
    Ne peut-on produire un résultat similaire (dashboard, jauge tps réel, graphiques) avec Cayenne MyDevice et ce en ligne (sans le rPI en local) sachant qu’il existe en plus nativement un plugin MQTT dans Cayenne MyDevice ?

    (*) Je ne sais pas par contre si le plugin MQTT pour Cayenne est sécurisé (authentification, TLS pour le chiffrement), avec configuration en ligne

    Meric

    • En effet il semble possible d’utiliser MQTT avec MyDevice depuis quelque temps déjà. Il existe même une bibliothèque dédiée pour ESP8266 et ESP32 : https://github.com/myDevicesIoT/Cayenne-MQTT-ESP
      Il y a une authentification par mot de passe dans l’exemple pour ESP8266 mais la bibliothèque semble utiliser « WiFiClient » et non « WiFiClientSecure », même si « CAYENNE_TLS_PORT » est défini dans « CayenneDefines.h ». Sans tester, on peut donc en conclure que l’authentfication est possible mais que SSL/TLS n’est pas utilisé. Mais il ne s’agit là que de 10 petites minutes de recherche sur le web, et il est toujours possible de modifier la bibliothèque (si tant est que mqtt.mydevices.com réponde sur le port 8883 (ce qui semble être le cas quand on fait un « echo QUIT | openssl s_client -connect mqtt.mydevices.com:8883 | openssl x509 -noout -text » sur une machine GNU/Linux)).
      Ensuite, c’est une affaire de préférence. Personnellement, je ne suis pas très fan des solutions « cloud » où mes données se baladent sur des serveurs qui ne m’appartiennent pas. C’est une question d’équilibre entre l’avantage d’une solution en ligne et la difficulté à mettre en place sa propre solution « maison » et à la maintenir.
      Là, le simple fait que l’exemple officiel proposé n’utilise pas SSL/TLS est déjà mauvais signe en ce qui me concerne, en plus du fait que MyDevice est d’une lenteur affligeante pour afficher des graphiques sur plus d’une semaine.

  4. Bonjour Denis, je ne sais pas si tu as déjà entendu parlé de ce projet, mais je pense qu’il colle parfaitement à l’esprit des articles sur le Z80 (que je suivais assidûment jusqu’à leur effroyable disparition…) :
    https://bradsprojects.com/digirule2/
    Je viens de recevoir l’objet, et on s’amuse comme un gamin qui redecouvre l’informatique.
    A+

    • Les articles sur le Z80 vont revenir. Comme dit dans le précédent édito, la voie prise a conduit à une impasse technique et la copie doit être revue de façon plus « classique ». Rien de ce qui a été appris n’est perdu, c’est juste l’approche qui doit être révisée pour laisser plus d’autonomie au Z80 (SRAM, EEPROM, circuit d’horloge, de reset et surtout exécution single-step reposant sur les signaux /M1 et /WAIT).

Les commentaires sont fermés.