Installer Mosquitto sur Raspberry Pi vous donne un broker MQTT rapide et léger qui continue de fonctionner sur votre réseau local même quand Internet tombe. Dans ce tutoriel, vous allez installer les paquets Mosquitto depuis le dépôt du système, configurer un listener avec authentification par mot de passe, le tester en ligne de commande et déterminer quand un broker local suffit et quand il doit faire un pont vers un broker cloud. Chaque fichier de configuration est complet et prêt à copier.
Quand un broker Mosquitto local a du sens
Un broker sur le Pi convient bien à certains usages et mal à d'autres. Soyez lucide sur votre cas avant d'y consacrer du temps.
| Situation | Mosquitto local sur le Pi | Broker cloud |
|---|---|---|
| Tous les appareils sur un seul réseau local, aucun accès distant nécessaire | Bien adapté | Facultatif |
| Doit continuer à fonctionner pendant les coupures Internet | Bien adapté | À combiner avec un broker local |
| Appareils répartis dans plusieurs bâtiments ou sur réseaux mobiles | Peu adapté, nécessite une redirection de ports | Bien adapté |
| Applications mobiles et tableaux de bord accessibles de partout | Peu adapté, nécessite un VPN ou des ports ouverts | Bien adapté |
| Vous voulez que quelqu'un d'autre gère TLS, l'authentification et les mises à jour | Peu adapté | Bien adapté |
| Latence très faible entre appareils locaux | Bien adapté | Ajoute un aller-retour par Internet |
Le schéma qui combine les deux est courant en pratique : les appareils dialoguent avec un Mosquitto local sur le Pi, et Mosquitto relaie par un pont une sélection de topics vers un broker cloud. Les automatisations locales de la maison connectée continuent de tourner hors ligne, et le côté cloud reçoit les données pour les tableaux de bord et l'accès à distance. C'est là que ce tutoriel vous mène. Pour un rappel préalable sur le rôle du broker, voir ce que fait un broker MQTT.
Étape 1 : installer Mosquitto sur Raspberry Pi OS
Raspberry Pi OS Bookworm fournit Mosquitto 2.0 dans son dépôt, une version suffisamment récente pour la plupart des usages :
sudo apt update
sudo apt install -y mosquitto mosquitto-clients
sudo systemctl enable --now mosquitto
mosquitto -h | head -n 1
systemctl status mosquitto --no-pager
Le paquet mosquitto-clients ajoute mosquitto_pub et mosquitto_sub, que vous utiliserez pour les tests.
Par défaut, Mosquitto 2.0 est volontairement verrouillé : sans listener configuré, il n'accepte que les connexions venant du Pi lui-même (localhost) et refuse les clients distants anonymes. Cela surprend ceux qui ont suivi d'anciens guides, où le broker acceptait n'importe qui sur le port 1883. C'est pourtant le bon comportement par défaut, et l'étape suivante l'ouvre en toute sécurité.
Étape 2 : créer des utilisateurs et un fichier de mots de passe
Créez un fichier de mots de passe avec un utilisateur par appareil ou service. L'option -c crée le fichier : ne l'utilisez que pour le premier utilisateur.
sudo mosquitto_passwd -c /etc/mosquitto/passwd sensors
sudo mosquitto_passwd /etc/mosquitto/passwd nodered
sudo mosquitto_passwd /etc/mosquitto/passwd dashboard
Chaque commande demande un mot de passe et enregistre une empreinte salée, pas le texte en clair. Restreignez le fichier pour que seuls root et le broker puissent le lire :
sudo chown root:mosquitto /etc/mosquitto/passwd
sudo chmod 0640 /etc/mosquitto/passwd
Les versions récentes de Mosquitto affichent un avertissement dans le journal lorsque le fichier de mots de passe est lisible par tous, et les versions futures pourraient le refuser : définissez donc les permissions dès maintenant.
Étape 3 : configurer le listener
Laissez le fichier principal /etc/mosquitto/mosquitto.conf tel qu'il est livré ; il inclut tous les fichiers de /etc/mosquitto/conf.d/. Ajoutez-y votre propre configuration :
sudo nano /etc/mosquitto/conf.d/local.conf
# Local network listener with authentication
per_listener_settings true
listener 1883 0.0.0.0
allow_anonymous false
password_file /etc/mosquitto/passwd
# Limits that protect a small Pi
max_connections 200
max_inflight_messages 20
max_queued_messages 1000
message_size_limit 262144
# Keep the SD card happy: persistence is on by default in the main file,
# save to disk every 5 minutes rather than continuously
autosave_interval 300
Quelques remarques sur ces réglages. per_listener_settings true permet à chaque listener d'avoir sa propre authentification, ce dont vous aurez besoin si vous ajoutez plus tard un listener WebSocket avec d'autres règles. message_size_limit empêche un client défaillant d'envoyer d'énormes payloads à un Pi dont la RAM est limitée. autosave_interval contrôle la fréquence d'écriture de la base de persistance en mémoire, ce qui compte pour l'usure de la carte SD.
Redémarrez et consultez le journal :
sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 30 --no-pager
Le journal doit afficher Opening ipv4 listen socket on port 1883. Si le service échoue, la ligne du journal juste au-dessus de l'erreur indique l'option fautive.
Étape 4 : tester le broker local
Dans un terminal du Pi, abonnez-vous avec l'utilisateur dashboard :
mosquitto_sub -h localhost -p 1883 -u dashboard -P 'dashboard-password' \
-i test-sub -t 'home/#' -v
Dans un autre terminal, ou depuis un ordinateur portable sur le même réseau en utilisant l'adresse IP du Pi, publiez en tant que sensors :
mosquitto_pub -h 192.168.1.50 -p 1883 -u sensors -P 'sensors-password' \
-i test-pub -t home/kitchen/temperature -m 21.6
L'abonné affiche home/kitchen/temperature 21.6. Essayez maintenant sans identifiants pour confirmer que l'accès anonyme est refusé :
mosquitto_pub -h 192.168.1.50 -p 1883 -i anon-test -t home/x -m test
# Connection error: Connection Refused: not authorised.
Pour d'autres usages en ligne de commande, voir les exemples mosquitto_pub et mosquitto_sub. Si vous voulez simplement essayer MQTT sans rien installer, le serveur MQTT public gratuit broker.connectmq.com convient aux tests, mais pas aux données réelles de votre maison.
Étape 5 : listener WebSocket facultatif pour les tableaux de bord locaux
Si un tableau de bord dans le navigateur sur votre réseau local doit dialoguer avec le broker du Pi, ajoutez un listener WebSocket dans le même fichier :
listener 9001 0.0.0.0
protocol websockets
allow_anonymous false
password_file /etc/mosquitto/passwd
Comme per_listener_settings est activé, ce listener a besoin de ses propres lignes allow_anonymous et password_file. Un ws:// en clair est acceptable sur un réseau local de confiance, mais pas à travers Internet.
Check-list de sécurisation après avoir installé Mosquitto sur Raspberry Pi
- Changez le mot de passe de l'utilisateur par défaut du Pi et maintenez le système à jour avec
sudo apt full-upgrade. - Ne redirigez pas le port 1883 sur votre box ou votre routeur. Exposer un broker non chiffré sur Internet invite aux tentatives de devinette de mots de passe et à l'écoute du trafic.
- Utilisez un utilisateur MQTT distinct par appareil ou service, afin de pouvoir en révoquer un sans toucher aux autres.
- Ajoutez une règle de pare-feu pour que seul votre réseau local atteigne le broker :
sudo ufw allow from 192.168.1.0/24 to any port 1883. - Déplacez la persistance sur un SSD ou réduisez les écritures si le Pi tourne sur une carte SD pendant des années.
- Surveillez le Pi lui-même ; le publieur de statistiques système du Raspberry Pi remonte l'occupation du disque et la température.
Pour accéder au broker depuis l'extérieur, résistez à la tentation d'ouvrir des ports. C'est un travail qu'un broker cloud fait mieux.
Relier le broker Mosquitto local à ConnectMQ par un pont
C'est ici que le broker local et le broker cloud se rejoignent. Mosquitto intègre une fonction de pont (bridge) : il se connecte en sortie à un broker distant comme un client MQTT ordinaire et transfère les topics de votre choix. ConnectMQ est un broker MQTT cloud : de son point de vue, votre Pi n'est qu'un client de plus qui se connecte avec le nom d'utilisateur, le mot de passe et le client ID générés dans le portail. Aucune fonction de pont spéciale n'est nécessaire côté cloud, et aucun port entrant n'est ouvert sur votre réseau.
Un fichier de pont minimal, /etc/mosquitto/conf.d/bridge-connectmq.conf, ressemble à ceci :
connection connectmq
address broker.connectmq.com:8883
bridge_capath /etc/ssl/certs
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
bridge_protocol_version mqttv311
try_private false
cleansession false
notifications false
start_type automatic
# Local topic home/... appears in the cloud as site1/home/...
topic home/# out 1 "" site1/
# Commands from the cloud reach local devices
topic home/+/set in 1 "" site1/
Redémarrez Mosquitto : le journal affiche Connecting bridge connectmq. Les messages publiés localement sur home/kitchen/temperature apparaissent désormais aussi sur site1/home/kitchen/temperature chez ConnectMQ, où l'explorateur de topics en direct et le tableau de bord du portail peuvent les afficher. Si Internet tombe, les appareils locaux continuent de dialoguer avec le Pi, et avec cleansession false et le QoS 1, les messages sortants sont mis en file d'attente localement jusqu'à la reconnexion du pont, dans la limite de max_queued_messages.
Le broker cloud utilise un certificat Let's Encrypt, c'est pourquoi bridge_capath /etc/ssl/certs suffit comme configuration TLS. try_private false est important : il empêche Mosquitto d'utiliser un indicateur de protocole propre à Mosquitto que les autres brokers n'attendent pas. La présentation complète, option par option, avec la prévention des boucles et les tests, figure dans le guide de configuration d'un pont Mosquitto.
Si vous constatez à terme que vous ne gardez le broker du Pi que pour atteindre le cloud, envisagez de le supprimer complètement et de connecter les appareils directement au cloud. Le guide de migration de Mosquitto vers un broker cloud couvre cette voie.
Dépannage
| Erreur ou symptôme | Cause | Solution |
|---|---|---|
Connection refused depuis d'autres machines |
Aucun listener sur 0.0.0.0 | Ajoutez listener 1883 0.0.0.0 |
not authorised |
Mauvais utilisateur ou mot de passe, ou fichier illisible par le broker | Relancez mosquitto_passwd, vérifiez chown root:mosquitto |
| Le service échoue après modification de la configuration | Listener en double ou faute de frappe | Lisez journalctl -u mosquitto |
| Les clients se déconnectent sans cesse | Deux clients partagent le même ID | Utilisez des client ID uniques |
| Le pont se connecte puis décroche | Client ID ou identifiants incorrects | Copiez exactement les trois depuis le portail |
Démarrer avec ConnectMQ
Gardez Mosquitto pour le trafic local rapide et laissez un broker MQTT managé gérer tout ce qui traverse Internet. Créez un broker Serverless gratuit sur app.connectmq.com, sans carte bancaire, copiez les identifiants générés dans votre fichier de pont et regardez vos topics locaux apparaître dans le portail. D'autres projets Pi sont rassemblés dans le tutoriel MQTT sur Raspberry Pi, et pour organiser les topics de votre maison connectée, suivez notre guide dédié. Jeedom et Domoticz savent aussi communiquer en MQTT et peuvent donc utiliser ce même broker local.
Questions fréquentes
Pourquoi Mosquitto refuse-t-il les connexions des autres appareils après l'installation ?
Mosquitto 2.0 n'écoute que sur localhost et rejette les clients anonymes tant que vous n'avez pas configuré de listener. Ajoutez listener 1883 0.0.0.0 avec allow_anonymous false et un fichier de mots de passe.
Faut-il exposer mon broker Mosquitto sur Raspberry Pi à Internet ?
Ce n'est pas recommandé. Faites plutôt un pont sortant vers un broker cloud, pour que l'accès distant passe par un service sécurisé par TLS et que votre routeur garde tous les ports entrants fermés.
Mosquitto sur Raspberry Pi peut-il gérer beaucoup d'appareils ?
Pour une maison ou un petit site, un Pi gère sans difficulté le trafic typique des capteurs. Les limites que vous atteindrez en premier sont généralement l'usure de la carte SD et l'effort de maintenance plutôt que le débit brut.
Le pont nécessite-t-il un compte spécial sur ConnectMQ ?
Non. Le pont est un client MQTT normal : il utilise le même nom d'utilisateur, le même mot de passe et le même client ID que ceux générés par le portail pour n'importe quel appareil.
