La pregunta Raspberry Pi vs ESP32 aparece en casi todos los proyectos IoT, y la respuesta honesta es que resuelven problemas distintos. Esta guía compara un ordenador de placa única con Linux y un microcontrolador con Wi-Fi en lo que de verdad decide un despliegue: consumo, coste, fiabilidad, esfuerzo de desarrollo y opciones de cliente MQTT. Al final sabrás qué placa poner en cada sitio y cómo hacer que ambas hablen con el mismo broker.
Dos clases de dispositivo diferentes
Una Raspberry Pi es un ordenador completo. Arranca Linux desde una tarjeta SD o un SSD y ejecuta un gestor de paquetes, varios procesos, Python, Node.js, Docker, un servidor web y una base de datos al mismo tiempo. Un ESP32 es un microcontrolador: un chip de doble núcleo con unos cientos de kilobytes de RAM, Wi-Fi y Bluetooth integrados, que ejecuta una única imagen de firmware que grabas por USB. No hay sistema operativo en el sentido de escritorio, solo FreeRTOS por debajo de tu código Arduino o ESP-IDF.
Esa diferencia de clase lo condiciona todo. La Pi te da flexibilidad y un enorme ecosistema de software; el ESP32 te da determinismo, bajo consumo y la posibilidad de meterlo en una caja y olvidarte. Ninguno es "mejor" en abstracto.
Raspberry Pi vs ESP32 de un vistazo
| Criterio | Raspberry Pi (4, 5, Zero 2 W) | ESP32 (clásico, S3, C6) |
|---|---|---|
| Tipo | Ordenador de placa única con Linux | Microcontrolador con Wi-Fi/Bluetooth |
| Tiempo de arranque | Decenas de segundos | Muy por debajo de un segundo |
| Consumo típico en reposo | Vatios | Milivatios; microamperios en deep sleep |
| Funcionamiento con batería | Poco práctico durante periodos largos | Diseñado para ello con deep sleep |
| Almacenamiento | Tarjeta SD o SSD con sistema de archivos | Flash interna, no requiere sistema de archivos |
| Corte de luz repentino | Puede corromper la tarjeta SD | Por lo general inofensivo |
| Lenguajes | Python, Node.js, Go, C#, Java, cualquier cosa en Linux | C/C++ (Arduino, ESP-IDF), MicroPython |
| Clientes MQTT | paho-mqtt, MQTT.js, herramientas de Mosquitto, Node-RED | PubSubClient, AsyncMqttClient, ESP-MQTT, umqtt |
| TLS | OpenSSL completo, trivial de activar | Compatible, pero los certificados y la RAM requieren cuidado |
| Cámara, ML, dispositivos USB | Fácil | Limitado (ESP32-CAM, TinyML) |
| Actualizaciones remotas | apt, git pull, contenedores | Imágenes de firmware OTA |
| Coste unitario | Más alto | Más bajo |
Consumo y duración de la batería
El consumo es donde la comparativa está más desequilibrada. Una Raspberry Pi nunca duerme de verdad; incluso la Zero 2 W consume una corriente constante siempre que está encendida, y una Pi 5 con periféricos necesita una fuente USB-C adecuada. Alimentar una Pi con un power bank sirve para una demo de fin de semana, no para un sensor en el campo.
Un ESP32 puede despertarse, leer un sensor, conectarse al Wi-Fi, publicar un mensaje MQTT y volver al deep sleep en pocos segundos. Entre despertares consume una fracción minúscula de su corriente activa, y así es como placas del tamaño de una moneda funcionan durante meses con una sola celda. Si tu dispositivo no tiene alimentación de red, la decisión está prácticamente tomada: usa el ESP32 y lee nuestra guía de ESP32 en deep sleep con MQTT para el patrón de publicar y dormir.
Fiabilidad en campo
Los microcontroladores son difíciles de romper. Si un ESP32 pierde la alimentación en mitad de una escritura, simplemente se reinicia con el mismo firmware. Un temporizador watchdog lo reinicia si tu bucle se cuelga, y no hay sistema de archivos que corromper.
Una Raspberry Pi es más frágil en instalaciones desatendidas. Los modos de fallo habituales son:
- Corrupción de la tarjeta SD tras cortes de luz bruscos repetidos o un registro de logs intensivo.
- Subtensión por una fuente débil, que provoca cuelgues aleatorios y caídas del Wi-Fi.
- Un script de Python que termina por una excepción y nadie lo reinicia.
- Disco lleno de logs al cabo de los meses.
Los cuatro tienen solución: usa una fuente de calidad, registra en RAM o reduce los logs, arranca desde un SSD en una Pi 4 o Pi 5 y ejecuta tu script MQTT como servicio systemd con Restart=always. Nuestra guía para ejecutar un script MQTT de Python al arrancar explica el archivo de servicio paso a paso. Una vez blindada, una Pi funciona durante largos periodos sin atención, pero necesita ese paso de blindaje que un ESP32 no requiere.
Velocidad de desarrollo y depuración
En una Pi entras por SSH, editas un archivo de Python, lo ejecutas, lees el traceback e iteras en segundos. Puedes instalar mosquitto-clients y observar el tráfico en el mismo dispositivo, usar htop para revisar la memoria y mantener un checkout completo de git en la placa. Para procesamiento de datos, manejo de imágenes o cualquier cosa que implique una base de datos, esto es mucho más rápido que el desarrollo embebido.
En un ESP32 cada cambio implica compilar y grabar, y la depuración se basa sobre todo en mensajes por el puerto serie. A cambio, el firmware terminado es pequeño, arranca al instante y se comporta igual cada vez. Muchos equipos prototipan la lógica en una Pi con Python y después portan la parte estable al ESP32.
Comparativa de opciones de cliente MQTT
Ambas plataformas son clientes MQTT de primera, pero la experiencia es distinta.
En la Raspberry Pi tienes las mismas librerías que en un servidor. paho-mqtt 2.x de Python admite MQTT 3.1.1 y 5.0, TLS, websockets y reconexiones automáticas. MQTT.js cubre Node.js, Node-RED funciona de forma nativa y las herramientas de línea de comandos de Mosquitto están a un apt install de distancia. Una Pi también puede actuar como gateway: leer dispositivos Modbus, BLE o serie y reenviarlos por MQTT.
En el ESP32, PubSubClient es la opción más sencilla para MQTT 3.1.1 con publicación en QoS 0; AsyncMqttClient y el componente esp-mqtt de ESP-IDF añaden QoS 1 y 2 y funcionamiento no bloqueante. MicroPython ofrece umqtt.simple. El soporte de MQTT 5 es más escaso en los microcontroladores, y TLS consume una parte considerable de la RAM, así que debes planificar los tamaños de buffer. Un tutorial de MQTT con ESP32 usando PubSubClient y WiFiClientSecure muestra un sketch completo preparado para TLS.
Una forma rápida de comprobar que ambas placas se comportan igual en la red es apuntarlas al mismo broker y observar desde tu portátil:
# Observa todo lo que publican tus dispositivos bajo tu propio prefijo
mosquitto_sub -h broker.connectmq.com -p 1883 -i watcher-7f3a91 \
-t 'connectmq/demo/7f3a91/#' -v
En la Pi, una publicación de una línea confirma la ruta de red:
mosquitto_pub -h broker.connectmq.com -p 1883 -i rpi-7f3a91 \
-t 'connectmq/demo/7f3a91/rpi/status' -m 'online'
El servidor MQTT público gratuito broker.connectmq.com es anónimo y legible por cualquiera, así que usa un prefijo aleatorio y nunca envíes datos sensibles.
Coste más allá del precio de la placa
El ESP32 es más barato por unidad, pero el coste total incluye más que el chip. Una Pi necesita una fuente de alimentación, una tarjeta SD o un SSD y a menudo una caja. Un ESP32 necesita un regulador, posiblemente una batería y un circuito de carga, y una caja. Por otro lado, el tiempo de ingeniería suele ser el mayor coste en despliegues pequeños, y Python en una Pi puede ahorrar días de trabajo de firmware en instalaciones únicas. Para decenas o cientos de nodos sensores idénticos, el menor coste unitario y el menor consumo del ESP32 ganan con claridad.
Cuándo elegir cada placa
Elige una Raspberry Pi cuando el dispositivo deba:
- Ejecutar varios servicios, como Node-RED, una base de datos local y un dashboard.
- Procesar imágenes de cámara, audio o modelos de machine learning.
- Actuar como gateway para dispositivos USB, serie, Modbus o Bluetooth.
- Desarrollarse y modificarse rápidamente en Python o Node.js.
Elige un ESP32 cuando el dispositivo deba:
- Funcionar con baterías o con energía captada del entorno.
- Arrancar al instante y sobrevivir a cortes de luz sin cuidados.
- Ser lo bastante barato para desplegarse en grandes cantidades.
- Hacer un solo trabajo: leer sensores, conmutar salidas, publicar y suscribirse.
Usar ambos juntos
Las arquitecturas más robustas los combinan. Los nodos ESP32 se sitúan junto a los sensores y actuadores y publican pequeños payloads JSON. Una o varias Raspberry Pi se suscriben a esos topics para ejecutar lógica local, flujos de Node-RED, una pila de Grafana o una cámara. Ningún dispositivo habla directamente con el otro; ambos hablan con un broker MQTT, lo que los desacopla por completo. Puedes sustituir un ESP32 por una Pi, o al revés, sin tocar el resto del sistema mientras se mantenga el mismo contrato de topics y payloads.
Dónde se ejecuta ese broker importa en cuanto el proyecto sale de tu mesa. Ejecutar Mosquitto en la propia Pi está bien para un laboratorio, pero convierte la Pi en un punto único de fallo y te deja a cargo de TLS, la autenticación y el acceso remoto. Un broker MQTT gestionado como ConnectMQ da a ambas placas un endpoint TLS estable en el puerto 8883, credenciales generadas por dispositivo y un explorador de topics en vivo para depurar el tráfico, sin redirección de puertos en el router de tu casa o tu fábrica.
Para profundizar en el lado de la Pi, empieza por el tutorial de MQTT con Raspberry Pi y después prueba un montaje práctico como controlar una placa de relés por MQTT. Si también estás valorando microcontroladores más pequeños, la comparativa ESP32 frente a Raspberry Pi Pico W cubre esa elección.
Lista de decisión
Repasa estas preguntas antes de pedir el hardware:
- ¿Hay alimentación de red en el lugar de instalación? Si no, elige ESP32.
- ¿Necesita el dispositivo una cámara, almacenamiento local o varios servicios? Si sí, elige una Pi.
- ¿Vas a desplegar más de un puñado de nodos idénticos? Inclínate por el ESP32.
- ¿Importa más la velocidad de desarrollo que el coste unitario? Inclínate por la Pi.
- ¿Debe el dispositivo sobrevivir a cortes de luz frecuentes sin mantenimiento? Inclínate por el ESP32, o blinda la Pi.
- ¿Necesitas funciones de MQTT 5, como la caducidad de mensajes o los response topics, en el propio dispositivo? Es más fácil en una Pi.
Empieza con ConnectMQ
Elijas la placa que elijas, necesita un broker al que pueda llegar desde cualquier lugar. ConnectMQ ofrece un broker MQTT en la nube con MQTT 3.1.1 y 5.0, TLS en el 8883 y WebSocket seguro en el 8084 para dashboards. Crea un broker Serverless gratuito sin tarjeta de crédito, copia el nombre de usuario, la contraseña y el client ID generados en tu script de la Pi o tu sketch del ESP32 y observa cómo aparecen ambos dispositivos en el explorador de topics del portal. Cuando necesites más conexiones o QoS 2, puedes pasar a un plan Serverless de pago o Dedicated sin cambiar tu código, y la guía del broker MQTT en la nube explica las ventajas y desventajas.
Preguntas frecuentes
¿Es un ESP32 más fiable que una Raspberry Pi?
Para tareas de sensores sencillas y desatendidas, normalmente sí, porque no tiene sistema de archivos que corromper y se reinicia en menos de un segundo. Una Pi bien blindada, con una buena fuente de alimentación y un servicio systemd, también es fiable, pero requiere más cuidado.
¿Pueden una Raspberry Pi y un ESP32 usar el mismo broker MQTT?
Sí. MQTT es independiente de la plataforma, así que ambos se conectan al mismo broker, publican en topics acordados y nunca necesitan saber el uno del otro.
¿Cuál es mejor para sensores alimentados por batería?
El ESP32, con mucha diferencia. Su modo deep sleep le permite publicar una lectura y apagarse entre mediciones, algo que una Raspberry Pi no puede hacer.
¿Debo ejecutar el broker MQTT en mi Raspberry Pi?
Sirve para aprender, pero ata todos los dispositivos a una sola tarjeta SD y a una sola red doméstica. Un broker alojado elimina ese punto único de fallo y te da TLS y acceso remoto sin cambios en el router.
