Cuando un ESP32 tiene que hablar con un servidor, las dos opciones más comunes son HTTP, el protocolo de la web, y MQTT, el protocolo de mensajería pensado para IoT. Los dos funcionan; la diferencia está en qué tiene que hacer tu dispositivo.
En un sistema de domótica es normal usar los dos: MQTT entre los dispositivos y la nube, y HTTP para una API que llama, por ejemplo, Siri. En esta comparativa te explico qué hace bien cada uno y dónde encaja.
La diferencia de fondo
HTTP es pregunta y respuesta. El cliente abre una conexión, hace una petición, recibe la respuesta y (normalmente) se acaba. El servidor no puede hablarle al cliente si el cliente no pregunta.
MQTT es publicar y suscribirse. El dispositivo abre una conexión que se queda abierta con un broker y, a través de ella, publica mensajes en tópicos y recibe los mensajes de los tópicos a los que está suscrito. El servidor puede enviarle algo en cualquier momento.
Comparación
| HTTP | MQTT | |
|---|---|---|
| Modelo | Petición y respuesta | Publicar y suscribirse a través de un broker |
| Conexión | Una por petición (o reutilizada un rato) | Una permanente |
| ¿El servidor puede enviar órdenes al dispositivo? | No, salvo que el dispositivo consulte | Sí, al instante |
| Tamaño de cada mensaje | Cabeceras de texto que pesan | Cabecera mínima, de pocos bytes |
| Latencia de una orden | La del próximo sondeo del dispositivo | Inmediata |
| Garantía de entrega | La da TCP en cada petición | Niveles de QoS 0, 1 y 2 |
| Saber si el dispositivo se desconectó | No directamente | Mensaje de última voluntad (LWT) |
| Necesita | Un servidor web o una API | Un broker MQTT |
| Ideal para | Enviar datos de vez en cuando; integraciones y APIs | Recibir órdenes y estado en tiempo real |
Cuándo usar HTTP
- El dispositivo solo envía datos de vez en cuando: un sensor que reporta la temperatura cada diez minutos y vuelve a dormir. Abrir una conexión, enviar y cerrar es más simple que mantener una conexión abierta.
- Llamas a una API existente: un servicio del clima, un webhook, una función en la nube.
- El que llama no es un dispositivo: por ejemplo, un Atajo de Siri envía un POST con un token a una Lambda, porque los Atajos hablan HTTP y no MQTT (parte 8 de la serie de domótica).
#include <WiFi.h>
#include <HTTPClient.h>
void enviarTemperatura(float t) {
HTTPClient http;
// En producción, usa HTTPS: http.begin(clienteSeguro, url) con un WiFiClientSecure y su CA
http.begin("http://tu-servidor.local/api/lecturas");
http.addHeader("Content-Type", "application/json");
int codigo = http.POST(String("{\"temperatura\":") + t + "}");
Serial.printf("Respuesta: %d\n", codigo);
http.end();
}
Cuándo usar MQTT
- El dispositivo tiene que recibir órdenes: encender una luz desde la app. Con HTTP tendría que preguntar cada pocos segundos "¿hay algo para mí?", con latencia y consumo innecesarios.
- Varios clientes ven el mismo estado: la app de cada persona de la casa recibe al instante los cambios, porque todas están suscritas al mismo tópico.
- Quieres saber si el dispositivo está conectado, con la última voluntad o los eventos de conexión del broker.
#include <WiFi.h>
#include <MQTTClient.h> // librería MQTT de 256dpi
WiFiClient red; // WiFiClientSecure en producción, con TLS
MQTTClient cliente(512);
void alRecibir(String &topico, String &mensaje) {
if (topico == "casa/sala/luz") {
digitalWrite(LED_PIN, mensaje == "on" ? HIGH : LOW);
}
}
void conectar() {
cliente.begin("broker.ejemplo", 1883, red);
cliente.onMessage(alRecibir);
while (!cliente.connect("esp32-sala")) delay(1000);
cliente.subscribe("casa/sala/luz");
}
void loop() {
cliente.loop(); // mantiene la conexión y entrega los mensajes
if (!cliente.connected()) conectar();
}
Define LED_PIN según tu placa y llama a conectar() desde setup() después de conectar el Wi-Fi. Con AWS IoT Core se usa MQTT sobre TLS y el Device Shadow, que además guarda el estado mientras el dispositivo está desconectado (parte 3).
Consumo y memoria
- MQTT mantiene una conexión abierta: el Wi-Fi no puede dormir del todo. Para un dispositivo enchufado no importa; para uno con batería, sí.
- HTTP abre y cierra: puede dormir entre envíos, pero cada conexión (sobre todo con TLS) tarda y consume en el momento.
- Con TLS, ambos necesitan memoria para los buffers. Una sola conexión MQTT permanente suele ser más eficiente que muchas conexiones HTTPS seguidas.
Lo mejor de los dos
No hay que elegir uno para todo el sistema. Un reparto habitual:
- MQTT donde hace falta tiempo real y comunicación en los dos sentidos: dispositivo y app con la nube.
- HTTP donde el cliente solo puede hacer peticiones: Siri, integraciones, tareas de administración.
Si quieres ver todas las opciones de comunicación de un ESP32, incluidos ESP-NOW y Bluetooth, tienes la guía de comunicación de este blog.
Preguntas frecuentes
¿MQTT es más rápido que HTTP?
Para enviar órdenes a un dispositivo, sí: el mensaje llega por la conexión ya abierta, sin esperar a que el dispositivo pregunte. Para una petición puntual, la diferencia es pequeña.
¿Necesito un servidor para MQTT?
Un broker: puede ser uno propio, como Mosquitto en una Raspberry Pi, o uno administrado en la nube, como AWS IoT Core.
¿Se puede usar MQTT desde el navegador?
Sí, con MQTT sobre WebSocket y una URL firmada (parte 10).
¿Y WebSocket en lugar de MQTT?
WebSocket es un canal abierto en los dos sentidos, pero sin tópicos, sin QoS y sin broker: tendrías que construir esa lógica. MQTT sobre WebSocket te da las dos cosas.
