Key Takeaways
- Por qué conectar lectores directamente a Odoo es un anti-patrón
- Arquitectura del gateway: pipeline de tres capas
- Hooks de escritura stock.quant y manejo de conflictos
01Por qué conectar lectores directamente a Odoo es un anti-patrón
Los lectores pueden emitir cientos a miles de eventos TagRead por segundo, llenos de duplicados (la misma etiqueta leída 5-20 veces en 1 segundo). Escribirlos directamente a Odoo satura los locks de la base de datos — las escrituras concurrentes a stock.quant causan colas de bloqueos de PostgreSQL que congelan todo el módulo de inventario. Un lector de 4 antenas sobre una cinta genera más de 2000 eventos por segundo, de los cuales el 95% son lecturas duplicadas. El enfoque correcto es un middleware gateway entre el lector y Odoo que maneje deduplicación, agregación y buffering antes de escribir en lote.
- Cinta 4 antenas: 2000+ eventos/seg, 95% duplicados
- Escritura directa: cola de locks PostgreSQL → congelación de inventario
- Middleware gateway: dedup → agregar → buffer → escritura en lote
02Arquitectura del gateway: pipeline de tres capas
El gateway SpidersRFID usa un pipeline de tres capas. La capa 1 es el receptor de eventos LLRP, suscribiéndose a eventos TagReadData vía conexión TCP larga con heartbeat de 100ms. La capa 2 es el motor de deduplicación, con algoritmo de ventana deslizante (2 segundos por defecto) y clave compuesta EPC+antena, comprimiendo 2000 eventos/seg a 50-80 eventos/seg. La capa 3 es el escritor de Odoo, llamando al método write de stock.quant vía XML-RPC/JSON-RPC con envío por lotes (cada 500ms, máx 100 por lote) y control de concurrencia optimista (OCC). Las tres capas se desacoplan vía colas Redis.
El análisis EPC es el paso crítico tras la deduplicación. La codificación EPC Gen2 de 96 bits contiene cuatro segmentos: Header, Domain Manager, Object Class y Serial Number. El gateway analiza el EPC y lo mapea al campo product.product.external_id de Odoo, buscando el registro correspondiente vía ir.model.data. Para EPCs no mapeados, el gateway escribe en una cola de coincidencia pendiente para enlace manual. En la práctica, el 5-10% de los EPCs no están mapeados en el primer despliegue, requiriendo 1-2 días de calibración.
03Hooks de escritura stock.quant y manejo de conflictos
La tabla stock.quant de Odoo es el núcleo del inventario — cada fila representa cantidad de ubicación+producto+lote. El gateway intercepta las escrituras vía un hook personalizado con tres protecciones: (1) bloqueo a nivel de campo — usando SELECT FOR UPDATE para evitar sobreescrituras concurrentes; (2) escritura incremental — en lugar de establecer quantity directamente, crea registros stock.move dejando que la lógica estándar de Odoo maneje los cambios; (3) reintentos de conflicto — cuando OCC detecta conflicto de versión, relee y reintenta hasta 3 veces. En la práctica, a 100K escrituras/día la tasa de conflicto es solo 0,3%.
- SELECT FOR UPDATE → evita sobreescritura concurrente
- Escritura incremental stock.move → asientos correctos
- Reintento OCC 3× → 0,3% conflictos resueltos
