La fiabilidad Raspberry Pi rara vez está limitada por la propia placa; la limitan la tarjeta SD, la fuente de alimentación, el calor y un software que nadie reinicia cuando se cuelga. Esta guía recorre los cambios que convierten una Pi de proyecto de escritorio en un gateway MQTT que funciona desatendido durante meses: reducir las escrituras en el almacenamiento, usar un sistema de archivos raíz de solo lectura, elegir alimentación y refrigeración, activar watchdogs y monitorizar el dispositivo en remoto por MQTT. Cada sección incluye los comandos para aplicarlo.
Por qué fallan las Pi siempre encendidas
Cuando un gateway con Pi deja de dar señales en campo, la causa suele caer en una de pocas categorías:
| Fallo | Síntoma típico | Causa raíz |
|---|---|---|
| Corrupción del almacenamiento | Arranca en el shell de emergencia, se remonta en solo lectura, faltan archivos | Tarjeta SD desgastada o corte de luz durante una escritura |
| Subtensión | Reinicios aleatorios, dispositivos USB que se desconectan, reinicios del Wi-Fi | Fuente débil, cable largo o fino, periféricos que consumen mucho |
| Sobrecalentamiento | Lentitud, throttling, comportamiento errático | Sin refrigeración en una caja cerrada |
| Cuelgue del software | El dispositivo responde al ping pero los datos se detienen | Script atascado, interbloqueo, fuga de memoria, problema de la pila de red |
| Pérdida de red | Hueco en los datos y luego pérdida del acumulado | Caída del Wi-Fi, reinicio del router, corte de la red celular |
La buena noticia es que todos tienen una mitigación conocida. Ninguna requiere hardware exótico, y la mayoría son unas pocas líneas de configuración.
Almacenamiento: reduce las escrituras o cambia el medio
Las tarjetas SD tienen una resistencia a la escritura limitada y una protección débil frente a cortes de alimentación. Un gateway que genera logs detallados, escribe en una base de datos y deja que journald guarde los logs en disco puede desgastar una tarjeta barata sorprendentemente rápido. Hay tres soluciones complementarias.
Usa un almacenamiento mejor. Una Raspberry Pi 4 o 5 puede arrancar desde un SSD USB, y la Pi 5 también admite unidades NVMe mediante el M.2 HAT+. Ambos soportan las escrituras mucho mejor que las tarjetas SD. Si tienes que usar SD, elige una tarjeta de alta resistencia de una marca reconocida, diseñada para grabación continua.
Elimina escrituras innecesarias. Mantén los logs en RAM, desactiva el swap si no lo necesitas y monta con noatime:
# journald solo en RAM (los logs se pierden al reiniciar, así que reenvía los importantes)
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
# desactivar el archivo de swap
sudo systemctl disable --now dphys-swapfile 2>/dev/null || true
# comprobar que las opciones de montaje de la raíz incluyen noatime
findmnt /
Escribe de forma deliberada. Si tu gateway almacena mensajes en disco mientras está sin conexión, agrupa las escrituras y usa SQLite en modo WAL, como en el tutorial del buffer MQTT offline en Python. Evita reescribir un archivo de estado JSON cada segundo.
Sistema de archivos raíz de solo lectura
Para gateways que no necesitan cambiar su software a menudo, una raíz de solo lectura es la protección más sólida frente a la corrupción. Raspberry Pi OS incluye una opción de sistema de archivos overlay: la raíz real permanece en solo lectura y todos los cambios van a una capa en RAM que desaparece al reiniciar.
sudo raspi-config nonint enable_overlayfs
sudo reboot
# más adelante, para actualizar el software:
sudo raspi-config nonint disable_overlayfs
sudo reboot
También puedes activarlo de forma interactiva en Performance Options de raspi-config. Ten en cuenta dos consecuencias. Primero, todo lo que el gateway deba conservar (cambios de configuración, un buffer de mensajes) necesita una partición escribible aparte o una unidad externa. Segundo, las actualizaciones requieren un ciclo de reinicio de mantenimiento, así que automatízalo o documéntalo.
Alimentación: el factor más infravalorado
La subtensión provoca más comportamientos misteriosos que cualquier otro problema de hardware. Usa la fuente de alimentación oficial para tu modelo, o una fuente industrial con margen: la Raspberry Pi 5 está diseñada para una fuente USB-C de 5 V y 5 A, y la Pi 4 para 5,1 V y 3 A. Usa cables cortos y gruesos, y alimenta las unidades USB o los módems desde un hub con alimentación propia si consumen mucho.
Comprueba si la Pi ha sufrido subtensión o throttling desde el arranque:
vcgencmd get_throttled
El resultado que quieres es throttled=0x0. El bit 0 (0x1) indica subtensión en este momento, el bit 16 (0x10000) indica que ha habido subtensión desde el arranque, y los bits 2 y 18 informan del throttling. Publica este valor por MQTT para ver los problemas antes de que provoquen fallos.
En sitios con una red eléctrica poco fiable, un pequeño HAT de SAI o un SAI de continua da a la Pi tiempo para apagarse limpiamente. Incluso unos segundos de autonomía protegen el sistema de archivos mucho mejor que un corte brusco.
Calor y cajas
La Pi reduce la frecuencia de su CPU cuando se calienta, lo que protege el hardware pero ralentiza tu aplicación. En una caja de plástico sellada al sol, una Pi puede llegar a ese punto con poca carga. Usa una caja disipadora o el Active Cooler oficial en una Pi 5, ventila las cajas y mantén la Pi alejada de otras fuentes de calor. Lee la temperatura con vcgencmd measure_temp e inclúyela en tus mensajes de salud.
Watchdogs: recupérate sin ir al sitio
Un watchdog reinicia el sistema cuando el software deja de responder. Usa dos capas.
Watchdog de hardware mediante systemd. El SoC de la Pi incluye un temporizador watchdog que systemd puede alimentar. Si el kernel o el propio systemd se cuelgan, la placa se reinicia.
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 de aplicación. Un proceso de Python colgado no activa el watchdog de hardware porque systemd sigue sano. Ejecuta el gateway como servicio systemd con Restart=always y, para los cuelgues (no solo los cierres), usa Type=notify con WatchdogSec=: el script debe enviar un latido con regularidad o systemd lo mata y lo reinicia.
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())
# tras conectar MQTT: sd_notify("READY=1")
# en el bucle principal, solo cuando el trabajo avanza de verdad:
# sd_notify("WATCHDOG=1")
Envía WATCHDOG=1 solo cuando el bucle esté realmente sano, por ejemplo tras una lectura y una publicación correctas. Enviarlo desde un hilo aparte que siempre se ejecuta anula el propósito. El archivo de unidad completo está en la guía para ejecutar un script MQTT de Python al arrancar.
Resiliencia de red
Las caídas de conectividad son normales, no excepcionales. Diseña para ellas:
- Deja que paho-mqtt se reconecte automáticamente con
reconnect_delay_set(1, 60)yconnect_async(). - Guarda las lecturas en local mientras no haya conexión y reprodúcelas en orden.
- Incluye una marca de tiempo en cada payload para que los datos reproducidos queden en el momento correcto.
- Usa un mensaje Last Will en un topic
statusretained para que el backend sepa cuándo desaparece el gateway. - Prefiere Ethernet a Wi-Fi siempre que puedas; con Wi-Fi, desactiva el ahorro de energía con
sudo iw dev wlan0 set power_save offsi ves caídas.
Monitorización remota de la salud por MQTT
No puedes arreglar lo que no ves. Haz que cada gateway publique un pequeño mensaje de salud cada minuto: tiempo en marcha, temperatura de la CPU, flags de throttling, disco libre, profundidad del buffer y versión del software. El tutorial de estadísticas del sistema de la Raspberry Pi por MQTT muestra un publicador completo. Con un broker MQTT en la nube en medio, puedes vigilar toda una flota desde un solo lugar, y las reglas de alerta por umbral de ConnectMQ pueden señalar un gateway cuya temperatura o profundidad de buffer cruce un límite. El estado retained del Last Will, junto con el topic $SYS/broker/connection/{clientId}/state del broker, te dice qué dispositivos están online en este momento.
Lista de comprobación de fiabilidad
- Arranca desde SSD o NVMe, o usa una tarjeta SD de alta resistencia.
- Logs en RAM, swap desactivado,
noatimeen el montaje de la raíz. - Overlay de solo lectura activado en despliegues estables.
- Fuente de alimentación oficial o industrial;
get_throttleddevuelve0x0. - Disipador o refrigeración activa; temperatura monitorizada.
- Watchdog de hardware activado en systemd.
- El gateway se ejecuta como servicio systemd con
Restart=alwaysy un watchdog de aplicación. - Reconexión MQTT automática, buffer offline y Last Will configurados.
- Métricas de salud publicadas cada minuto y vigiladas por alertas.
- Sistema operativo bastionado y conexiones TLS, siguiendo la lista de seguridad para IoT con Raspberry Pi.
Aplicados en conjunto, estos pasos eliminan los modos de fallo habituales y hacen que los pocos restantes se puedan recuperar en remoto. Para los fundamentos de cómo conectar una Pi a un broker, empieza por el tutorial de MQTT con Raspberry Pi, y consulta la documentación oficial de Raspberry Pi para los detalles de alimentación y arranque de cada modelo.
Mantén fiable el lado del servidor con ConnectMQ
Un gateway que nunca falla sigue perdiendo datos si falla el broker con el que habla. Un broker MQTT gestionado como ConnectMQ se encarga del broker para que puedas concentrarte en el edge. Crea un broker Serverless gratuito en app.connectmq.com sin tarjeta de crédito, conecta tu gateway por TLS en el puerto 8883 y observa sus topics de salud en el explorador de topics en vivo.
Preguntas frecuentes
¿Cuánto dura una tarjeta SD en un gateway con Raspberry Pi?
Depende por completo de la carga de escritura y de la calidad de la tarjeta. Reducir las escrituras y usar una tarjeta de alta resistencia o un SSD alarga mucho su vida, mientras que un registro intensivo de logs puede desgastar rápidamente una tarjeta barata.
¿Un sistema de archivos de solo lectura romperá mi cliente MQTT?
No, si el cliente solo necesita leer su código y su configuración. Todo lo que deba persistir, como un buffer offline, necesita una ubicación escribible aparte.
¿Necesito un SAI para una Raspberry Pi?
No siempre, pero merece la pena donde la alimentación es inestable. Un apagado limpio protege el sistema de archivos, y una raíz de solo lectura reduce el daño cuando la luz se corta sin aviso.
¿Debo programar reinicios periódicos?
Los reinicios programados ocultan los problemas en lugar de resolverlos. Los watchdogs junto con la monitorización de la salud son mejores, pero un reinicio semanal es un recurso pragmático mientras investigas una fuga.
