publish: Broker MQTT
This commit is contained in:
Cédrix
@@ -1,20 +0,0 @@
|
||||
{
|
||||
"title": "Broker MQTT",
|
||||
"_updated_at": "2026-05-16 19:49:54",
|
||||
"slug": "broker",
|
||||
"published": true,
|
||||
"published_at": "2023-02-19 07:50",
|
||||
"category": "domotique",
|
||||
"tags": {
|
||||
"tags": [
|
||||
"Zigbee2MQTT",
|
||||
"MQTT",
|
||||
"Home Assistant",
|
||||
"Mosquitto",
|
||||
"IoT",
|
||||
"LXC"
|
||||
]
|
||||
},
|
||||
"seo_title": "",
|
||||
"seo_description": ""
|
||||
}
|
||||
@@ -1,35 +0,0 @@
|
||||
# Broker MQTT
|
||||
|
||||
Un **broker MQTT** est un serveur qui implémente le protocole MQTT et orchestre les échanges entre clients selon un modèle *publish/subscribe*. Les producteurs publient des messages sur des *topics*, et le broker se charge de les relayer aux clients abonnés à ces topics. Ce découplage entre émetteurs et récepteurs en fait une brique centrale des architectures IoT et des systèmes distribués asynchrones.
|
||||
|
||||
Pour fixer les idées, imaginons un capteur de température dans le salon. Toutes les 30 secondes, il publie sa mesure sur le topic `maison/salon/temperature` avec une charge utile minimale, par exemple `21.4`. Le capteur ne connaît ni le nombre ni l'identité des destinataires : il se contente d'envoyer son message au broker. De leur côté, Home Assistant (pour afficher la valeur sur un tableau de bord), une base de données InfluxDB (pour l'historisation) et un script de notification peuvent tous s'abonner indépendamment à ce même topic. Ajouter ou retirer un consommateur n'a aucun impact sur le capteur — c'est tout l'intérêt du découplage.
|
||||
|
||||
Les topics sont organisés en arborescence avec le `/` comme séparateur, ce qui permet de construire des hiérarchies lisibles : `maison/salon/temperature`, `maison/salon/humidite`, `maison/cuisine/temperature`, `maison/exterieur/luminosite`. Les abonnés peuvent utiliser des jokers : `+` remplace un niveau (`maison/+/temperature` capte toutes les températures, salon ou cuisine), et `#` remplace toute une sous-arborescence (`maison/#` capte tout ce qui touche à la maison).
|
||||
|
||||
## Rôle du broker
|
||||
|
||||
Au-delà du simple relais de messages, le broker assure plusieurs fonctions transverses :
|
||||
|
||||
- **sécurité** : authentification (login/mot de passe ou certificats), chiffrement TLS sur le port 8883, listes de contrôle d'accès (ACL). Par exemple, on peut autoriser le capteur du salon à *publier* uniquement sur `maison/salon/#` mais lui interdire de s'abonner à `maison/chambre/#` ;
|
||||
- **gestion des sessions** et reprise après reconnexion : si un client perd le réseau pendant deux minutes, le broker peut conserver ses abonnements et lui retransmettre les messages manqués à sa reconnexion (avec `clean_session=false`) ;
|
||||
- **gestion des abonnements** et de l'arborescence des topics, avec résolution des jokers à chaque message reçu ;
|
||||
- **qualité de service (QoS)** avec trois niveaux :
|
||||
- *0* — au plus une fois (best effort, sans accusé). Adapté à un capteur qui publie sa température toutes les 5 secondes : perdre un message n'a aucune conséquence,
|
||||
- *1* — au moins une fois (accusé de réception), avec risque de doublon. Bon compromis pour la majorité des cas, par exemple un capteur d'ouverture de porte,
|
||||
- *2* — exactement une fois (échange en quatre temps). Réservé aux messages critiques où ni la perte ni le doublon ne sont acceptables, par exemple une commande de paiement ou un ordre d'ouverture de portail ;
|
||||
- **rétention** : un message marqué *retained* est conservé par le broker et envoyé immédiatement à tout nouvel abonné. Très utile pour l'état d'un équipement — quand Home Assistant redémarre et s'abonne à `maison/salon/lampe/etat`, il récupère aussitôt la dernière valeur connue (`ON` ou `OFF`) sans attendre la prochaine publication ;
|
||||
- **Last Will and Testament (LWT)** : chaque client peut déclarer à la connexion un message que le broker publiera *à sa place* en cas de déconnexion brutale. Pratique pour signaler qu'un capteur est tombé : `maison/salon/capteur/status` passe automatiquement à `offline` si le capteur ne répond plus.
|
||||
|
||||
Un broker MQTT peut s'exécuter sur des cibles très variées — poste de travail, serveur cloud, passerelle IoT, voire un Raspberry Pi — et il existe de nombreuses implémentations, open source comme commerciales. Le choix dépend principalement de la volumétrie attendue, des exigences de sécurité et de l'écosystème cible.
|
||||
|
||||
## Quelques implémentations courantes
|
||||
|
||||
- **Mosquitto** — le broker le plus répandu dans les projets DIY et l'IoT léger ; léger, simple à déployer. Empreinte mémoire de quelques mégaoctets, configuration dans un unique fichier `mosquitto.conf`. Il tient sans problème sur un Raspberry Pi et gère confortablement quelques centaines de clients.
|
||||
- **EMQX** (ex-EMQTT) — conçu pour absorber un très grand nombre de connexions simultanées (jusqu'à plusieurs millions sur un cluster), adapté aux déploiements industriels et aux flottes de véhicules connectés. Fournit une interface web d'administration et des règles de routage avancées.
|
||||
- **RabbitMQ** — broker multi-protocoles (AMQP, MQTT, STOMP…) avec support commercial, pertinent quand MQTT cohabite avec d'autres protocoles dans un SI existant. Typiquement utilisé quand des microservices en AMQP doivent dialoguer avec des objets connectés en MQTT.
|
||||
- **ActiveMQ** — broker Apache supportant MQTT en plus de JMS et AMQP, intéressant dans un écosystème Java existant où l'on veut éviter d'introduire un nouveau composant.
|
||||
- **JoramMQ** — orienté intégration Java, plus rarement rencontré.
|
||||
|
||||
## Mon choix
|
||||
|
||||
Pour la suite, j'ai retenu **Mosquitto** pour sa légèreté, sa simplicité de configuration et sa large adoption dans la communauté IoT. Concrètement, mon installation devra gérer une poignée de clients — Home Assistant, Zigbee2MQTT, ntfy et quelques capteurs ESP — soit un volume bien en deçà de ce qu'un Mosquitto encaisse sans broncher. Il sera installé dans un conteneur **LXC** sous Debian, ce qui permet de l'isoler du reste de l'hôte tout en gardant une empreinte minimale.
|
||||
@@ -2,29 +2,34 @@
|
||||
|
||||
Un **broker MQTT** est un serveur qui implémente le protocole MQTT et orchestre les échanges entre clients selon un modèle *publish/subscribe*. Les producteurs publient des messages sur des *topics*, et le broker se charge de les relayer aux clients abonnés à ces topics. Ce découplage entre émetteurs et récepteurs en fait une brique centrale des architectures IoT et des systèmes distribués asynchrones.
|
||||
|
||||
Pour fixer les idées, imaginons un capteur de température dans le salon. Toutes les 30 secondes, il publie sa mesure sur le topic `maison/salon/temperature` avec une charge utile minimale, par exemple `21.4`. Le capteur ne connaît ni le nombre ni l'identité des destinataires : il se contente d'envoyer son message au broker. De leur côté, Home Assistant (pour afficher la valeur sur un tableau de bord), une base de données InfluxDB (pour l'historisation) et un script de notification peuvent tous s'abonner indépendamment à ce même topic. Ajouter ou retirer un consommateur n'a aucun impact sur le capteur — c'est tout l'intérêt du découplage.
|
||||
|
||||
Les topics sont organisés en arborescence avec le `/` comme séparateur, ce qui permet de construire des hiérarchies lisibles : `maison/salon/temperature`, `maison/salon/humidite`, `maison/cuisine/temperature`, `maison/exterieur/luminosite`. Les abonnés peuvent utiliser des jokers : `+` remplace un niveau (`maison/+/temperature` capte toutes les températures, salon ou cuisine), et `#` remplace toute une sous-arborescence (`maison/#` capte tout ce qui touche à la maison).
|
||||
|
||||
## Rôle du broker
|
||||
|
||||
Au-delà du simple relais de messages, le broker assure plusieurs fonctions transverses :
|
||||
|
||||
- **sécurité** : authentification, chiffrement TLS, listes de contrôle d'accès (ACL) ;
|
||||
- **gestion des sessions** et reprise après reconnexion ;
|
||||
- **gestion des abonnements** et de l'arborescence des topics ;
|
||||
- **sécurité** : authentification (login/mot de passe ou certificats), chiffrement TLS sur le port 8883, listes de contrôle d'accès (ACL). Par exemple, on peut autoriser le capteur du salon à *publier* uniquement sur `maison/salon/#` mais lui interdire de s'abonner à `maison/chambre/#` ;
|
||||
- **gestion des sessions** et reprise après reconnexion : si un client perd le réseau pendant deux minutes, le broker peut conserver ses abonnements et lui retransmettre les messages manqués à sa reconnexion (avec `clean_session=false`) ;
|
||||
- **gestion des abonnements** et de l'arborescence des topics, avec résolution des jokers à chaque message reçu ;
|
||||
- **qualité de service (QoS)** avec trois niveaux :
|
||||
- *0* — au plus une fois (best effort, sans accusé),
|
||||
- *1* — au moins une fois (accusé de réception),
|
||||
- *2* — exactement une fois (échange en quatre temps) ;
|
||||
- **rétention** et stockage temporaire des messages pour les clients déconnectés.
|
||||
- *0* — au plus une fois (best effort, sans accusé). Adapté à un capteur qui publie sa température toutes les 5 secondes : perdre un message n'a aucune conséquence,
|
||||
- *1* — au moins une fois (accusé de réception), avec risque de doublon. Bon compromis pour la majorité des cas, par exemple un capteur d'ouverture de porte,
|
||||
- *2* — exactement une fois (échange en quatre temps). Réservé aux messages critiques où ni la perte ni le doublon ne sont acceptables, par exemple une commande de paiement ou un ordre d'ouverture de portail ;
|
||||
- **rétention** : un message marqué *retained* est conservé par le broker et envoyé immédiatement à tout nouvel abonné. Très utile pour l'état d'un équipement — quand Home Assistant redémarre et s'abonne à `maison/salon/lampe/etat`, il récupère aussitôt la dernière valeur connue (`ON` ou `OFF`) sans attendre la prochaine publication ;
|
||||
- **Last Will and Testament (LWT)** : chaque client peut déclarer à la connexion un message que le broker publiera *à sa place* en cas de déconnexion brutale. Pratique pour signaler qu'un capteur est tombé : `maison/salon/capteur/status` passe automatiquement à `offline` si le capteur ne répond plus.
|
||||
|
||||
Un broker MQTT peut s'exécuter sur des cibles très variées — poste de travail, serveur cloud, passerelle IoT — et il existe de nombreuses implémentations, open source comme commerciales. Le choix dépend principalement de la volumétrie attendue, des exigences de sécurité et de l'écosystème cible.
|
||||
Un broker MQTT peut s'exécuter sur des cibles très variées — poste de travail, serveur cloud, passerelle IoT, voire un Raspberry Pi — et il existe de nombreuses implémentations, open source comme commerciales. Le choix dépend principalement de la volumétrie attendue, des exigences de sécurité et de l'écosystème cible.
|
||||
|
||||
## Quelques implémentations courantes
|
||||
|
||||
- **Mosquitto** — le broker le plus répandu dans les projets DIY et l'IoT léger ; léger, simple à déployer.
|
||||
- **EMQX** (ex-EMQTT) — conçu pour absorber un très grand nombre de connexions simultanées, adapté aux déploiements industriels.
|
||||
- **RabbitMQ** — broker multi-protocoles (AMQP, MQTT…) avec support commercial, pertinent quand MQTT cohabite avec d'autres protocoles.
|
||||
- **ActiveMQ** — broker Apache supportant MQTT en plus de JMS et AMQP, intéressant dans un écosystème Java existant.
|
||||
- **Mosquitto** — le broker le plus répandu dans les projets DIY et l'IoT léger ; léger, simple à déployer. Empreinte mémoire de quelques mégaoctets, configuration dans un unique fichier `mosquitto.conf`. Il tient sans problème sur un Raspberry Pi et gère confortablement quelques centaines de clients.
|
||||
- **EMQX** (ex-EMQTT) — conçu pour absorber un très grand nombre de connexions simultanées (jusqu'à plusieurs millions sur un cluster), adapté aux déploiements industriels et aux flottes de véhicules connectés. Fournit une interface web d'administration et des règles de routage avancées.
|
||||
- **RabbitMQ** — broker multi-protocoles (AMQP, MQTT, STOMP…) avec support commercial, pertinent quand MQTT cohabite avec d'autres protocoles dans un SI existant. Typiquement utilisé quand des microservices en AMQP doivent dialoguer avec des objets connectés en MQTT.
|
||||
- **ActiveMQ** — broker Apache supportant MQTT en plus de JMS et AMQP, intéressant dans un écosystème Java existant où l'on veut éviter d'introduire un nouveau composant.
|
||||
- **JoramMQ** — orienté intégration Java, plus rarement rencontré.
|
||||
|
||||
## Mon choix
|
||||
|
||||
Pour la suite, j'ai retenu **Mosquitto** pour sa légèreté, sa simplicité de configuration et sa large adoption dans la communauté IoT. Il sera installé dans un conteneur **LXC** sous Debian.
|
||||
Pour la suite, j'ai retenu **Mosquitto** pour sa légèreté, sa simplicité de configuration et sa large adoption dans la communauté IoT. Concrètement, mon installation devra gérer une poignée de clients — Home Assistant, Zigbee2MQTT, ntfy et quelques capteurs ESP — soit un volume bien en deçà de ce qu'un Mosquitto encaisse sans broncher. Il sera installé dans un conteneur **LXC** sous Debian, ce qui permet de l'isoler du reste de l'hôte tout en gardant une empreinte minimale.
|
||||
|
||||
@@ -7,13 +7,19 @@
|
||||
"featured": false,
|
||||
"published_at": "2023-02-19 07:50",
|
||||
"created_at": "2023-02-19 07:50:53",
|
||||
"updated_at": "2026-05-16 19:47:58",
|
||||
"updated_at": "2026-05-16 19:49:56",
|
||||
"revisions": [
|
||||
{
|
||||
"n": 1,
|
||||
"date": "2026-05-16 19:47:58",
|
||||
"comment": "Titre modifié, catégorie modifiée, tags modifiés, contenu modifié, image de couverture modifiée",
|
||||
"title": "120 · broker"
|
||||
},
|
||||
{
|
||||
"n": 2,
|
||||
"date": "2026-05-16 19:49:56",
|
||||
"comment": "Contenu modifié",
|
||||
"title": "Broker MQTT"
|
||||
}
|
||||
],
|
||||
"cover": "cover.svg",
|
||||
|
||||
@@ -0,0 +1,30 @@
|
||||
# Broker MQTT
|
||||
|
||||
Un **broker MQTT** est un serveur qui implémente le protocole MQTT et orchestre les échanges entre clients selon un modèle *publish/subscribe*. Les producteurs publient des messages sur des *topics*, et le broker se charge de les relayer aux clients abonnés à ces topics. Ce découplage entre émetteurs et récepteurs en fait une brique centrale des architectures IoT et des systèmes distribués asynchrones.
|
||||
|
||||
## Rôle du broker
|
||||
|
||||
Au-delà du simple relais de messages, le broker assure plusieurs fonctions transverses :
|
||||
|
||||
- **sécurité** : authentification, chiffrement TLS, listes de contrôle d'accès (ACL) ;
|
||||
- **gestion des sessions** et reprise après reconnexion ;
|
||||
- **gestion des abonnements** et de l'arborescence des topics ;
|
||||
- **qualité de service (QoS)** avec trois niveaux :
|
||||
- *0* — au plus une fois (best effort, sans accusé),
|
||||
- *1* — au moins une fois (accusé de réception),
|
||||
- *2* — exactement une fois (échange en quatre temps) ;
|
||||
- **rétention** et stockage temporaire des messages pour les clients déconnectés.
|
||||
|
||||
Un broker MQTT peut s'exécuter sur des cibles très variées — poste de travail, serveur cloud, passerelle IoT — et il existe de nombreuses implémentations, open source comme commerciales. Le choix dépend principalement de la volumétrie attendue, des exigences de sécurité et de l'écosystème cible.
|
||||
|
||||
## Quelques implémentations courantes
|
||||
|
||||
- **Mosquitto** — le broker le plus répandu dans les projets DIY et l'IoT léger ; léger, simple à déployer.
|
||||
- **EMQX** (ex-EMQTT) — conçu pour absorber un très grand nombre de connexions simultanées, adapté aux déploiements industriels.
|
||||
- **RabbitMQ** — broker multi-protocoles (AMQP, MQTT…) avec support commercial, pertinent quand MQTT cohabite avec d'autres protocoles.
|
||||
- **ActiveMQ** — broker Apache supportant MQTT en plus de JMS et AMQP, intéressant dans un écosystème Java existant.
|
||||
- **JoramMQ** — orienté intégration Java, plus rarement rencontré.
|
||||
|
||||
## Mon choix
|
||||
|
||||
Pour la suite, j'ai retenu **Mosquitto** pour sa légèreté, sa simplicité de configuration et sa large adoption dans la communauté IoT. Il sera installé dans un conteneur **LXC** sous Debian.
|
||||
Reference in New Issue
Block a user