Guías

sequence es un entero por dispositivo que debe crecer ESTRICTAMENTE. El backend guarda una marca máxima duradera y descarta en silencio todo mensaje cuyo sequence sea menor o igual al último que aceptó, incluso si la firma y la marca de tiempo son perfectamente válidas.

Inicialícelo con el reloj del sistema (int(time.time())) e incremente desde ahí. De esa marca máxima duradera se derivan tres trampas:

• Un contador que empieza en 0 o 1 funciona exactamente una vez, y después se descarta todo mensaje posterior, incluso tras cada reinicio.
• Un dispositivo que antes usó otro transporte ya tiene una marca alta registrada, así que su primer frame MQTT con numeración baja también se rechaza.
• Dentro de un lote, las secuencias también deben crecer: el backend recorre la lista en orden y rechaza el lote COMPLETO en el primer valor que no crece.

event_id es aparte y opcional: una clave de idempotencia. Reenviar un mensaje con un event_id visto recientemente para el mismo dispositivo se deduplica en vez de contarse dos veces. Protege contra una carrera de reintento tras un tiempo de espera, no contra reenviar horas después.

1. No hay nada que volver a autenticar. MQTT autentica dentro del propio CONNECT, así que una reconexión exitosa ya es una sesión plenamente autenticada.
2. Use espera progresiva: empiece en 1-2 s y duplique hasta un tope de ~30 s. Nunca un bucle de reconexión sin pausa.
3. Vuelva a suscribirse a su topic cmd en cada conexión. Las sesiones son limpias, así que las suscripciones no sobreviven a una reconexión. Suscribirse desde su callback de conexión resuelve esto sin esfuerzo.
4. La mayoría de las bibliotecas cliente ya reconectan por usted una vez que su bucle de red está en marcha (en paho: loop_start() más reconnect_delay_set()). Prefiera eso antes que implementarlo a mano.

Una credencial revocada o regenerada se expulsa del broker de inmediato, y reconectar con la antigua falla en el CONNECT: eso es un problema de credenciales, no de red; ninguna espera progresiva lo arregla.

El keepalive es el tiempo máximo que su cliente puede permanecer en silencio antes de que el broker dé la conexión por muerta. Su cliente lo propone en el CONNECT; si no envía nada más en esa ventana, debe enviar un PINGREQ.

30 segundos es un buen valor por defecto y es el que usan todos los ejemplos de IoT Manager. Un valor menor detecta antes una conexión TCP rota a cambio de más despertares de radio; uno mucho mayor hace que un dispositivo que se cayó de la red parezca conectado durante minutos.

El keepalive no es presencia. Que el panel marque un dispositivo como desconectado depende de un tiempo de espera distinto, basado en la telemetría (120 s por dispositivo por defecto, mínimo 30 s): no hay topic de estado ni Last Will, así que un dispositivo que mantiene la conexión abierta pero deja de publicar igual pasa a desconectado.

Mientras esté desconectado, siga capturando en un buffer local ACOTADO: un buffer circular en un microcontrolador. Un buffer sin límite convierte una caída de red en un fallo por falta de memoria; descartar la lectura más antigua es el intercambio correcto.

Al reconectar, publique el backlog en lotes, del más antiguo al más reciente: como máximo 100 mensajes cada uno y por debajo de 64 KB cada uno. Conserve el timestamp propio de cada mensaje como el momento en que se OBSERVÓ, y firme el frame de nuevo al vaciarlo para que su ts LM1 esté vigente.

El backlog se acepta aunque llegue todo de golpe: los límites de tasa se miden por la marca de tiempo firmada de cada mensaje, no por la hora de llegada. Un backlog QoS 1 vaciado tras reiniciar el broker o el backend se ingiere en lugar de descartarse.

Este transporte no tiene frame de error. Un mensaje rechazado (firma incorrecta, marca de tiempo vieja o futura, secuencia repetida, mensaje demasiado grande, JSON mal formado o un límite de tasa) simplemente se descarta. El PUBACK de QoS 1 que recibió confirma que el broker lo recibió, nunca que el backend lo aceptó.

Cuando no llega nada, diagnostique en este orden:

1. ¿El CONNECT tuvo éxito? Un usuario, clientid o contraseña equivocados fallan ahí, de forma visible.
2. ¿El reloj del dispositivo está bien? Más de 3600 s de antigüedad o 300 s de adelanto se descarta.
3. ¿sequence supera todo lo que este dispositivo haya enviado alguna vez?
4. ¿El frame está por debajo de 64 KB y dentro de los límites de lote?
5. ¿Está enviando más rápido de lo que permite su plan?

Para confirmar de verdad que un dispositivo se está ingiriendo, use un viaje de ida y vuelta con cmd/ack o la vista de telemetría en vivo del panel. No tome el PUBACK como prueba.