Glossaire
IoT : internet des objets ou en anglais, « Internet of Things ». Interconnexion d’objets aux usages variés comme l’e-santé, la domotique, la télégestion, via un réseau public (internet, téléphonie mobile, radio, satellite).
Réseau local (« Local Area Network » ou « LAN » en anglais) : réseau permettant à des machines de communiquer entre elles sans passer par un réseau public.
Réseau privé : réseau informatique local dans lequel on attribue une adresse IP privée à chaque machine et une adresse IP publique à chaque entrée du réseau. Les adresses IP privées ne sont pas accessibles directement depuis internet ou depuis un autre réseau privé. Suivant la norme IPv4, deux machines situées dans des réseaux privés différents peuvent avoir une adresse IP privée identique. Suivant la nouvelle norme IPv6, chaque machine a une adresse IP privée unique.
Translation d’adresse réseau (« network address translation» ou « NAT » en anglais) : on fait correspondre l’adresse IP privée d’une machine avec une adresse publique de son réseau, afin de pouvoir communiquer avec cette machine depuis un autre réseau.
Pare-feu (« firewall » en anglais) : logiciel de sécurité permettant de définir quels types de communication sont autorisés dans un réseau. Il filtre les flux de données entre les différentes zones d’un réseau privé et entre ce réseau privé et d’autres réseaux.
Passerelle (« gateway » en anglais) : dispositif permettant de relier deux réseaux informatiques de technologies différentes.
Navigateur web : logiciel permettant de communiquer avec un serveur web, en utilisant le protocole de communication HTTP. Le navigateur web demande des pages au serveur web, il les reçoit et les affiche. Il envoie au serveur web les données saisies dans les formulaires et permet d’échanger des fichiers avec le serveur web.
Exemples de navigateurs web : Firefox, Chrome, Edge, Opera…
Avec le protocole de communication WebRTC, les navigateurs web permettent aussi de faire de la visioconférence, des discussions instantanées et de l’échange de fichiers. On n’a plus besoin d’installer sur son ordinateur un logiciel dédié à ces usages.
API (« programmable logic controller » ou « PLC » en anglais) : automate programmable industriel.
Les objectifs
- Faire des mesures sur un système (capteurs), transmettre les données par internet, réseau cellulaire, satellite… et les afficher en temps réel (tableau de bord, synoptique, alertes…).
- Stocker les données et les analyser (calculs, graphiques, apprentissage automatique…) pour améliorer le système (économie d’énergie, maintenance prévisionnelle, amélioration de la production…). Les données partagées sous licence Open Data peuvent être utilisées pour améliorer d’autres systèmes.
- Commander le système à distance par internet, réseau cellulaire, satellite…
Le système peut être une machine industrielle, un banc d’essai, un lieu (bâtiment, jardin…).
Des traitements peuvent éventuellement être faits avant une transmission de données :
- Sélection (on ne transmet que certaines données ou que les données qui changent) ;
- Conversion de données, mise en forme, tri ;
- Ajout d’informations (date, lieu, sujet, fichiers…) ;
- Combinaison de données, calculs.
Les besoins en sécurité :
- 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.
- On doit pouvoir transmettre les données d’un réseau à l’autre en passant les différents filtrages (pare-feu, 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 données enregistrées doivent être gérées (volume, obsolescence) et sauvegardées.
- Les données ne doivent pas être à caractère personnel (anonymisation ou pseudonymisation, champ de vision des caméras limité, floutage des corps et des visages). Même croisées avec d’autres données, elles ne doivent pas être identifiantes. Elles ne doivent pas non plus mettre en danger des personnes ou des biens, par exemple en donnant des indications sur les dates et horaires de fermeture.
- Les applications doivent être mises à jour et sauvegardées.
Étude comparative de protocoles de communication pour l’IoT
Protocole |
Connexion entrante1 |
Avantages |
Inconvénients |
Données transmises |
NON |
Intégré dans les navigateurs web. |
Chacun crée ses interfaces (API), incompatibles entre elles. Peu de standards à part OpenAPI. Peu d’applications dans l’IoT, à part WebThings. |
Tout type de données mais flux audio/vidéo segmenté. |
|
OUI (serveur dans réseau privé) |
Performant pour faire communiquer directement deux machines au sein d’un même réseau (« Machine to Machine » ou « M2M » en anglais). On peut l’interfacer avec MQTT : Open Automation Software, Frankenstein Automation Gateway, OPC Router (distribué en France par M.A.C. Solutions)… |
Compliqué à implémenter (des milliers de pages de spécifications). |
Tout type de données sauf flux audio/vidéo. | |
MQTT |
NON |
Performant pour l’IoT, simple à implémenter. Peut être encapsulé dans WebSocket. Très répandu. |
|
Tout type de données (texte, image en binaire ou en base64…) sauf flux audio/vidéo. |
OUI si serveur côté capteur |
Similaire à HTTP. Conçu pour les réseaux radio. |
Peu d’applications dans l’IoT, à part IoTivity. |
|
|
WebSocket |
NON |
Intégré dans les navigateurs web. Flux bidirectionnel. La connexion entre le client et le serveur est maintenue jusqu’à ce qu’elle soit interrompue par l’un des deux. |
Sera remplacé par WebTransport, basé sur HTTP/3 et QUIC ? |
Tout type de données. |
1 Connexion entrante : cela nécessite la mise en place de moyens de sécurisation du serveur situé dans le réseau privé (isolation, filtrage des flux…), en plus du paramétrage d’un routeur, d’un pare-feu, voire d’un proxy. Il vaut mieux utiliser un protocole avec une connexion sortante, vers un serveur situé en dehors du réseau privé. Dans le doute, demandez à votre service informatique.
Le protocole de communication MQTT
Le protocole MQTT2 est un protocole de communication couramment utilisé dans l’IoT en raison de sa simplicité, de sa basse consommation et de ses performances dans les réseaux à faible débit.
C’est un protocole de messagerie, avec un système de publication 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 lui transmet alors tous les messages associés à ces sujets.
Les clients MQTT sont de plus en plus souvent intégrés dans les capteurs, les API, les passerelles réseaux, les afficheurs, les logiciels… :
Les sujets des messages sont organisés de manière hiérarchique. Exemple : maintenance/drone1/altitude, maintenance /drone1/rotor, maintenance/drone2/altitude. Pour recevoir les messages de tous les capteurs du drone 1, on s’abonne au sujet maintenance/drone1/#. Pour recevoir les messages concernant l’altitude de tous les drones, on s’abonne au sujet maintenance/+/altitude.
Les données transmises dans les messages MQTT sont généralement 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"]
}
Mais on peut aussi transmettre tout type de données avec MQTT : booléenne, numérique, texte, binaire.
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 après une transmission n’est pas prévue dans la norme MQTT. On peut éventuellement l’ajouter dans les applications utilisant MQTT.
La sécurité :
Le protocole MQTT peut s’utiliser avec le protocole de transport chiffré TLS. Il gère l’authentification des clients par identifiant/mot de passe, par certificat, ou par délégation d’authentification.
Utilisez des logiciels et du matériel qui implémentent la dernière version du protocole MQTT et qui sont régulièrement mis à jour.
La gestion d’un parc hétérogène d’objets connectés peut générer une charge de travail supplémentaire pour le service informatique : mises à jour des systèmes, des logiciels et des micro-codes, renouvellement des certificats de chiffrement, surveillance des flux, alertes… Il vaut mieux isoler les objets connectés dans un réseau séparé pour les protéger des attaques locales, surtout si les objets connectés sont des machines pouvant présenter un danger physique. Il faut éviter d’installer un point d’accès Wi-Fi dans ce réseau ou sinon, il faut le sécuriser et le surveiller.
Serveurs MQTT et plateformes IoT :
Les plateformes IoT sont des applications web qui intègrent plusieurs outils pour l’IoT : un serveur MQTT, une gestion des publications et des abonnements MQTT, le stockage dans des bases de données, une gestion des comptes utilisateurs et des droits d’accès, l’affichage des données (freeboard, Grafana, Chart.js, Vega, Discovery…), etc.
Serveurs MQTT et plateformes IoT sous licence libre ou sous licence Open Source :
- ActiveMQ Artemis : serveur MQTT 5.0, MQTT + TLS, WebSocket. QoS 0, 1 et 2.
- Aedes : serveur MQTT 3.1.1, MQTT + TLS, WebSocket. Intégré dans le socle d’applications Kuzzle qui permet de développer une plateforme IoT sur mesure. Kaliop (Paris et Montpellier, France) loue la version hébergée de la plateforme IoT Kuzzle PaaS.
- Amlen : serveur MQTT 5.0.
- ejabberd : serveur MQTT 5.0, MQTT + TLS, WebSocket, WebSocket + TLS, serveur XMPP et service SIP. ProcessOne (Paris, France) développe et intègre ejabberd et loue la version hébergée Fluux.
- Emitter : serveur MQTT, WebSocket, TLS. Messages texte et binaire. Misakai (Irlande) loue la version hébergée Emitter Cloud.
- EMQX : serveur MQTT 5.0, MQTT + TLS, WebSocket, WebSocket + TLS, QUIC. EMQ (Chine) loue la version hébergée EMQX Cloud et offre un serveur de test.
- FlashMQ : serveur MQTT 5.0, WebSocket. QoS 0, 1 et 2.
- HiveMQ Community Edition : serveur MQTT 5.0, MQTT + TLS, WebSocket, WebSocket + TLS. HiveMQ (Allemagne) loue la version hébergée HiveMQ Cloud, avec un accès gratuit pour 100 clients MQTT, une taille de message jusqu’à 5 Mo, un maximum de 10 Go de données stockées pendant 3 jours.
- KMQTT : serveur MQTT 5.0, MQTT + TLS, WebSocket, WebSocket + TLS.
- MCloudTT : serveur MQTT 5.0. TLS, WebSocket.
- Mosquitto : serveur MQTT 5.0, MQTT + TLS, WebSocket, WebSocket + TLS, serveur de test gratuit. Cedalo (Allemagne) loue la version hébergée MQTT Broker. 84code (Suède) loue la version hébergée CloudMQTT.
- MQTT server : serveur MQTT 5.0, MQTT + TLS, WebSocket, WebSocket + TLS.
- NanoMQ : serveur MQTT 5.0, MQTT + TLS, WebSocket, WebSocket + TLS.
- NATS : système de messagerie proposant notamment MQTT 3.1.1, QoS 0 et 1 (pas de QoS 2). Intégré dans la plateforme IoT Mainflux : MQTT + TLS, WebSocket, stockage dans Cassandra, MongoDB, InfluxDB ou PostgreSQL, affichage avec Grafana, langage Golang. Mainflux Labs (Serbie) propose une offre d’intégration. Mainflux est conçue pour fonctionner sous forme de services cloud.
- Plateforme IoT Openremote. Une offre d’intégration (USA, Pays-Bas) est proposée.
- Plateforme IoT TagoIO (USA).
- ThingsBoard (développement en Ukraine) : plateforme IoT avec serveur MQTT, MQTT + TLS. Une version prête à l’emploi (USA) est proposée, avec une offre à $10 / mois, suffisante pour être utilisée dans un cadre pédagogique.
- VerneMQ : serveur MQTT 5.0, MQTT + TLS, WebSocket, WebSocket + TLS. QoS 0, 1 et 2.
Serveurs MQTT et plateformes IoT sous licence non libre (liste non exhaustive, il en existe des centaines) :
- Plateforme IoT AskSensors (Épinay-sur-Seine, France). Offre à $9 / mois, suffisante pour être utilisée dans un cadre pédagogique.
- Plateforme IoT Braincube (Issoire, France).
- Plateforme IoT pour la mesure d’énergie Easy-live (Geispolsheim, France).
- Plateforme IoT pour la mesure d’énergie Ecolight de Becomanager (Maxéville, France).
- Plateforme IoT INGELI (Brignais, France).
- Plateforme IoT InUse (Boulogne-Billancourt, France). Serveur MQTT 3.1.1 RabbitMQ.
- Plateforme IoT JUMO Cloud (Metz, France).
- Serveur MQTT Live Objects d’Orange (France). WebSocket, 2/3/4G, LTE-M, NB-IoT, satellite Kineis.
- Plateforme IoT Orisun IoT (Strasbourg, France). Intègre des vues 360° et des environnements 3D fournis par Almédia (Strasbourg, France) et AureXus (Sainte-Gemmes-sur-Loire, France). Serveur MQTT Mosquitto (migration prévue vers VerneMQ).
- Plateforme IoT SCorp-io (Paris, France). Fourniture en option de la passerelle Connecter. Serveur MQTT 5.0 VerneMQ, Sparkplug B.
- Plateforme IoT ThingSpeak de MathWorks, éditeur de MATLAB et Simulink. Offre gratuite, suffisante pour utiliser MQTT dans un cadre pédagogique. Serveur MQTT 3.1.1.
- Plateforme IoT What is What de The WiW (Nancy, France). Affichage de données dans des vues 360° et des environnements 3D hébergés chez SBS INTERACTIVE (Nancy, France) et Okénite Animation (Troyes, France). Fourniture en option de la passerelle The WiW Box, conçue et fabriquée en Alsace. Serveur MQTT 3.1.1 (version 5.0 non testée) VerneMQ.
- Bureau d’étude Wiifor (Toulouse, France). Conception de plateformes IoT sur mesure.
Clients MQTT pour publier des messages MQTT :
- Clients MQTT sous forme de librairies dans différents langages : Client libraries.
- Logiciels intégrant un client MQTT : Tools and Applications.
- Logiciels de redirection de flux de données (programmation événementielle), intégrant un client MQTT : Kura, Flogo (rapide et léger en mémoire), Node-RED. Il existe des offres SAAS, par exemple Stackhero pour Node-RED cloud.
Pour éviter de reparamétrer tous les clients MQTT utilisés dans votre réseau local lorsque vous changez de plateforme IoT sur internet, vous pouvez installer une passerelle unique entre plusieurs objects connectés et le serveur MQTT de la plateforme IoT. Vous aurez juste à reparamétrer le client MQTT de cette passerelle. Il transmettra toutes les données regroupées dans un seul fichier JSON à la plateforme IoT. La structure du fichier JSON est spécifique à chaque plateforme IoT, il faudra aussi la modifier.
Exemples de systèmes d’acquisition de données et/ou de commande, intégrant un client MQTT ou utilisables avec un logiciel de redirection de flux de données :
- Raspberry Pi sur rail DIN : Andino, Brainboxes.
- RevolutionPi : Raspberry Pi sur rail DIN, modules d’entrées/sorties numériques et analogiques.
- ACE AUTOMATION : API avec entrées/sorties analogiques.
- ELASTEL : Raspberry Pi monté dans un boîtier. Entrées-sorties numériques, entrées analogiques, Modbus TCP, Modbus RTU, OPC UA, EtherNET/IP, Ethernet, Wi-Fi, WiFi HaLow, 4G LTE, NB-IoT.
- Industrial Shields : Raspberry Pi, Arduino, ESP32 sur rail DIN. API avec entrées/sorties numériques et analogiques.
- PiXtend de Kontron : RaspBerry Pi, Modbus RTU, Linux, CODESYS, Node-RED, entrées/sorties numériques ou analogiques.
- JUMO (usine à Metz, France) : contrôleur variTRON avec Linux, CODESYS, Node-RED, modules sorties relais, entrées/sorties numériques, entrées analogiques, régulateurs PID, variateurs de puissance.
- WAGO : contrôleur avec Linux, CODESYS, Node-RED, sorties relais, entrées/sorties numériques et analogiques, régulateur PID.
- Unipi technology : contrôleur avec Linux, OpenPLC, Node-RED, sorties relais, entrées/sorties numériques et analogiques.
- Contrôleurs M2M Control : entrées/sorties numériques et analogiques extensibles, interface de développement.
- La gamme OPTA de relais logiques pilotables, de Finder, embarque une version spécifique d’Arduino.
- Gamme groov d’Opto : interfaces d’acquisitions numérique et analogiques, contrôleur avec Linux, CODESYS, Node-RED, modules entrées/sorties numériques ou analogiques.
- ICP DAS : modules d’acquisition de données analogiques ou numériques, à combiner avec un module ou une passerelle intégrant MQTT.
- Advantech : modules d’acquisition de données analogiques ou numériques ADAM.
- Boîtiers et centrales d’acquisition de données DUNASYS pour systèmes mobiles.
- Le logiciel Tasmota pour de la mesure et du pilotage avec des microcontrôleurs Espressif.
Voir aussi dans le forum de discussion CaméX-IA la liste de fournisseurs et prestataires.
Selon l’utilisation des appareils, vérifiez la plage de tenue en température, les vitesses d’acquisition et de transmission des données, le support d’enregistrement (les cartes mémoire sont fragiles), la sauvegarde de l’heure, la gestion du changement d’heure été/hiver, les différents modes de marche et d’arrêt (sécurité).
Exemples de passerelles radio ou bus de terrain <-> Wi-Fi, Ethernet ou réseau cellulaire, intégrant un client ou un serveur MQTT, ou utilisables avec un logiciel de redirection de flux de données :
- Zigbee2MQTT est une passerelle logicielle Zigbee -> Ethernet ou Wi-Fi. Voir les vidéos de Néodyme sur sa chaîne Youtube.
- OpenMQTTGateway est une passerelle logicielle infrarouge, Bluetooth Low Energy, radio 315/433/868 MHz, LoRa, RS-232 <-> Ethernet, Wi-Fi, GSM/GPRS, pour microcontrôleurs.
- EnOcean IoT Connector est une passerelle logicielle EnOcean -> Ethernet ou Wi-Fi.
- Jitter (Pays-Bas), LiQuiBit (Belgique) et WizziLab (France) conçoivent des capteurs et proposent des passerelles DASH7 -> Ethernet ou Wi-Fi. La modulation LoRa peut éventuellement être ajoutée sur ces produits pour augmenter la portée de la transmission.
- ChirpStack est une passerelle logicielle LoRaWAN -> Ethernet ou Wi-Fi. Elle est utilisée par exemple dans la passerelle LoRaWAN d’ATIM.
- Hub de Wattsense (filiale de Siemens) est une passerelle LoRaWAN, BACnet, Modbus RTU, Modbus TCP, KNX, M-Bus, Diematic ou LonWorks en entrée et BACnet IP, Modbus TCP, Ethernet ou 4G en sortie. Vendue par Siemens sous le nom de Connect Box.
- NEXCOM propose une passerelle RS232/RS485/LoRa -> Ethernet et des convertisseurs Modbus RTU -> Modbus TCP, RS232/RS485 -> LoRa, etc. NEXCOM propose aussi des systèmes de communications en MQTT ou OPC UA avec des robots industriels.
- Passerelles Modbus TCP, Modbus RTU <-> Ethernet/2G/3G/4G/5G de Teltonika Networks.
- ADFweb.com propose tot type de passerelles.
- Passerelles Modbus TCP, Modbus RTU <-> Ethernet d’ICP DAS.
- Passerelle Modbus RTU <-> Wi-Fi de Friendtrol.
- Passerelles Modbus RTU ou TCP <-> Ethernet de Moxa.
- Passerelle Weintek avec plus de 300 protocoles supportés <-> Ethernet ou Wi-Fi.
- Agate de Bevywise est une passerelle logicielle Modbus TCP, Modbus RTU <-> Ethernet ou Wi-Fi.
- Passerelle Modbus <-> Ethernet, Wi-Fi, LoRaWAN, 4G LTE ou NB-IoT de Firefly.
- Passerelles Modbus TCP, HART, PROFIBUS, PROFINET <-> Ethernet (OPC UA et MQTT) d’Industrial.
- Passerelles Modbus TCP et différents API (Beckhoff, Mitsubishi, Modicon, Phoenix Contact, Rockwell Automation, Schneider Electric, Siemens, Wago…) <-> Ethernet (OPC UA et MQTT) de Softing Industrial Automation.
- Serveur BACnet ou unité modulaire de gestion locale BACnet de SAUTER, avec passerelle BACnet <-> Ethernet.
- Anybus et Ixxat de HMS NETWORKS sont des passerelles Modbus RTU, Modbus TCP, PROFIBUS, PROFINET, CANopen, EtherCAT, CC-Link, PowerLink, InterBus… <-> Ethernet (OPC UA et MQTT).
- Passerelles Hilscher, NetModule, CloudGate d’OPTION, Multi-Tech Systems, InHand…
- FreeWave Edge est une passerelle logicielle Modbus TCP, Modbus RTU, Bluetooth et autres protocoles <-> Ethernet, Wi-Fi, radio 900 MHz ou satellite.
- Passerelle logicielle API Siemens, API Allen Bradley, OPC UA, Modbus ASCII, Modbus RTU ou Modbus TCP <-> Ethernet ou Wi-Fi : Open Automation Software. Peut s’utiliser avec Node-RED.
- Neuron est une passerelle logicielle avec plus de 20 000 protocoles supportés dont OPC UA, MQTT et WebSocket.
- MQTT.box utilise Mosquitto pour permettre à des clients MQTT d’échanger au sein d’un réseau privé ou entre deux réseaux Ethernet.
Clients MQTT pour s’abonner à des sujets MQTT :
MQTT2Excel enregistre un flux MQTT dans un fichier Excel.
Streamsheets est un tableur qui peut s’abonner à des flux MQTT et afficher les données dans des feuilles de calcul.
Afficher un flux de données dans LibreOffice Calc ou dans Google Sheets.
PlotJuggler affiche les courbes de séries temporelles publiées en MQTT.
Si le serveur MQTT propose le protocole de communication WebSocket, on peut utiliser un navigateur web pour publier ou pour s’abonner à un flux MQTT en intégrant un client MQTT dans une page web3. Exemple de clients MQTT intégrables dans une page web :
- MQTT X Web.
- Eclipse Paho JavaScript Client, utilisé par hivemq-mqtt-web-client. Voir MQTT Web Applications: How to build your own! et How to make MQTT web app using HTML and Javascript.
- MQTT.js
Des applications Android permettent de développer facilement des interfaces pour publier ou s’abonner à des flux de données MQTT. Vous pouvez aussi développer une application web ou pour smartphone avec MIT App Inventor, Flask.
Normes, outils de test :
Les spécifications du protocole MQTT sont publiées par l’organisme de normalisation OASIS. MQTT for Sensor Networks (MQTT-SN) est une version de MQTT adaptée aux réseaux de capteurs sans fil.
Les spécifications de MQTT peuvent être complétées avec les spécifications d’Eclipse Sparkplug.
MQTT Tools.
MQTT Data Generator.
MQTT Message Editing Suite, un éditeur de messages MQTT.
Magazines, sites web
- Hackable Magazine n°26.
- Discussions sur le canal reddit r/MQTT, sur le canal IRC #mqtt.
2 Andy Stanford-Clark (IBM) et Arlen Nipper (Arcom Control Systems) créent le protocole « MQ Telemetry Transport » en 1999 pour transmettre par satellite les données de capteurs installés sur des oléoducs. MQ faisait référence au logiciel IBM MQSeries. Le protocole a ensuite été renommé MQTT (Message Queuing Telemetry Transport).
3 Exemple d’utilisation de MQTT + WebSocket : http://steves-internet-guide.com/mqtt-websockets/
Auteur : David VANTYGHEM <david.vantyghem@ensam.eu>. Ce document est mis à disposition selon les termes de la Licence Creative Commons Attribution – Partage dans les Mêmes Conditions 4.0 International.
Image en vignette : Diversité IOT © Atomas42 / Wikimedia Commons, licence CC BY-SA 4.0.
N’hésitez pas à signaler les erreurs et à commenter cet article ci-dessous.