Al instalar Mosquitto en una Raspberry Pi obtienes un broker MQTT rápido y ligero que sigue funcionando en tu red local aunque falle internet. En este tutorial instalarás los paquetes de Mosquitto para Raspberry Pi desde el repositorio del sistema operativo, configurarás un listener con autenticación por contraseña, lo probarás desde la línea de comandos y decidirás cuándo basta un broker local y cuándo conviene hacer de puente (bridge) con un broker en la nube. Cada archivo de configuración está completo y listo para copiar.
Cuándo tiene sentido un broker Mosquitto local
Un broker en la Pi encaja bien en algunos trabajos y mal en otros. Sé sincero sobre cuál es tu caso antes de invertir tiempo en él.
| Situación | Mosquitto local en la Pi | Broker en la nube |
|---|---|---|
| Todos los dispositivos en una LAN, nada necesario en remoto | Encaja bien | Opcional |
| Debe seguir funcionando durante cortes de internet | Encaja bien | Combinar con un broker local |
| Dispositivos en varios edificios o en redes móviles | Encaja mal, requiere redirección de puertos | Encaja bien |
| Apps móviles y dashboards desde cualquier lugar | Encaja mal, requiere VPN o puertos abiertos | Encaja bien |
| Quieres que otro se encargue de TLS, autenticación y actualizaciones | Encaja mal | Encaja bien |
| Latencia muy baja entre dispositivos locales | Encaja bien | Añade un viaje de ida y vuelta por internet |
El patrón que combina ambos es habitual en la práctica: los dispositivos hablan con un Mosquitto local en la Pi, y Mosquitto hace de puente con un broker en la nube para los topics seleccionados. Las automatizaciones locales siguen funcionando sin conexión, y la parte en la nube recibe los datos para dashboards y acceso remoto. Ahí es donde termina este tutorial. Si antes quieres repasar el papel del broker, consulta qué hace un broker MQTT.
Paso 1: instalar Mosquitto en Raspberry Pi OS
Raspberry Pi OS Bookworm incluye Mosquitto 2.0 en su repositorio, una versión suficientemente reciente para la mayoría de usos:
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
El paquete mosquitto-clients añade mosquitto_pub y mosquitto_sub, que usarás para las pruebas.
Tal como viene, Mosquitto 2.0 está bloqueado a propósito: sin ningún listener configurado, solo acepta conexiones desde la propia Pi (localhost) y rechaza clientes remotos anónimos. Eso sorprende a quienes siguieron guías antiguas, en las que el broker aceptaba a cualquiera en el puerto 1883. Es el valor predeterminado correcto, y el paso siguiente lo abre de forma segura.
Paso 2: crear usuarios y un archivo de contraseñas
Crea un archivo de contraseñas con un usuario por dispositivo o servicio. La opción -c crea el archivo, así que úsala solo con el primer usuario:
sudo mosquitto_passwd -c /etc/mosquitto/passwd sensors
sudo mosquitto_passwd /etc/mosquitto/passwd nodered
sudo mosquitto_passwd /etc/mosquitto/passwd dashboard
Cada comando pide una contraseña y guarda un hash con sal, no el texto plano. Restringe el archivo para que solo root y el broker puedan leerlo:
sudo chown root:mosquitto /etc/mosquitto/passwd
sudo chmod 0640 /etc/mosquitto/passwd
Las versiones recientes de Mosquitto avisan en el log cuando el archivo de contraseñas es legible por todos, y versiones futuras podrían rechazarlo, así que configura los permisos ahora.
Paso 3: configurar el listener
Deja el archivo principal /etc/mosquitto/mosquitto.conf tal como viene; incluye todos los archivos de /etc/mosquitto/conf.d/. Añade ahí tu propia configuración:
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
Algunas notas sobre estos ajustes. per_listener_settings true permite que cada listener tenga su propia autenticación, algo que necesitarás si más adelante añades un listener WebSocket con reglas distintas. message_size_limit impide que un cliente defectuoso envíe payloads enormes a una Pi con RAM limitada. autosave_interval controla cada cuánto se escribe la base de datos de persistencia en memoria, lo que importa para el desgaste de la tarjeta SD.
Reinicia y revisa el log:
sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 30 --no-pager
El log debería mostrar Opening ipv4 listen socket on port 1883. Si el servicio falla, la línea del log justo encima del fallo indica la opción incorrecta.
Paso 4: probar el broker local
En un terminal de la Pi, suscríbete con el usuario dashboard:
mosquitto_sub -h localhost -p 1883 -u dashboard -P 'dashboard-password' \
-i test-sub -t 'home/#' -v
En otro terminal, o desde un portátil en la misma red usando la dirección IP de la Pi, publica como 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
El suscriptor imprime home/kitchen/temperature 21.6. Ahora prueba sin credenciales para confirmar que se rechaza el acceso anónimo:
mosquitto_pub -h 192.168.1.50 -p 1883 -i anon-test -t home/x -m test
# Connection error: Connection Refused: not authorised.
Para más patrones de línea de comandos, consulta los ejemplos de mosquitto_pub y mosquitto_sub.
Paso 5: listener WebSocket opcional para dashboards locales
Si un dashboard de navegador en tu LAN necesita hablar con el broker de la Pi, añade un listener WebSocket al mismo archivo:
listener 9001 0.0.0.0
protocol websockets
allow_anonymous false
password_file /etc/mosquitto/passwd
Como per_listener_settings está activado, este listener necesita sus propias líneas allow_anonymous y password_file. Un ws:// sin cifrar es aceptable en una LAN de confianza, pero no a través de internet.
Lista de refuerzo de seguridad tras instalar Mosquitto en Raspberry Pi
- Cambia la contraseña del usuario predeterminado de la Pi y mantén el sistema actualizado con
sudo apt full-upgrade. - No redirijas el puerto 1883 en tu router. Exponer a internet un broker sin cifrar invita a adivinar contraseñas y a espiar el tráfico.
- Usa un usuario MQTT distinto por dispositivo o servicio, para poder revocar uno sin tocar el resto.
- Añade una regla de firewall para que solo tu LAN llegue al broker:
sudo ufw allow from 192.168.1.0/24 to any port 1883. - Mueve la persistencia a un SSD o reduce las escrituras si la Pi va a funcionar durante años desde una tarjeta SD.
- Monitoriza la propia Pi; el publicador de estadísticas del sistema de Raspberry Pi informa del disco y la temperatura.
Para acceder al broker desde fuera, resiste la tentación de abrir puertos. Ese es un trabajo que un broker en la nube hace mejor.
Conectar el broker Mosquitto local a ConnectMQ mediante bridge
Aquí es donde se encuentran el broker local y un broker en la nube. Mosquitto tiene un bridge integrado: se conecta hacia fuera a un broker remoto como un cliente MQTT corriente y reenvía los topics que elijas. ConnectMQ es un broker MQTT en la nube, así que, desde su punto de vista, tu Pi es simplemente otro cliente que inicia sesión con el usuario, la contraseña y el client ID generados en el portal. No se necesita ninguna función de bridge especial en la parte de la nube, y no se abre ningún puerto de entrada en tu red.
Un archivo de bridge mínimo, /etc/mosquitto/conf.d/bridge-connectmq.conf, tiene este aspecto:
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/
Reinicia Mosquitto y el log mostrará Connecting bridge connectmq. Los mensajes publicados localmente en home/kitchen/temperature aparecen ahora también en site1/home/kitchen/temperature en ConnectMQ, donde el explorador de topics en vivo y el dashboard del portal pueden mostrarlos. Si se cae internet, los dispositivos locales siguen hablando con la Pi y, con cleansession false y QoS 1, los mensajes salientes se encolan localmente hasta que el bridge se reconecta, hasta el límite de max_queued_messages.
El broker en la nube usa un certificado de Let's Encrypt, por eso bridge_capath /etc/ssl/certs es toda la configuración TLS necesaria. try_private false es importante: impide que Mosquitto use un indicador de protocolo específico de Mosquitto que otros brokers no esperan. La explicación completa opción por opción, incluida la prevención de bucles y las pruebas, está en la guía de configuración del bridge de Mosquitto.
Si llegas a la conclusión de que solo mantienes el broker de la Pi para llegar a la nube, plantéate eliminarlo por completo y apuntar los dispositivos directamente a la nube. La guía para migrar Mosquitto a un broker en la nube cubre ese camino.
Solución de problemas
| Error o síntoma | Causa | Solución |
|---|---|---|
Connection refused desde otros equipos |
No hay listener en 0.0.0.0 | Añade listener 1883 0.0.0.0 |
not authorised |
Usuario o contraseña incorrectos, o archivo no legible por el broker | Vuelve a ejecutar mosquitto_passwd, comprueba chown root:mosquitto |
| El servicio falla tras editar la configuración | Listener duplicado o error tipográfico | Lee journalctl -u mosquitto |
| Los clientes se desconectan constantemente | Dos clientes comparten ID | Usa client ID únicos |
| El bridge se conecta y luego se cae | Client ID o credenciales no coinciden | Copia los tres valores exactamente del portal |
Empieza con ConnectMQ
Conserva Mosquitto para el tráfico local rápido y deja que un broker MQTT gestionado se encargue de todo lo que cruza internet. Crea un broker Serverless gratuito en app.connectmq.com, sin tarjeta de crédito, copia las credenciales generadas en tu archivo de bridge y observa cómo aparecen tus topics locales en el portal. Más proyectos con la Pi en el tutorial de MQTT con Raspberry Pi.
Preguntas frecuentes
¿Por qué Mosquitto rechaza conexiones de otros dispositivos tras la instalación?
Mosquitto 2.0 solo escucha en localhost y rechaza clientes anónimos a menos que configures un listener. Añade listener 1883 0.0.0.0 con allow_anonymous false y un archivo de contraseñas.
¿Debo exponer a internet el broker Mosquitto de mi Raspberry Pi?
No se recomienda. En su lugar, haz un bridge saliente hacia un broker en la nube, para que el acceso remoto pase por un servicio protegido con TLS y tu router mantenga cerrados todos los puertos de entrada.
¿Puede Mosquitto en una Raspberry Pi gestionar muchos dispositivos?
Para un hogar o un sitio pequeño, una Pi maneja con facilidad el tráfico típico de sensores. Los primeros límites que encuentras suelen ser el desgaste de la tarjeta SD y el esfuerzo de mantenimiento, más que el rendimiento bruto.
¿Necesita el bridge una cuenta especial en ConnectMQ?
No. El bridge es un cliente MQTT normal, así que usa el mismo usuario, contraseña y client ID que el portal genera para cualquier dispositivo.
