El defecto fatal del polling HTTP Los gateways RFID tradicionales reportan eventos a Odoo vía polling HTTP, con tres problemas: primero, el polling de alta frecuencia satura el pool de workers de Odoo; segundo, el jitter de red causa pérdida de eventos; tercero, no hay comunicación bidireccional (Odoo no puede enviar al gateway). El modelo pub-sub de MQTT resuelve los tres.
Diseño de tema MQTT y formato de mensaje Usamos un diseño jerárquico: rfid/{siteId}/{readerId}/event para reporte de eventos, rfid/{siteId}/command para que Odoo envíe comandos. El formato es JSON: {epc, timestamp, rssi, readerId, antennaId, eventType}. El diseño clave es el campo eventType que distingue inventory, entry, exit y alarm — permitiendo a los suscriptores consumir según necesidad.
Selección de nivel QoS QoS 0 (como máximo una vez): para eventos de inventario de alta frecuencia en tiempo real, tolerando pérdida menor. QoS 1 (al menos una vez): para eventos de entrada/salida, asegurando no pérdida pero posibles duplicados — los suscriptores necesitan idempotencia. QoS 2 (exactamente una vez): para alarmas de prevención de pérdidas, sin pérdida ni duplicados, pero mayor overhead. Nuestra práctica: inventario QoS 0, entrada/salida QoS 1, prevención QoS 2.
Suscriptor MQTT en el lado de Odoo Un proceso suscriptor Python independiente (paho-mqtt) corre en el servidor Odoo, se suscribe a rfid/+/+/event, y escribe a Odoo vía XML-RPC o el módulo connector de OCA al recibir mensajes. Una cola Redis bufferiza entre suscriptor y Odoo para prevenir pérdida durante reinicios. Un solo suscriptor maneja 5.000 eventos/seg — suficiente para la mayoría de escenarios de almacén.
