DÍA 211 DE 365

Fase 4: FreeRTOS y Conectividad IoT

📖 Teoría a Estudiar

El Paradigma Cliente-Servidor (HTTP) vs. Publicador-Suscriptor (MQTT)

HTTP es síncrono. Si tu máquina quiere saber si cambiaron el precio del Gas LP, tiene que abrir un túnel TCP, enviar un bloque de texto gigante preguntando, y esperar la respuesta. Si el servidor no tiene cambios, responderá "Nada nuevo", y habrás gastado batería y datos inútilmente. A esto se le llama Polling.

MQTT es asíncrono y orientado a eventos. Funciona bajo el modelo Pub/Sub. Desaparece el concepto de "Servidor y Cliente" y aparece el Broker (El cartero central). Tu despachador de gas se conecta al Broker una sola vez y le dice: "Suscríbeme al tema (Topic) 'precio/guadalajara'". A partir de ese momento, tu máquina no pregunta nada, simplemente duerme. Si mañana el dueño cambia el precio en la App, la App Publica el dato en el Broker, y el Broker se lo "empuja" (Push) instantáneamente a la máquina.

Anatomía de la Ligereza (Overhead)

Ambos protocolos usan TCP por debajo para garantizar la entrega. Sin embargo, el encabezado HTTP que armamos en el Día 208 pesa ~150 bytes. El encabezado de un paquete MQTT pesa ¡apenas 2 bytes! Esto hace que MQTT sea hasta 90 veces más rápido y eficiente en redes celulares inestables.

PARADIGMA HTTP POLLING VS MQTT PUB/SUB HTTP (Cliente-Servidor) Pesado, Síncrono, "Polling" Máquina Gas Servidor REST GET /precio (150 Bytes) HTTP 304 Not Modified GET /precio (150 Bytes) HTTP 304 Not Modified Precio cambia GET /precio (150 Bytes) HTTP 200: {"p":10.5} Desperdicio de CPU y Red constante MQTT (Pub / Sub) Ligero, Asíncrono, "Push" Máquina Gas MQTT BROKER (Ej. AWS IoT Core) App Dueño Subscribe: "disp/precio" SLEEP (Ahorra Red) Precio cambia Publish: {"p":10.5} PUSH! Despierta ISR Actualiza Precio Conexión Viva (Keep-Alive) Latencia Cero

⚙️ Ejercicios Prácticos

Circuito: El ESP32 incluye de forma nativa un cliente MQTT en su firmware oficial (ESP-AT). No necesitas cambiar hardware, ni importar librerías voluminosas como PubSubClient al STM32. Todo se maneja por comandos AT.

Ejercicio 1: Evolucionaremos nuestro conocimiento de comandos AT. Compararemos cómo se ve conceptualmente la misma tarea de envío de JSON, primero usando el viejo HTTP POST (Día 208) y luego usando la modernidad de MQTT. Observa la drástica reducción de complejidad.


/**
 * @file mqtt_vs_http_concept.c
 * @brief Comparación conceptual del esfuerzo de transmisión (HTTP vs MQTT)
 */

// =======================================================
// EL METODO VIEJO: HTTP POST (Requiere Ensamblador)
// =======================================================
/*
// 1. STM32 Construye 150 bytes de Headers + 30 bytes de JSON.
char paquete_http[] = 
    "POST /api/ventas HTTP/1.1\r\n"
    "Host: api.aws.com\r\n"
    "Content-Type: application/json\r\n"
    "Content-Length: 29\r\n\r\n"
    "{\"ticket\":123,\"litros\":20.5}";

// 2. Transmisión de 2 pasos
AT_Enviar_Comando("AT+CIPSEND=179\r\n", 1000);  // Pedir permiso para 179 bytes
Esperar_Prompt_Mayor_Que();
HAL_UART_Transmit(paquete_http, 179);           // Inyectar el bloque gigante
Esperar_HTTP_200_OK();                          // Esperar que el servidor procese
*/


// =======================================================
// EL METODO MODERNO: MQTT PUBLISH (Nativo del ESP-AT)
// =======================================================
/*
// Configuración Inicial (Se hace UNA sola vez al arrancar la FSM)
// AT+MQTTUSERCFG=0,1,"Cliente_Gas","Usuario","Pass",0,0,""
// AT+MQTTCONN=0,"broker.aws.com",1883,1

// 1. STM32 solo arma la carga útil (El JSON de 29 bytes)
char mi_json[] = "{\"ticket\":123,\"litros\":20.5}";

// 2. Transmisión de 1 solo paso (El ESP32 arma los 2 bytes de Header MQTT)
// Sintaxis AT: AT+MQTTPUB=<LinkID>,"<Topic>","<Data>",<QoS>,<Retain>
char comando_mqtt[128];
snprintf(comando_mqtt, sizeof(comando_mqtt), 
         "AT+MQTTPUB=0,\"gas/ventas\",\"%s\",1,0\r\n", 
         mi_json);

// Disparar por UART y listo. El ESP32 se encarga del QOS (Quality of Service).
HAL_UART_Transmit(comando_mqtt, strlen(comando_mqtt));

// ¡CERO HEADERS MANUALES! ¡CERO CÁLCULOS DE CONTENT-LENGTH!
*/
        

🚀 Avance del Proyecto Tesis: Despachador de Gas LP

Objetivo del día: Migración a Arquitectura Orientada a Eventos y Eficiencia de Ancho de Banda.

En el mundo real del Internet de las Cosas, los proveedores de telefonía (Telcel, AT&T) te venden tarjetas SIM IoT (M2M) que cobran por cada Kilobyte transferido. Si usas HTTP POST para informar el "Latido de Vida" (Heartbeat) de la máquina cada 30 segundos, consumirás Megabytes de datos al mes solo en encabezados de texto inútiles. Multiplica eso por 100 máquinas y tus costos operativos se disparan.

Al migrar el core de telecomunicaciones de tu tesis hacia **MQTT**, has transformado a tu Despachador de un "Llamador compulsivo" a un "Oyente silencioso". La máquina abre el túnel TCP, negocia la conexión con el *Broker MQTT* y mantiene la tubería abierta con ligeros pings de 2 bytes (Keep-Alive). Cuando tu máquina despacha gas, *Publica* la venta de forma fulminante en el tema `gas/ventas`. Cuando la nube quiere subir el precio a $11.50, simplemente lo publica en `gas/precio` y la máquina despierta por una interrupción, lo actualiza, y vuelve a dormir. Has logrado latencia cero, control bidireccional en tiempo real y has reducido tu consumo de ancho de banda celular en un 90%. Eres oficialmente un desarrollador IoT.

📝 Resumen del Día