Transmission de données de capteurs via internet

Posté par  . Édité par Benoît Sibaud. Modéré par Ysabeau 🧶. Licence CC By‑SA.
Étiquettes :
35
24
mai
2022
Internet

Cette dépêche passe en revue des solutions pour transmettre via internet des données de mesure issues de capteurs (domotique, machines instrumentées…).

Sommaire

1. Les besoins

  • Échanger des données de mesure entre des machines industrielles, des systèmes de domotique, des équipements pédagogiques, des logiciels, des espaces de stockage, des systèmes d’affichage (écran industriel, navigateur web, application sur smartphone…).
    Les objets connectés sont situés dans des réseaux privés distincts.

  • Les échanges de données sont faits en temps réel. Certains flux peuvent être synchronisés. Il peut y avoir besoin d’enregistrer les données avant ou/et après leur transmission.

  • Des traitements peuvent éventuellement être faits avant ou/et après une transmission :

    • Sélection (on ne transmet que les données qui changent) ;
    • Conversion des données, mise en forme, tri ;
    • Ajout d’informations (date, lieu, sujet…) ;
    • Simple affichage ou calculs, graphiques, intelligence artificielle…

Les besoins en sécurité :

  • On doit pouvoir communiquer d’un réseau à l’autre en passant les différents filtrages (pare-feu, antivirus, translation d’adresse, proxy…).

  • Les données doivent être transmises et éventuellement enregistrées avec des méthodes de chiffrement adaptées à chaque besoin de confidentialité.

  • Les flux de données doivent être surveillés (détection de panne, code malveillant).

  • Les objets connectés et les utilisateurs doivent être identifiés (qui sont-ils ?) et authentifiés (ils doivent légitimer leur demande d’accès). Les droits d’accès doivent être gérés.

  • Les données enregistrées doivent être gérées (volume, obsolescence) et sauvegardées.

  • Les applications doivent être mises à jour et sauvegardées.

  • Les données ne doivent pas être à caractère personnel (anonymisation ou pseudonymisation). Même croisées avec d’autres données, elles ne doivent pas être identifiantes. Si les données ne sont pas à caractère personnel, elles ne doivent pas non plus mettre en danger un établissement (par exemple, donner des indications sur les dates et horaires de fermeture).

2. Comparaison des protocoles de communication pour l’IoT

HTTP pourrait convenir mais il faut construire un serveur avec des API et c'est un travail de titan. Je n'ai pas trouvé de solution clé en main sous licence libre ou Open Source.

MQTT est la solution idéale. Ce protocole est simple à implémenter (80 pages de spécification) et très répandu dans tous les domaines : domotique et industrie. On le trouve intégré dans quasiment tous les produits de communication récents. Son autre avantage est qu'on ouvre toujours les sessions depuis l'intérieur du réseau privé donc normalement, on n'a pas à modifier le réseau privé pour que ça fonctionne.

AMQP est similaire à MQTT. Il est peu répandu à part dans le secteur bancaire mais il faudra surveiller son évolution. Il y a jusqu’à 3 fois plus de latence qu'avec MQTT.

OPC-UA est une solution performante pour faire communiquer des machines directement entre elles, dans un réseau privé. Il est difficile à implémenter (1 200 pages de spécification) et nécessite d'accéder depuis l'extérieur à un serveur situé dans le réseau privé, d'où sa faible utilisation, même dans l'industrie. Heureusement, on peut l’interfacer avec MQTT.

3. Le protocole de communication MQTT

Le protocole MQTT est un protocole de communication couramment utilisé dans l'internet des objets (IoT) en raison de sa simplicité, de sa basse consommation et de ses performances dans les réseaux à faible débit.

Le protocole MQTT fonctionne comme un service de messagerie instantanée, avec un système de publication de messages et d’abonnement (en anglais, « publish/subscribe » ou « Pub/Sub »).
Des logiciels « clients MQTT » se connectent à un « serveur MQTT » aussi appelé « courtier MQTT » (« MQTT broker » en anglais). Chaque client publie des messages vers le serveur, en associant un « sujet » (« topic » en anglais) à chaque message. Chaque client peut aussi s'abonner à un ou plusieurs sujets. Le serveur ne lui envoie alors que les messages associés à ces sujets :

Protocole MQTT

Les logiciels clients MQTT sont de plus en plus souvent intégrés dans les capteurs, les automates programmables industriels, les interfaces, les passerelles, les afficheurs, les logiciels… Il faut demander aux fournisseurs si la version du protocole MQTT qu’ils utilisent est la même que celle du serveur MQTT et si leur produit peut communiquer avec des serveurs MQTT publics (certains produits ne communiquent qu’avec le serveur MQTT du fournisseur).

Si le serveur MQTT intègre aussi le protocole de communication WebSocket, on peut utiliser un navigateur web pour publier et s’abonner, le navigateur web fait office de client MQTT.

Les sujets des messages sont organisés de manière hiérarchique. Exemple : gendarmerie/drone1/altitude, gendarmerie/drone1/rotor, gendarmerie/drone2/altitude. Pour recevoir les messages de tous les capteurs du drone 1, on s’abonne au sujet gendarmerie/drone1/#. Pour recevoir les messages concernant l’altitude de tous les drones, on s’abonne au sujet gendarmerie/+/altitude.

Les données transmises dans les messages MQTT sont au format « JavaScript Object Notation » ou « JSON ». Exemple de fichier JSON :

{
  "fruits": [
    { "kiwis": 3,
      "mangues": 4,
      "pommes": null
    },
    { "panier": true }
  ],
  "légumes": {
      "patates": "amandine",
      "poireaux": false
    },
    "viandes": ["poisson","poulet","bœuf"]
 }

Pour transmettre une image, il faut d’abord la transformer en texte avec un codage « base64 ». Cela augmente la taille du message de 33%.

La qualité de Service (QoS) :

Le protocole MQTT dispose d'un mécanisme de qualité de service (« Quality of Service » ou « QoS » en anglais) qui garantit la livraison des messages au client en cas de défaillance d’un appareil ou de la liaison.

Il y a trois niveaux de qualité :

  • QoS 0 « At most once » : le message n’est envoyé qu’une seule fois. En cas de défaillance, il se peut qu’il ne soit pas reçu.
  • QoS 1 « At least once » : le message est envoyé jusqu'à ce que sa réception soit garantie. En cas de défaillance, le message peut être reçu en double.
  • QoS 2 « Exactly once » : chaque message est garanti d'être réceptionné et il n’est réceptionné qu’une seule fois.

Plus le niveau de qualité est élevé, plus la charge réseau augmente.

La vérification de l’intégrité des données n’est pas prévue dans la norme MQTT. On peut éventuellement l’ajouter dans les applications utilisant MQTT (somme de contrôle).

La sécurité :

Le protocole MQTT peut s’utiliser avec le protocole de transport chiffré TLS.

Le protocole MQTT gère l’authentification des clients par mot de passe, certificat, délégation d’authentification.

Exemples de serveurs MQTT (version 5.0), sous licence Open Source :

Mosquitto : https://mosquitto.org (MQTT, MQTT + TLS, WebSocket, WebSockets + TLS). Disponible dans un boîtier sur rail DIN : https://www.directautomation.com.au/mqtt-box.html.
EMQX : https://emqx.io (MQTT, MQTT + TLS, WebSocket, WebSockets + TLS).
HiveMQ : https://hivemq.com (MQTT, MQTT + TLS, WebSocket, WebSockets + TLS).
VerneMQ : https://github.com/vernemq/vernemq (MQTT, MQTT + TLS, WebSocket, WebSockets + TLS).
KMQTT : https://github.com/davidepianca98/KMQTT (MQTT, MQTT + TLS, WebSocket, WebSockets + TLS apparemment pas disponible).
NanoMQ : https://nanomq.io

Les plateformes IoT sont des applications web qui intègrent un serveur MQTT et éventuellement d’autres serveurs de communication pour l’IoT, par exemple MQTT-SN pour les réseaux avec une mauvaise qualité de transmission. Elles permettent de gérer facilement les comptes utilisateurs, les droits d’accès des clients MQTT, de visualiser les publications et les abonnements, de paramétrer le stockage sur des bases de données locales ou distantes etc.

Plateformes IoT sous licence Open Source :

Plateformes IoT sous licences non libres (liste non exhaustive, il en existe des centaines) :

Quand on choisit une plateforme IoT, il faut vérifier qu’elle soit compatible avec les protocoles de communication qu’on utilise et qu’elle intègre ou permette de communiquer avec les services dont on a besoin (stockage, tableaux de bord, calculs…).

Des prestataires développent des plateformes IoT sur mesure :

Clients et passerelles MQTT :

La liste des clients MQTT est consultable sur https://mqtt.org/software/.
Pour écrire un client MQTT :

MQTT Websocket Toolkit permet d’utiliser un navigateur web comme client MQTT : https://www.emqx.com/en/mqtt/mqtt-websocket-toolkit

MQTT2Excel enregistre un flux MQTT dans un fichier Excel : https://github.com/gsampallo/mqtt2excel.
Streamsheets est tableur qui peut s’abonner à des flux MQTT et les afficher dans des feuilles de calcul : https://github.com/eclipse/streamsheets.
Afficher un flux de données dans LibreOffice Calc ou dans Google Sheets : https://www.mathieupassenaud.fr/iot-platform/.

ChirpStack est une passerelle LoRaWAN -> serveur MQTT : https://www.chirpstack.io. Elle est utilisée par exemple dans la passerelle 1Gate d’ATIM : https://atim.com.

Outils de test et de développement, documentation :

Serveurs MQTT de test :

MQTT Tools : https://github.com/eerimoq/mqttools
MQTT Data Generator : https://github.com/ufthelp/MQTT-Generator

Les spécifications du protocole MQTT sont publiées par l’organisme de normalisation OASIS, la dernière version est la version 5.0 : https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=mqtt
La version 3.1.1 des spécifications de MQTT est parfois complétée avec les spécifications Eclipse Sparkplug : https://sparkplug.eclipse.org.

Discussions sur le canal reddit r/MQTT : https://www.reddit.com/r/MQTT/
Discussions sur le canal IRC #mqtt : https://libera.chat

Aller plus loin

  • # CoAP

    Posté par  (site web personnel, Mastodon) . Évalué à 9.

    Pouquoi n'avoir pas cité CoAP / RFC 7252, qui est justement conçu pour cela ?

    • [^] # Re: CoAP

      Posté par  . Évalué à 5.

      Bonjour,
      Ne connaissant pas CoAP, merci pour cette découverte.
      Il se trouve que faute d'information/formation suffisante beaucoup de projets scientifiques réinventent un peu la roue à chaque fois, utilisant chacun son mongodb+API REST, influxdb, mysql+appli dédiée, ou que sais-je d'autre.
      Souvent le cahier des charges se résume à:
      Transmettre à intervalle régulier des trames de data format ascii, 1 ligne type CSV ou 1 json par capteur par unité de temps, pouvoir sécuriser la transmission (éviter de se faire vandaliser sa "base" par quelques script kiddies), collecter et aggreger les data qque part. Additionnellement développer une appli de requête/visualisation/extraction.
      Et on retrouve ça décliné en X versions, avec au final des workflows et des implémentations assez lourdes et complexes pour traiter cette problématique sur le papier assez simple.

  • # MQTT WS et chemin

    Posté par  (site web personnel) . Évalué à 5. Dernière modification le 25 mai 2022 à 08:46.

    Dans les bibliothèques/clients mqtt WS, le chemin /mqtt est parfois codé en dur (ou sinon par défaut).

    https://github.com/mqttjs/MQTT.js/issues/356
    https://stackoverflow.com/questions/46593911/change-path-of-rabbitmq-websocket-mqtt-endpoint
    …

    Un contre-exemple : http://mqttjs.github.io/mqtt-elements/

    La spécification https://docs.oasis-open.org/mqtt/mqtt/v5.0/os/mqtt-v5.0-os.html#_Toc3901285

  • # Pas mal d'erreurs dans l'article

    Posté par  . Évalué à 10. Dernière modification le 25 mai 2022 à 12:16.

    Le payload MQTT est complètement libre, ce n'est pas forcément du JSON. Tu peux y mettre du binaire (pour l'OTA ou pas) ou ce que tu veux. Tu n'es pas du tout obligé d'encoder en base64 des images pour les transmettre.

    MQTT existe en différentes version, la 3.1 et la 5 sont actuellement les plus utilisées. La version 5 permet des authentification forte (c'est à dire type Diffie Helman, sans le fâcheux username/password qui doit être stocké en dur dans le client, donc hackable facilement). Il gère également les propriétés sur chaque packet, ce qui permet de réaliser beaucoup plus de chose que la version 3.

    Pour les clients MQTT, je te recommande eMQTT5 qui est un client MQTTv5 en C++ pour l'embarqué, type ESP32, (mais fonctionnant également sur Linux / OSX / Windows) et très léger (moins de 80kB sur x86, et 17kB sur Xtensa).

    Il possède également un parseur de packet MQTT ce qui est très pratique pour déboguer une communication qui échoue.

    De plus à la différence des autres protocoles, MQTT impose au broker de stocker l'état d'un client et d'éxécuter ses dernières volontés en cas de déconnexion, ce qui est super pratique pour l'IoT (qui peut ainsi s'assurer d'avoir un status "connecté/déconnecté" fiable) et permet aussi de récupérer sa session lors d'un connexion ultérieure (pratique pour le roaming, ip changeante, etc…)

    Aucun des autres protocoles ne permet ceci (ou alors, c'est en plus, non standard).

    • [^] # Re: Pas mal d'erreurs dans l'article

      Posté par  (site web personnel, Mastodon) . Évalué à 6.

      Autre petite boulette

      ProcessOne : https://www.process-one.net/en/ejabberd/ (MQTT + XMPP + SIP).

      ProcessOne n'est pas qu'un prestataire, c'est la société qui développe ejabberd, un serveur XMPP opensource écrit en erlang.
      Personnellement, c'est ce qui fait tourner mon serveur XMPP et qui fournit depuis peu un broker MQTT pour un pote.

      C'est assez simple à installer et pas insurmontable à configurer. Pour la partie MQTT, c'est même très simple si on fait un truc open.

    • [^] # Re: Pas mal d'erreurs dans l'article

      Posté par  . Évalué à 1.

      Merci pour les informations complémentaires.
      Aurais-tu des exemples pour transmettre des images en binaire ? je n'ai rien trouvé sur le web.
      Sinon, quand tu titres "Pas mal d'erreurs dans l'article", quelles sont ces erreurs ?

      • [^] # Re: Pas mal d'erreurs dans l'article

        Posté par  . Évalué à 2. Dernière modification le 31 mai 2022 à 10:25.

        Liste des erreurs:
        1. Payload dans MQTT non typé (et pas forcément JSON)
        2. Authentification forte: à partir de MQTTv5 pour une version non basée sur utilisateur/mot de passe
        3. AMQP n'est pas similaire à MQTT. C'est un protocole de messagerie, et pas de transfert de paquets avec résilience
        4. Les versions MQTT sont rétrocompatibles car la session est taggué par la version du protocole utilisé, ce qui veut dire qu'un broker MQTTv5 peut dialoguer avec un client MQTT v3.1.1. Après, un client MQTTv5 ne peut qu'implémenter MQTTv5 et pas MQTTv3.1.1 (principalement pour des raisons de ressources, pas de difficultés particulières pour supporter une version précédente). Les brokers MQTTv3.1.1 uniquement sont de plus en plus rares et difficilement gérable pour une flotte IoT.
        5. MQTT est n'est pas un service de messagerie (car il ne stocke pas les messages, tout au plus le dernier). C'est un service de transfert de paquets avec résilience (c'est à dire avec des garanties sur la livraison d'un paquet et ou d'un état d'un système).

        Une des avancées majeure de MQTTv5 c'est la possibilité ajouter des propriétés aux paquets. Dans ces propriétés, on trouve la possibilité de déclarer la taille maximale d'un paquet que le client déclare supporter (contrairement à MQTT v3.1.1 qui autorisait un paquet de 250Mo à transiter), mais également les méthodes d'authentifications supportés (type négociation SSH), le type des données transmises, etc…

        Pour envoyer une image, il suffit simplement de définir le payload sur les octets de l'image encodée. Soit tu décides que le topic/sujet sur lequel tu envois ces paquets est associé à un type MIME et dans ce cas, c'est fini, soit tu autorises différents type et dans ce cas, tu ajoutes une propriété Content Type avec le type MIME (de telle façon à ce que le client puisse décoder le flux).

  • # En restant local, et sans sécurité… OSC

    Posté par  (site web personnel) . Évalué à 5.

    La façon d'identifier les messages m'a fait penser à Open Sound Control, bien plus léger, mais avec nettement moins de fonctionnalités (c'est plus une évolution du standard MIDI pour la transmission d'événements dans un cadre musical). Pour un proto ou une maquette, c'est probablement plus facile à mettre en œuvre.

    Quand j'ai eu à jouer avec, j'avais fait Osc4py3.

    Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN

    • [^] # Re: En restant local, et sans sécurité… OSC

      Posté par  . Évalué à 1.

      Merci pour le lien et le rapprochement. Je suis un peu hors sujet, mais j'ai découvert ce protocole il y a peu en cherchant si il existait une bibliothèque générique utilisant les fonctions des DSP pour de la génération de son. Un oscillateur. J'ai surtout vu des post-traitements. C'est un peu dommage de générer au CPU les sons alors que des processeurs spécialisés sont à portée de main sur la quasi-totalité des machines.

      Certains m'ont prétexté que ça prend très peu de CPU, mais c'est toujours un peu inutile d'utiliser les ressources (bien plus consommatrices) d'un cpu, généraliste, quand un processeur spécialisé peut faire la tâche plus efficacement. Et c'est pas une mince affaire lorsqu'on fait des montages audio complexes dans des logiciels dédiés, ou bien dans tout ce qui est émulateur de console de jeu par exemple. Dans ce deuxième cas on n'imaginerais pas ne pas utiliser l'accélération du processeur graphique afin d'avoir plus de ressources processeur principal disponible dans l'émulation du processeur de la console.

  • # Coquille

    Posté par  . Évalué à 2.

    Quelqu'un pourrait-il corriger :
    est une solution performant -> est une solution performante

  • # Le pénible de service

    Posté par  . Évalué à 6.

    Super journal, je vous fais juste un commentaire rapide concernant les données, en particulier celles qui seraient générées dans un cadre PROFESSIONNEL (toute ressemblance serait fortuite …). Une donnée toute bête comme celle d'un capteur de température d'ambiance peut paraitre innocente mais elle peut avoir une certaine confidentialité (notons là de 1 à 4 pour faire comme l'ANSSI).

    Parfois, c'est la corrélation de plusieurs données qui peut se traduire un certain niveau de confidentialité. Sur tous ces sujets, AVANT de balancer quelques téras de données dans un cloud américain (ou chinois, ou français pas bien géré), il est de bon ton de contacter vos RSSIs et vos architectes préférés pour leur expliquer ce que vous voulez faire, pourquoi et comment, et rassurez vous ils sont aussi passionnés que vous par l'IIoT, le cloud computing, le big data, le HPC, l'IA et tutti frutti, ils vous aideront à trouver les meilleures solutions.

    Si ces sujets vous intéressent, vous pouvez aller regarder ce qui se discute ici dans le projet ATLAS.

    PS : Si les capteurs sont installés dans votre serre PERSONELLE dans laquelle poussent des plantes vertes, des agrumes et autres solanacées bizarres, vous pouvez envoyer vos données chez Amazon ou AliBaba, vous ne risquez pas d'être convoqué par le "pénible de service", mais vous pouvez vous poser la question de la confidentialité que vous souhaitez associer à votre consommation électrique ou votre consommation d'eau.

    • [^] # Re: Le pénible de service

      Posté par  . Évalué à 1.

      En effet, un relevé de mesures peut par exemple renseigner sur l'occupation des lieux et faciliter un cambriolage. Il faut donc penser à anonymiser/pseudonimiser et aux croisements avec d'autres données.

    • [^] # Re: Le pénible de service

      Posté par  (site web personnel) . Évalué à 5.

      La nature du capteur/objet connecté joue beaucoup sur l'importance de la donnée associée : compteur d'eau/électricité/gaz/…, sextoy, chauffage, équipement médical, véhicule / objet mobile (conteneur, camion, etc.), serrure / alarme, température d'un appartement ou d'une chambre froide, éclairage public ou privé, etc.
      Ainsi que la capacité ou non à agir sur le capteur / objet : mise à jour de firmware, réglage de température / débit / …, (dé)verrouillage, etc. Et plus largement sur une flotte d'objets : réaction du réseau si les capteurs remontent une consommation d'eau/électricité/… extrêmement forte ou faible, bouchons virtuels en trichent sur les géo-localisation, génération d'alertes intempestives, etc.
      Ce n'est déjà pas facile d'envisager tous les aspects d'un ordinateur, mais c'est encore plus difficile s'il devient quasi invisible / oublié, très nombreux, répartis partout y compris des endroits inaccessibles, sans mises à jour ou sans sécurité prévue, d'une grande diversité.
      En tout cas, professionnellement, y a du boulot…

      • [^] # Re: Le pénible de service

        Posté par  . Évalué à 1.

        En général, il vaut mieux mettre tous les appareils IoT/M2M dans un sous-réseau (VLAN) et avoir une personne dédiée pour les gérer.

  • # http et websocket et WoT

    Posté par  (site web personnel) . Évalué à 1.

    Les travaux du W3C avec les specs WebOfThings TD, mériteraient une reference, egalement le projet webthings.io.

    Quelques refs pour les curieux:

    https://rzr.github.io/rzr-presentations/docs/webthings

    Et aussi OCF/Iotitivy aussi pour la surcouche sur CoAP…

    gpg:0x467094BC

  • # Télémétriques?

    Posté par  (site web personnel) . Évalué à 3.

    Pourquoi ne pas utiliser une solution de télémétrie ? Il y a par exemple collectd, grok, le protocole de prometheus… L'avantage c'est de pouvoir les brancher à des outils de visualisation existant comme Grafana.

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Télémétriques?

      Posté par  (site web personnel) . Évalué à 4.

      MQTT est un bus message sur lequel tu interconnectes un peu comme tu veux les flux et peut ainsi avoir des "triggers" maison. À coup de serpes, c'est un service XMPP ultra simplifié ! C'est standard et fonctionne dans l'embarqué sur un Arduino. La question serait plutôt de savoir pourquoi les outils de télémétrie n'utilise pas MQTT ?

      • [^] # Re: Télémétriques?

        Posté par  (site web personnel, Mastodon) . Évalué à 2.

        Les uns font de la mesure (métrie) à distance (télé)… les autres font de la diffusion aux abonnés (concept de subscrivers fait la différence d'avec le simple broadcast) Ce n'est pas du tout pareil et les messages brokés ne sont pas orcément des métriques ni n'ont vocation à être stocké+affiché-en-graphes. Mais je suis d'accord avec toi que ces outils auraient pu utiliser MQTT sauf si leur conception est fondamentalement foireuse.

        “It is seldom that liberty of any kind is lost all at once.” ― David Hume

  • # Un peu sceptique...

    Posté par  . Évalué à 2.

    C'est vrai qu'en domotique, MQTT fait une percée remarquée: On passe en fait de solutions bien intégrées (Domoticz en était un bon exemple) via des bibliothèques gérant des protocoles différents avec toute la configuration au même endroit, des bugs faciles à tracer, zéro problème de versions vu le monolithisme… a un truc éclaté, plus difficile à installer/configurer (pour ce dernier point, la découverte automatique entends le solutionner mais se révèle en pratique peu fiable): Broker MQTT (dans la bonne version), plugins s'y interfaçant (souvent en python, un langage en train de très mal tourner et pot de pus croissant à chaque changement de sous-version) côté applicatif domotique ET gestion d'un protocole domotique particulier (zwave, zigbee…) de l'autre côté du broker MQTT, idéalement écrits dans des langages absolument pas faits pour contrôler du matériel et rajoutant une couche d'interpréteur (JS pour ce qui remplace openzwave lâché par son unique mainteneur il y a 1 an 1/2 par exemple). Youpiii, c'est beau le progrès!
    Bref, on rajoute 3 étages de machins et leurs dépendances avec souvent des pb de versions qui tournent au cauchemar quand on doit unifier sous la bannière mqtt plusieurs protocoles différents: Au final on duplique tout dans les versions qui "tombent en marche" dans des docker que l'on doit faire causer ensemble…
    De quoi donner envie de tout bazarder!

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.