MQTT vs. HTTP en IoT celular: cómo reducir el consumo de datos y estirar la batería en tus sensores

Un sensor de nivel de agua, una central de alarma o un inversor fotovoltaico no necesitan "navegar por internet": necesitan enviar unos pocos bytes, de vez en cuando, con la menor batería y los menores datos posibles. Y ahí, el protocolo que usa el dispositivo para comunicarse pesa tanto como la tecnología de red — NB-IoT, LTE-M o 4G— que lleve la SIM.

Dos protocolos dominan ese envío de datos: HTTP, heredado de la web, y MQTT, diseñado específicamente para telemetría con recursos limitados. Elegir mal entre ellos no rompe el proyecto, pero sí puede duplicar el consumo de datos y reducir a la mitad la autonomía de un sensor con pilas.

HTTP funciona con el modelo de toda la web: el dispositivo abre una conexión, envía una petición completa (con cabeceras, método y formato del contenido) y espera una respuesta antes de poder cerrarla. Es el protocolo sobre el que están construidas la inmensa mayoría de las API REST, lo que lo hace muy fácil de integrar con un backend ya existente.

El coste de esa sencillez aparece en el detalle técnico: cada envío implica normalmente levantar una conexión TCP nueva —y, si hay cifrado, una negociación TLS encima—, transmitir cabeceras que pueden pesar varias veces más que el dato real, y mantener el radio del módulo celular encendido durante toda la negociación. Para un sensor que manda "nivel: 42 cm" una vez cada hora, ese sobrecoste de conexión puede representar la mayor parte de los datos consumidos y del tiempo de radio activo, que es lo que más batería gasta.

MQTT nació para justamente este escenario: dispositivos con poca energía, conexiones poco fiables y mensajes pequeños y frecuentes. En lugar de petición-respuesta, usa un modelo de publicación/suscripción: el dispositivo se conecta una vez a un broker (el servidor que redistribuye los mensajes) y, a partir de ahí, publica mensajes cortos sobre un "tema" (topic) sin tener que reabrir la conexión cada vez.

La conexión puede mantenerse activa con mensajes de keep-alive muy ligeros, y cada mensaje de datos lleva una cabecera mínima —puede ser de solo 2 bytes— en lugar de las cabeceras completas de HTTP. MQTT también permite elegir el nivel de garantía de entrega (QoS) según la criticidad del mensaje, algo relevante en una alarma o en teleasistencia, donde perder un aviso no es aceptable.

La diferencia no es solo técnica: cambia cómo se diseña todo el flujo de datos del dispositivo.

HTTP no es un protocolo obsoleto para IoT; sigue siendo razonable cuando:

• El dispositivo envía datos con poca frecuencia (unas pocas veces al día) y la batería no es el factor crítico, por ejemplo equipos con alimentación permanente como routers industriales o maquinaria de vending conectada a red eléctrica.
• Ya existe una integración REST en el backend del cliente y no compensa operativamente introducir un broker MQTT.
• El caso de uso es puntual: firmware que se actualiza, configuración que se sube una vez, o un reporte diario.

MQTT marca la diferencia cuando el proyecto tiene alguno de estos rasgos:

• Dispositivos con batería, como contadores de agua, sensores en arquetas o balizas, donde cada segundo de radio activo cuenta.
• Telemetría frecuente, con envíos cada pocos segundos o minutos (teleasistencia, monitorización de una central de alarma, maniobra de un ascensor).
• Volumen de datos ajustado, cuando el proyecto gestiona un pool de datos compartido entre muchos dispositivos y cada byte de cabecera multiplicado por miles de SIM sí tiene impacto en la factura.
• Redes celulares con cobertura variable, donde una conexión persistente con reconexión gestionada por el propio protocolo resulta más robusta que reabrir sesiones HTTP constantemente.

Elegir MQTT reduce drásticamente el volumen de datos y el tiempo de radio activo, pero no corrige un problema de cobertura o de gestión de SIM. Un protocolo eficiente sobre una red con cortes frecuentes sigue generando reconexiones —y consumo— innecesarias. La combinación que mejor funciona en despliegues reales de bajo consumo suele ser MQTT sobreNB-IoT o LTE-M, con una SIM gestionada que permita controlar el consumo real y la batería por dispositivo y detectar anomalías de forma centralizada.

MQTT no es "mejor" que HTTP en términos absolutos: es el protocolo adecuado cuando el objetivo es minimizar datos y batería en telemetría frecuente, mientras que HTTP sigue siendo razonable para integraciones puntuales o equipos con alimentación permanente. La decisión correcta depende del perfil energético del dispositivo, de la frecuencia de envío y de si ya existe infraestructura previa que no compensa cambiar.