Casi todo proyecto RFID empieza con un lector escribiendo en una base de datos y termina con cuarenta lectores escribiendo en la misma base de datos más rápido. Lo interesante está en el tramo entre ambos estados, y casi nunca tiene que ver con el broker elegido.

Por qué MQTT encaja con los flujos RFID

Un parque RFID genera un flujo de mensajes pequeños, con picos, unidireccional y de alto volumen, y esa forma tiene consecuencias.

Los eventos son diminutos y frecuentes; una llamada REST por etiqueta desperdicia tres órdenes de magnitud.
Los lectores viven en redes industriales poco fiables, así que el transporte debe tolerar reconexiones sin perder estado.
El publicador no sabe nada del consumidor, y debe seguir así; los lectores no llevan lógica de ERP.
Los tópicos ofrecen una partición natural por planta, zona y dispositivo, que es también cómo se escala el consumo.
MQTT mantiene sesión persistente, de modo que un suscriptor que reconecta recupera lo que se perdió.

Ese último punto es el que casi todos usan y el que casi todos configuran mal.

La integración es el contrato, no el broker

Los brokers son mercancía. El esquema de eventos es el activo, y merece la misma disciplina que una tabla.

Versiona el payload desde el primer día dentro del mensaje, no en el nombre del tópico.
Fija los campos de identidad: id de dispositivo, código de planta, antena, hora de lectura en UTC, EPC, RSSI y un número de secuencia.
Define qué significa una lectura: un evento de antena o una ventana de observación deduplicada.
Decide dónde se ata el significado de negocio: el lector reporta hechos, el suscriptor los interpreta.
Escribe el esquema y genera desde él los tipos del publicador y del suscriptor.

Si dos plantas pueden producir nombres distintos para el mismo hecho, no tienes una integración: tienes dos que comparten broker por casualidad.

El suscriptor vive fuera de los workers de petición

El fallo de producción más común es arquitectónico, no técnico: el suscriptor está atornillado al mismo proceso que sirve peticiones web.

Los workers web de Odoo son de vida corta y se reciclan; una suscripción larga no pertenece allí.
Ejecuta un servicio aparte, con su propia supervisión, presupuesto de memoria y política de reinicio.
Dale una conexión de base de datos separada del pool de usuarios, con sus propios timeouts de sentencia.
Nunca dejes que un manejador mantenga la transacción abierta esperando el siguiente mensaje.
Despliégalo con el mismo pipeline que la aplicación, pero con cadencia propia cuando haga falta.

Un suscriptor que muere cuando alguien sube un archivo grande no es un suscriptor: es un rehén.

QoS, duplicados y la trampa del mensaje retenido

Los niveles de servicio se eligen por costumbre, y eso produce a la vez eventos perdidos y movimientos duplicados.

QoS 0 pierde mensajes al reconectar; aceptable para telemetría, no para movimientos de stock.
QoS 1 garantiza llegada y permite duplicados de forma explícita; tu manejador debe ser idempotente.
QoS 2 elimina duplicados en el protocolo pero cuesta idas y vueltas y rara vez compensa aquí.
Los mensajes retenidos son para el último estado conocido, no para historia; nunca retengas un movimiento.
Las sesiones limpias descartan la cola al reconectar; si necesitas recuperación, usa sesión persistente y un client id fijo.

Elige QoS 1 con manejador idempotente y gasta el esfuerzo en el manejador.

Idempotencia, orden y disciplina de reloj

Dos eventos del mismo palé pueden llegar desordenados, dos veces, o ambas cosas.

Construye la clave de idempotencia con dispositivo, EPC, antena y marca de tiempo, y refuérzala con un índice único.
No confíes en el reloj del dispositivo; guarda la hora de recepción además de la reportada.
Resuelve el desorden comparando marcas de tiempo del evento, no el orden de llegada.
Para ajustes, escribe un log de eventos de solo añadir y deriva el saldo, en lugar de mutar una cantidad.
Haz las repeticiones seguras por diseño, para que alguien pueda reprocesar el lote de anoche sin miedo.

El inventario que solo se corrige a mano es el inventario que se corrige a mano cada semana.

Contrapresión, lotes y cola de mensajes muertos

Un suscriptor que aguanta un martes tranquilo se quedará atrás en un inventario físico completo.

Agrupa escrituras en lotes pequeños con intervalo de descarga acotado: sube el rendimiento sin alargar la latencia.
Aplica contrapresión a propósito: frena el grupo de consumidores, nunca descartes en silencio.
Deriva los mensajes venenosos a un tópico de mensajes muertos con el payload original y el motivo.
Alerta sobre el crecimiento de esa cola, porque una cola silenciosa es donde se esconde la pérdida de datos.
Limita los reintentos con retroceso exponencial y luego aparca el mensaje para revisión humana.

La cola de muertos no es admitir un fracaso; es la diferencia entre una mala tarde y un libro mayor corrupto.

Seguridad y aislamiento multi-planta

Un broker abierto dentro de la red de una fábrica es una herramienta de manipulación de inventario para quien lo encuentre.

Termina TLS en el broker y autentica cada dispositivo con credenciales propias, no una contraseña compartida.
Autoriza por tópico, para que un lector del almacén A no publique en el espacio de nombres del B.
Mantén los payloads sin datos personales cuando sea posible; si una etiqueta mapea a una persona, cifra o tokeniza ese mapeo.
Rota credenciales por calendario y al retirar dispositivos, y registra cada rotación.
Separa en la base de datos los permisos de lectura del suscriptor de los de escritura.

Observabilidad: demostrar que el flujo está vivo

A las tres de la mañana la pregunta nunca es si el broker está arriba, sino si la última hora de lecturas llegó a Odoo.

Mide la edad del mensaje de extremo a extremo: hora de publicación menos hora de confirmación, con umbral de alerta.
Emite un latido por dispositivo y alerta cuando uno calla en horario operativo.
Cuenta recibidos, procesados, deduplicados y rechazados, y expón los cuatro números juntos.
Mantén una reconciliación que compare eventos con movimientos de stock resultantes en la última hora.
Registra un id de correlación desde el lector hasta el registro de Odoo, para rastrear una lectura disputada en minutos.

Nada de esto es exótico. Es la disciplina ordinaria de tratar un pipeline de eventos como un sistema financiero, porque eso es lo que se vuelve en el momento en que el stock depende de él.