Un Zebra FX9600 es un lector industrial sólido: cuatro puertos de antena, carcasa con protección IP y una interfaz LLRP documentada. Nada de eso lo hace fácil de conectar a Odoo. El trabajo de integración no está en leer etiquetas; está en la disciplina de configuración, el tiempo y la frontera entre lo que decide el lector y lo que se le cuenta al ERP.

El patrón que sobrevive es poco glamoroso: estandarizar en LLRP, usar el SDK del fabricante solo donde se gana su lugar y mantener toda la lógica de negocio fuera del lector.

Por qué LLRP es la capa correcta para estandarizar

LLRP es verboso, y precisamente por eso vale la pena usarlo en las partes que no deben cambiar.

LLRP es un estándar abierto, así que el modelo de configuración y reporte sobrevive a un cambio de fabricante.
Expone los conceptos que importan operativamente: perfil de radio, configuración de antenas, rondas de inventario y operaciones de acceso.
Un ROSpec describe qué leer y adónde enviarlo; un AccessSpec describe una escritura o un bloqueo sobre una etiqueta concreta.
Los reportes llegan como mensajes estructurados, lo que significa que la pasarela parsea campos en lugar de eventos propietarios.
El coste es verbosidad y una curva de aprendizaje empinada, pagada una vez y no en cada cambio de firmware.

Configuración del lector: fíjala una vez, versiónala, deja de tocarla

La mayoría de los incidentes de campo son deriva de configuración, no fallo de hardware.

Fije explícitamente la región regulatoria y la potencia de transmisión; nunca confíe en el valor por defecto, que puede ser ilegal localmente.
Elija el modo de RF a conciencia: modo dense-reader para muchas etiquetas en poco espacio, un modo de mayor caudal para una cinta.
Seleccione la estrategia de sesión según el patrón de tráfico; la sesión dos es la habitual donde las etiquetas se mueven y deben releerse rápido.
Fije un intervalo de reporte que coincida con la cadencia del negocio; un reporte cada doscientos milisegundos es un torrente para un sistema de inventario.
Guarde la configuración completa en el repositorio y aplíquela desde un script, para que un lector de reemplazo arranque idéntico.

El SDK de Python: qué gana y qué no

El SDK del fabricante es realmente útil para un conjunto pequeño de tareas y un pasivo para todo lo demás.

Útil: descubrimiento, consultas de firmware, métricas de salud y alguna lectura de diagnóstico de bajo nivel.
Útil: aplicar un archivo de configuración LLRP a un dispositivo sin escribir XML a mano.
No útil: lógica de negocio, deduplicación o cualquier decisión que deba ser auditable; eso pertenece a tu pasarela.
No útil como ruta principal de eventos si quieres independencia del fabricante, porque su modelo de eventos es propietario.
Fija la versión del SDK como cualquier dependencia; una actualización puede cambiar el comportamiento por defecto en silencio.

Filtrar eventos antes de que Odoo vea nada

El lector es un buen lugar para descartar datos, y el ERP es el peor lugar para descubrir que no lo hiciste.

Aplique un umbral de RSSI en el lector para eliminar lecturas marginales y registre el umbral en el historial de configuración.
Filtre por prefijo de EPC cuando solo el stock de un cliente cruza un portal, lo que elimina la mayor parte del ruido gratis.
Enmascare explícitamente los puertos de antena no usados; un puerto abierto sin antena no produce más que diagnósticos confusos.
Deduplique por EPC dentro de una ventana en la pasarela, no en el lector, para que la ventana sea visible y ajustable.
Reporte el recuento de rechazados por antena, porque un aumento súbito es la primera señal de una instalación desintonizada.

Diseño de antenas y ciclo de lectura

Los ajustes del ciclo deciden si el portal ve un palé rápido o solo uno detenido.

Una antena por cara del portal es el patrón fiable; dos antenas en la misma cara exigen separación cuidadosa de fase y tiempo.
Las rondas de inventario por reporte deben coincidir con el tiempo de tránsito; un palé que cruza en tres segundos necesita rondas suficientes dentro de esos tres segundos.
El tiempo de permanencia de antena intercambia sensibilidad por velocidad; más permanencia va mejor en cinta lenta y peor en rápida.
Pruebe con el palé cargado como lo carga realmente la operación, no con un palé de demostración limpio.
Registre potencia, modo y permanencia finales por portal en un plano que el siguiente técnico pueda leer.

Manejo de fallos: sesiones, reconexiones y lecturas duplicadas

Una sesión TCP caída es operación normal, y el diseño tiene que tratarla así.

Espere que las sesiones LLRP caigan por eventos de red; implemente reconexión con backoff y un número acotado de reintentos.
Al reconectar, no reproduzca lecturas antiguas como eventos nuevos; use la hora de evento del lector para descartar lo obsoleto.
Mantenga un spool local para que una caída retrase los datos en lugar de perderlos, y deje que la pasarela lo vacíe tras la recuperación.
Vigile las lecturas duplicadas entre dos lectores que cubren la misma zona; la deduplicación de la pasarela debe ser global, no por lector.
Alerte sobre reconexiones repetidas como problema de red, porque un enlace que oscila suele ser cableado o PoE, no firmware.

Despliegue: red, firmware y tiempo

Tres decisiones de infraestructura causan más incidentes que el propio diseño RFID.

Ponga los lectores en una VLAN dedicada con direccionamiento predecible y documente el presupuesto PoE por puerto de switch.
Fije el firmware por sitio y pruebe las actualizaciones primero en un portal de laboratorio, porque el comportamiento de RF puede cambiar entre versiones.
Sincronice los relojes de los lectores con NTP; un lector desincronizado produce eventos que parecen fuera de orden al conciliar.
Reserve direcciones fijas o reservas DHCP, para que una unidad de reemplazo no adquiera una identidad nueva en la pasarela.
Tenga un lector de repuesto preconfigurado, porque el fallo que duele es el del muelle más ocupado.

Una secuencia de integración que funciona

La secuencia es deliberadamente lenta al principio, porque la alternativa es lenta al final.

Paso uno: un lector en banco, LLRP configurado, una etiqueta leída y registrada por la pasarela, sin escritura en Odoo.
Paso dos: el mismo lector en un portal en modo sombra durante una semana, comparando sus lecturas con el proceso manual.
Paso tres: habilitar escrituras solo para ese portal, con el proceso antiguo aún disponible como respaldo.
Paso cuatro: ampliar portal a portal, vigilando lecturas rechazadas y huecos de conciliación en lugar de contar etiquetas.
Paso cinco: entregar con un repositorio de configuración, un runbook para reemplazar un lector y un informe de conciliación.