LLRP —el Low Level Reader Protocol— existe porque cada lector UHF fijo hablaba antes un idioma distinto. Antes de él, integrar tres fabricantes significaba tres SDK, tres semánticas de conexión y tres formas de expresar "leer estas cuatro antenas con este filtro". LLRP lo sustituye por un único protocolo binario sobre TCP.

¿Qué estandariza realmente LLRP?

LLRP define los mensajes que un cliente envía a un lector y los informes que el lector devuelve: descubrimiento de capacidades, configuración del lector, especificaciones de inventario y acceso, comandos de acceso a etiquetas y notificaciones de eventos. La versión 1.0.1, ratificada en 2007, sigue siendo la más desplegada; la versión 2.0 añade los comandos de Gen2 v2.

No estandariza su lógica de negocio, su modelo de datos ni el nombre de sus antenas. Eso sigue siendo suyo, y confundir el protocolo con la integración es donde se desvían la mayoría de los proyectos.

Descubrimiento de capacidades: número de antenas, rango de potencia, protocolos aéreos soportados.
Configuración: modo de RF, potencia de transmisión, pesos de antena, comportamiento de GPI y GPO.
Inventario: ROSpec y AISpec definen qué antenas emiten y qué se informa.
Acceso: operaciones de lectura, escritura, bloqueo y kill sobre un conjunto de etiquetas seleccionado.

¿Qué ajustes deben vivir en el middleware y no en el firmware?

Todo lo que difiere entre dos sitios debe vivir en el middleware, versionado en el mismo repositorio que el resto de la integración. Los valores por defecto del lector son invisibles, no están versionados y no se pueden auditar cuando el ingeniero que los configuró ya no está.

Sesión de inventario, target y estimación de población de etiquetas.
Potencia de transmisión por antena y el mapa antena-zona.
Filtros (prefijo EPC, máscara TID) que determinan qué puede informar el lector.
Modo de lector: máximo rendimiento, dense reader o híbrido.
Disparadores GPI y ventanas de antirrebote para sensores de cinta o de puerta.

¿Cómo modelar ROSpec, AISpec y AccessSpec?

Un ROSpec es el contenedor: agrupa antenas, una especificación de inventario, una especificación de acceso opcional y una especificación de informes, y pasa por los estados deshabilitado, inactivo y activo. La AISpec indica qué antenas ejecutan qué parámetros de inventario; la AccessSpec indica qué leer o escribir en las etiquetas que cumplen un filtro.

Mantenga un ROSpec por zona física, no uno por antena. Así una puerta de muelle se convierte en un único objeto que se puede arrancar, parar y monitorizar, y el mapa de antenas sigue siendo un detalle de configuración en lugar de un cambio de código.

Un ROSpec por zona: puerta de muelle, línea de producción, almacén.
Intervalo de informe de 200 a 1.000 ms para portales; informe inmediato solo con poco volumen.
AccessSpec solo para escrituras; las zonas de solo lectura sin comandos de acceso.

¿Dónde fallan habitualmente los despliegues LLRP?

El protocolo rara vez es el problema. Los fallos son operativos.

Gestión de conexiones: los lectores se reinician, pierden TCP y reconectan en oleadas; un cliente sin retroceso expone el lector y la red al mismo tiempo.
Lecturas duplicadas: la misma etiqueta vista doce veces en dos segundos es un evento, no doce movimientos de stock.
Desbordamiento de búfer: una ráfaga de 800 etiquetas en un portal desborda a un cliente que procesa de forma sincrónica.
Variación de firmware: los campos y capacidades opcionales difieren entre modelos y versiones, así que el resultado del descubrimiento debe tratarse como dato y no como suposición.
Sin separación de responsabilidades: las reglas de negocio enterradas en la configuración del lector no se pueden probar.

¿Cómo deben llegar los eventos a Odoo?

El camino limpio es: evento del lector, normalización, deduplicación, evento de negocio, llamada al ERP. Cada paso tiene una única responsabilidad y se puede registrar por separado.

Evento del lector: EPC, antena, marca temporal, número de lecturas, RSSI.
Normalización: EPC a producto, antena a ubicación, lector a tipo de operación.
Deduplicación: ventana de antirrebote de 3 a 10 segundos por EPC y zona.
Evento de negocio: recepción, transferencia, recuento o ajuste, uno por movimiento físico.
Llamada a Odoo: actualización de stock.quant, creación de stock.move o ajuste de inventario, con una clave de idempotencia construida con EPC, zona y ventana.

¿Cómo se plantean la monitorización y el failover?

Trate los lectores como equipos de red. Consulte el latido y el estado GPI cada 30 segundos, alerte ante una caída del ritmo de lectura en lugar de ante errores individuales, y guarde eventos en local cuando el ERP o la red no estén disponibles.

El almacenamiento y reenvío no es opcional en un almacén donde una lectura perdida en la puerta de muelle se convierte en una diferencia de stock tres semanas después. Dimensione el búfer para al menos cuatro horas con el ritmo de lectura en pico y reproduzca con las marcas temporales originales para que el ERP vea la secuencia correcta.

Conclusión

LLRP le da un protocolo para lectores de varios fabricantes, y nada más. Ponga la configuración, el filtrado y el almacenamiento en el middleware, modele un ROSpec por zona, deduplique antes de tocar el ERP y monitorice los lectores como los equipos de red que son.