La fiabilité du Raspberry Pi est rarement limitée par la carte elle-même ; elle l'est par la carte SD, l'alimentation, la chaleur et des logiciels que personne ne redémarre lorsqu'ils se figent. Ce guide passe en revue les changements qui transforment un Pi de projet de bureau en passerelle MQTT capable de fonctionner sans surveillance pendant des mois : réduire les écritures sur le stockage, utiliser un système de fichiers racine en lecture seule, bien choisir l'alimentation et le refroidissement, activer les watchdogs et superviser l'appareil à distance via MQTT. Chaque section inclut les commandes nécessaires.
Pourquoi les Pi allumés en permanence tombent en panne
Lorsqu'une passerelle Pi se tait sur le terrain, la cause relève généralement de l'une de ces quelques catégories :
| Panne | Symptôme typique | Cause racine |
|---|---|---|
| Corruption du stockage | Démarrage en shell d'urgence, remontage en lecture seule, fichiers manquants | Carte SD usée ou coupure de courant pendant une écriture |
| Sous-tension | Redémarrages aléatoires, périphériques USB qui décrochent, Wi-Fi qui se réinitialise | Alimentation faible, câble long ou fin, périphériques gourmands |
| Surchauffe | Ralentissements, bridage du processeur, comportement erratique | Aucun refroidissement dans un boîtier fermé |
| Blocage logiciel | L'appareil répond au ping mais les données s'arrêtent | Script bloqué, interblocage, fuite mémoire, problème de pile réseau |
| Perte réseau | Trou dans les données, puis arriéré perdu | Coupure Wi-Fi, redémarrage du routeur, panne cellulaire |
Bonne nouvelle : chacun de ces problèmes a une parade bien connue. Aucune ne demande de matériel exotique, et la plupart tiennent en quelques lignes de configuration.
Stockage : réduire les écritures ou changer de support
Les cartes SD ont une endurance en écriture limitée et une faible protection contre les coupures de courant. Une passerelle qui journalise abondamment, écrit dans une base de données et laisse journald conserver ses journaux peut user une carte bon marché étonnamment vite. Trois solutions complémentaires existent.
Utilisez un meilleur stockage. Un Raspberry Pi 4 ou 5 peut démarrer depuis un SSD USB, et le Pi 5 prend aussi en charge les disques NVMe via le M.2 HAT+. Les deux supportent bien mieux les écritures que les cartes SD. Si vous devez utiliser une carte SD, choisissez une carte haute endurance de marque reconnue, conçue pour l'enregistrement en continu.
Supprimez les écritures inutiles. Gardez les journaux en RAM, désactivez le swap si vous n'en avez pas besoin et montez avec noatime :
# journald en RAM uniquement (journaux perdus au redémarrage : transférez les plus importants)
sudo mkdir -p /etc/systemd/journald.conf.d
printf "[Journal]\nStorage=volatile\nRuntimeMaxUse=30M\n" | sudo tee /etc/systemd/journald.conf.d/volatile.conf
sudo systemctl restart systemd-journald
# désactiver le fichier d'échange
sudo systemctl disable --now dphys-swapfile 2>/dev/null || true
# vérifier que les options de montage de la racine incluent noatime
findmnt /
Écrivez de façon réfléchie. Si votre passerelle met les messages en tampon sur disque pendant les coupures, regroupez les écritures et utilisez SQLite en mode WAL, comme dans le tutoriel tampon MQTT hors ligne en Python. Évitez de réécrire un fichier d'état JSON chaque seconde.
Système de fichiers racine en lecture seule
Pour les passerelles dont le logiciel change rarement, une racine en lecture seule est la meilleure protection contre la corruption. Raspberry Pi OS propose une option de système de fichiers overlay : la vraie racine reste en lecture seule et toutes les modifications vont dans une couche en RAM qui disparaît au redémarrage.
sudo raspi-config nonint enable_overlayfs
sudo reboot
# plus tard, pour mettre à jour les logiciels :
sudo raspi-config nonint disable_overlayfs
sudo reboot
Vous pouvez aussi l'activer de façon interactive dans Performance Options de raspi-config. Prévoyez deux conséquences. D'abord, tout ce que la passerelle doit conserver (changements de configuration, tampon de messages) nécessite une partition inscriptible séparée ou un disque externe. Ensuite, les mises à jour exigent un cycle de redémarrage de maintenance : automatisez-le ou documentez-le.
Alimentation : le facteur le plus sous-estimé
La sous-tension provoque plus de comportements mystérieux que n'importe quel autre problème matériel. Utilisez l'alimentation officielle de votre modèle, ou une alimentation industrielle avec de la marge : le Raspberry Pi 5 est conçu pour une alimentation USB-C 5 V 5 A, et le Pi 4 pour 5,1 V 3 A. Gardez des câbles courts et de forte section, et alimentez les disques USB ou les modems gourmands via un hub alimenté.
Vérifiez si le Pi a subi une sous-tension ou un bridage depuis le démarrage :
vcgencmd get_throttled
Le résultat attendu est throttled=0x0. Le bit 0 (0x1) signale une sous-tension en cours, le bit 16 (0x10000) une sous-tension survenue depuis le démarrage, et les bits 2 et 18 indiquent un bridage. Publiez cette valeur via MQTT pour repérer les problèmes avant qu'ils ne provoquent des pannes.
Sur les sites où le secteur est peu fiable, un petit HAT onduleur ou un onduleur DC donne au Pi le temps de s'arrêter proprement. Même quelques secondes d'autonomie protègent bien mieux le système de fichiers qu'une coupure franche.
Chaleur et boîtiers
Le Pi bride son processeur lorsqu'il chauffe, ce qui protège le matériel mais ralentit votre application. Dans un boîtier plastique étanche en plein soleil, un Pi peut atteindre ce seuil avec très peu de charge. Utilisez un boîtier dissipateur ou l'Active Cooler officiel sur un Pi 5, ventilez les boîtiers et éloignez le Pi des autres sources de chaleur. Lisez la température avec vcgencmd measure_temp et intégrez-la à vos messages de santé.
Watchdogs : récupérer sans se déplacer
Un watchdog redémarre le système lorsque le logiciel ne répond plus. Utilisez deux niveaux.
Watchdog matériel via systemd. Le SoC du Pi intègre une minuterie watchdog que systemd peut alimenter. Si le noyau ou systemd lui-même se bloque, la carte redémarre.
sudo mkdir -p /etc/systemd/system.conf.d
printf "[Manager]\nRuntimeWatchdogSec=15\nRebootWatchdogSec=2min\n" | sudo tee /etc/systemd/system.conf.d/watchdog.conf
sudo systemctl daemon-reexec
dmesg | grep -i watchdog
Watchdog applicatif. Un processus Python bloqué ne déclenche pas le watchdog matériel, puisque systemd fonctionne toujours. Exécutez la passerelle en tant que service systemd avec Restart=always et, pour les blocages (pas seulement les plantages), utilisez Type=notify avec WatchdogSec= : le script doit envoyer régulièrement un signal de vie, sans quoi systemd le tue et le relance.
import os
import socket
def sd_notify(state: str):
addr = os.getenv("NOTIFY_SOCKET")
if not addr:
return
if addr.startswith("@"):
addr = "\0" + addr[1:]
with socket.socket(socket.AF_UNIX, socket.SOCK_DGRAM) as s:
s.connect(addr)
s.sendall(state.encode())
# après la connexion MQTT : sd_notify("READY=1")
# dans la boucle principale, uniquement quand le travail progresse réellement :
# sd_notify("WATCHDOG=1")
N'envoyez WATCHDOG=1 que lorsque la boucle est réellement en bonne santé, par exemple après une lecture et une publication réussies. L'envoyer depuis un thread séparé qui tourne toujours n'a aucun intérêt. Le fichier d'unité complet se trouve dans le guide pour lancer un script Python MQTT au démarrage.
Résilience réseau
Les pertes de connectivité sont normales, pas exceptionnelles. Concevez en conséquence :
- Laissez paho-mqtt se reconnecter automatiquement avec
reconnect_delay_set(1, 60)etconnect_async(). - Mettez les mesures en tampon localement pendant la déconnexion et rejouez-les dans l'ordre.
- Incluez un horodatage dans chaque payload pour que les données rejouées soient placées au bon moment.
- Utilisez un message Last Will sur un topic
statusretained pour que le backend sache quand la passerelle disparaît. - Préférez Ethernet au Wi-Fi lorsque c'est possible ; en Wi-Fi, désactivez l'économie d'énergie avec
sudo iw dev wlan0 set power_save offsi vous constatez des coupures.
Supervision de la santé à distance via MQTT
On ne répare pas ce qu'on ne voit pas. Faites publier à chaque passerelle un petit message de santé toutes les minutes : temps de fonctionnement, température du processeur, indicateurs de bridage, espace disque libre, profondeur du tampon et version du logiciel. Le tutoriel statistiques système du Raspberry Pi via MQTT présente un publieur complet. Avec un broker MQTT cloud au milieu, vous pouvez surveiller toute une flotte depuis un seul endroit, et les règles d'alerte à seuil de ConnectMQ peuvent signaler une passerelle dont la température ou la profondeur de tampon dépasse une limite. Le statut Last Will retained, ainsi que le topic $SYS/broker/connection/{clientId}/state du broker, indiquent quels appareils sont en ligne à l'instant présent.
Liste de contrôle de fiabilité
- Démarrer depuis un SSD ou un NVMe, ou utiliser une carte SD haute endurance.
- Journaux en RAM, swap désactivé,
noatimesur le montage racine. - Overlay en lecture seule activé pour les déploiements stables.
- Alimentation officielle ou industrielle ;
get_throttledrenvoie0x0. - Dissipateur ou refroidissement actif ; température surveillée.
- Watchdog matériel activé dans systemd.
- Passerelle exécutée comme service systemd avec
Restart=alwayset un watchdog applicatif. - Reconnexion MQTT automatique, tampon hors ligne et Last Will configurés.
- Indicateurs de santé publiés chaque minute et surveillés par des alertes.
- Système durci et connexions TLS, en suivant la liste de contrôle pour sécuriser un Raspberry Pi IoT.
Appliquées ensemble, ces mesures éliminent les pannes courantes et rendent les rares pannes restantes récupérables à distance. Pour les bases de la connexion d'un Pi à un broker, commencez par le tutoriel MQTT sur Raspberry Pi, et consultez la documentation officielle Raspberry Pi pour les détails d'alimentation et de démarrage propres à chaque modèle.
Fiabiliser aussi le côté serveur avec ConnectMQ
Une passerelle qui ne tombe jamais en panne perd quand même des données si le broker auquel elle parle tombe. Un broker MQTT managé comme ConnectMQ prend en charge le broker pour que vous puissiez vous concentrer sur l'edge. Créez un broker Serverless gratuit sur app.connectmq.com sans carte bancaire, connectez votre passerelle en TLS sur le port 8883 et suivez ses topics de santé dans l'explorateur de topics en direct. Pour un tout premier essai sans compte, le serveur MQTT public gratuit suffit, à condition de n'y envoyer que des données de test.
Questions fréquentes
Combien de temps dure une carte SD dans une passerelle Raspberry Pi ?
Cela dépend entièrement de la charge en écriture et de la qualité de la carte. Réduire les écritures et utiliser une carte haute endurance ou un SSD prolonge considérablement la durée de vie, alors qu'une journalisation intensive peut user rapidement une carte bon marché.
Un système de fichiers en lecture seule va-t-il casser mon client MQTT ?
Non, si le client n'a besoin que de lire son code et sa configuration. Tout ce qu'il doit conserver, comme un tampon hors ligne, nécessite un emplacement inscriptible séparé.
Faut-il un onduleur pour un Raspberry Pi ?
Pas toujours, mais c'est utile là où l'alimentation est instable. Un arrêt propre protège le système de fichiers, et une racine en lecture seule limite les dégâts quand le courant est coupé sans prévenir.
Faut-il programmer des redémarrages réguliers ?
Les redémarrages programmés masquent les problèmes au lieu de les résoudre. Des watchdogs associés à une supervision de la santé valent mieux, mais un redémarrage hebdomadaire reste un recours pragmatique pendant que vous traquez une fuite.
