La primera integración típica entre un parque de lectores y un ERP es HTTP: la pasarela publica cada lote de lecturas en un endpoint, Odoo lo recibe y todos se van a casa. Tres meses después el endpoint empieza a expirar en carga punta, la pasarela reintenta contra un muro y los eventos perdidos son exactamente los que habrían explicado la discrepancia de stock.

MQTT es la solución habitual y es buena, pero solo si se entiende como un transporte con garantías concretas y no como una cola que hace desaparecer el problema por arte de magia.

Por qué falla el polling HTTP a ritmos de eventos RFID

El fallo no es cuestión de ajuste; es estructural.

El polling significa que el cliente pregunta; con diez mil etiquetas por hora, el preguntar mismo se vuelve la carga.
Una respuesta lenta del ERP bloquea la pasarela, así que los lectores o bufferizan en memoria o descartan eventos en el borde.
El jitter convierte una llamada sincrónica en un timeout, y un timeout en una lectura no registrada.
No hay canal inverso natural: Odoo no puede decirle a la pasarela que baje el ritmo, cambie de modo o relea una zona.
Las tormentas de reintentos amplifican el problema original, porque cada petición fallida se repite mientras llegan eventos nuevos.

Qué cambia el modelo publicación-suscripción

El broker inserta un búfer persistente y direccionable entre las dos partes, y eso cambia los modos de fallo.

El lector publica y se olvida; la entrega pasa a ser problema del broker y no del lector.
El lado de negocio se suscribe a su propio ritmo, así que un ERP lento frena el puente, no la radio.
Los topics aportan un vocabulario de enrutamiento: sitio, zona, lector y tipo de evento se pueden direccionar por separado.
El broker puede bufferizar mientras el consumidor se reinicia, lo que convierte una caída en un retraso.
Los topics de comando permiten que Odoo o un operador empujen configuración hacia los lectores.

El árbol de topics es el contrato

La mayoría de las integraciones MQTT envejecen mal porque el árbol de topics se improvisó, y ahora cada consumidor parsea cadenas.

Diseñe la jerarquía una sola vez: sitio, zona, lector, tipo de evento, y mantenga el orden para siempre.
Publique lecturas crudas en una rama y eventos de negocio resueltos en otra; tienen consumidores distintos y necesidades de retención distintas.
Use una rama separada para estado y latido, así un lector muerto se ve sin recorrer el flujo de eventos.
Los comodines son cómodos para herramientas y peligrosos para consumidores de producción, porque una suscripción puede ensancharse en silencio.
Versione el árbol, no solo el payload; un nivel renombrado rompe más que un campo renombrado.

Diseño del payload: pequeño, versionado, autodescriptivo

Los payloads también son contratos, y el coste de equivocarse llega tarde.

Incluya lo esencial por evento: hora del evento en el lector, identificador, antena, EPC, intensidad de señal y una secuencia monotónica.
Prefiera marcas de tiempo numéricas en milisegundos del dispositivo, con la hora de recepción de la pasarela en un campo aparte.
Mantenga el esquema plano cuando sea posible; las estructuras anidadas son más difíciles de validar y de indexar.
Lleve una versión explícita de esquema y de firmware, porque el comportamiento de los campos cambia con el firmware más que con el esquema.
Comprima solo cuando el ancho de banda esté realmente limitado; un broker lleno de blobs binarios es un broker que nadie puede depurar.

QoS, mensajes retenidos y lo que garantizan de verdad

Los tres niveles de QoS se describen mucho y se entienden poco.

QoS cero es disparar y olvidar: vale para lecturas crudas de alto ritmo donde la siguiente lectura en un segundo la reemplaza.
QoS uno garantiza al menos una entrega, lo que significa duplicados, y los duplicados obligan a que el puente sea idempotente.
QoS dos garantiza exactamente una entrega a nivel de protocolo, al coste de un handshake de cuatro pasos por mensaje.
Los mensajes retenidos son para estado, no para eventos: el último estado conocido de un lector pertenece ahí, una lectura de etiqueta no.
El testamento es lo que hace visible un lector muerto en segundos en lugar de en la siguiente auditoría.

El puente: donde el protocolo se vuelve evento de negocio

El puente es una aplicación real con estado, y es donde se crea o se destruye el valor.

Suscríbase a lecturas crudas, deduplique por EPC dentro de una ventana y agregue en deltas con signo.
Resuelva EPC a producto y lote desde un mapeo en caché y enrute etiquetas desconocidas a un topic de cuarentena.
Aplique en Odoo mediante un único escritor con clave de idempotencia, nunca desde varias instancias del puente a la vez.
Confirme el mensaje MQTT solo después de que la escritura de negocio haga commit, o perderá eventos en el peor momento.
Publique el evento resuelto de vuelta en la rama de negocio para que otros consumidores no repitan ese trabajo.

Contrapresión, replay y el mensaje venenoso

Todo pipeline de eventos acaba encontrando un mensaje que no puede procesar, y la pregunta de diseño es qué pasa entonces.

Limite los mensajes en vuelo; un consumidor sin límite es solo una forma más lenta de quedarse sin memoria.
Cuando la cola supere un límite, descarte con contador en lugar de bloquear al lector, y alerte con fuerza.
Envíe los mensajes no procesables a un topic de mensajes muertos con el motivo adjunto, y nunca deje que uno detenga la cola.
Guarde la secuencia monotónica para que un replay empiece en un punto conocido en lugar de adivinar.
Pruebe el replay deliberadamente; un replay no probado es una creencia, no una capacidad.

Seguridad: TLS, credenciales y ACL de topics

Un broker MQTT en una red de almacén sin control de acceso es una interfaz para manipular el inventario.

Use TLS en el puerto seguro estándar y desactive por completo el listener en claro.
Dé a cada lector su propia credencial o certificado de cliente, para poder revocar un dispositivo comprometido por separado.
Restrinja derechos de publicación y suscripción por rama, para que un lector no publique en la rama de otro sitio.
Desactive el acceso anónimo y la cuenta administrativa por defecto; ambas siguen siendo los hallazgos más comunes en auditorías.
Registre los fallos de conexión y autorización, porque son la primera señal de un dispositivo mal configurado o hostil.

Operación: ahora eres dueño de un broker

Añadir un broker significa añadir un sistema que debe monitorizarse como cualquier otro.

Siga los clientes conectados, el ritmo de mensajes, los mensajes descartados y la profundidad de las sesiones persistentes.
Alerte sobre el retraso del puente, la edad del mensaje sin procesar más antiguo y el crecimiento de la cola de muertos.
Dimensione para la hora punta, no para la media diaria, y pruebe un reinicio del broker en un turno cargado.
Respalde el estado retenido y las tablas de mapeo del puente; son configuración, no caché.
Documente el árbol de topics y el esquema de payload en el repositorio, porque la siguiente integración la escribirá otra persona.