LLRP tiene fama de difícil, y la fama está medio justificada: la codificación es binaria, el catálogo de mensajes es largo y la documentación parece escrita por un comité de estándares, porque lo fue. Pero el subconjunto que necesita un despliegue real es pequeño, y una vez entendido, el protocolo se convierte en la parte menos interesante del proyecto.

Este es el mapa de ese subconjunto: qué configurar, en qué orden y qué campos cambian de verdad lo que hace el lector.

Qué es LLRP y en qué capa está

LLRP es un protocolo host-lector, no un protocolo de aplicación, y mantener esa distinción ahorra mucha confusión de diseño.

Lo define EPCglobal y está estandarizado como LLRP 1.0.1, con 1.1 añadiendo control más fino y mejor soporte de extensiones.
Corre sobre TCP en el puerto 5084 por defecto y codifica mensajes como estructuras binarias tipo-longitud-valor.
Su trabajo es configurar la radio y entregar reportes de etiquetas, no decidir qué significa una lectura.
Casi cualquier lector fijo empresarial lo soporta, y por eso el código LLRP puede ser portable entre marcas.
Por encima de LLRP sigues necesitando tu propia pasarela: deduplicación, mapeo de negocio y escrituras al ERP quedan fuera del protocolo.

El modelo de mensajes: peticiones, respuestas y reportes

Tres familias de mensajes cubren todo, y saber cuál es cuál evita la mayor parte de la confusión.

Las peticiones llevan un identificador y esperan exactamente una respuesta con el mismo identificador.
Las respuestas llevan un código de estado; un éxito con carga inesperada es más común que un fallo rotundo.
Los reportes llegan de forma asíncrona una vez que un ROSpec está corriendo, y no son respuesta a nada.
Los eventos del lector y las notificaciones de error también pueden llegar asíncronamente, así que el cliente debe estar leyendo siempre.
Un cliente que solo lee después de enviar una petición acabará llenando el búfer del socket y bloqueándose.

Configuración del lector: los cinco mensajes que siempre envías

La configuración es una máquina de estados, y el orden importa más que los campos individuales.

Lee capacidades primero; te dice qué opciones soporta el lector y evita enviar ajustes no soportados.
Configura el lector después: keepalive, búfer de reportes y propiedades de antena por defecto.
Añade el ROSpec, habilítalo y arráncalo; un ROSpec habilitado pero no arrancado no hace nada y parece un fallo.
Añade el AccessSpec aparte, y solo cuando una escritura o un bloqueo sea realmente necesario.
Borra y vuelve a añadir un ROSpec en lugar de editarlo in situ; las ediciones in situ son donde aparecen las diferencias entre fabricantes.

ROSpec: describir una operación de inventario

Un ROSpec es un contenedor de una especificación de reporte y una o más especificaciones de parámetros de inventario.

La especificación de reporte selecciona qué campos de etiqueta vuelven y con qué frecuencia se emiten reportes.
La especificación de parámetros de inventario nombra las antenas y el comportamiento del protocolo aéreo en una sola unidad.
Todo ROSpec en ejecución compite por la misma radio, así que dos ROSpecs en un lector suelen significar que uno está mal.
Los disparadores de observación deciden cuándo se reporta una etiqueta: de inmediato, tras N lecturas o cuando deja de verse.
Mantén un ROSpec por comportamiento de negocio, nómbralo en el campo de descripción y trata ese nombre como parte de tu contrato de configuración.

Ajustes de protocolo aéreo: los campos que cambian el comportamiento

El comando de inventario C1G2 es donde realmente se decide el comportamiento del lector.

La potencia de transmisión y el canal o tabla de saltos van primero; la potencia está limitada por regulación, no es una perilla de ajuste.
El ajuste de sensibilidad del receptor intercambia una ventana de escucha más amplia por ruido, y los valores por defecto rara vez son óptimos en un pasillo denso.
La elección de sesión de singulación determina si las etiquetas se reportan rápido o se mantienen calladas; la sesión dos conviene a mercancía en movimiento.
La estimación de población de etiquetas ayuda al lector a elegir valores Q; una estimación equivocada cuesta tiempo, no corrección.
Los filtros de etiqueta reducen la población antes de la singulación y son la mejora de rendimiento más barata disponible.

AccessSpec: leer y escribir memoria de etiqueta

Las operaciones de acceso se usan con cuentagotas, y cada uso tiene un perfil de fallo concreto.

Un AccessSpec apunta a un filtro, así que nunca debe ejecutarse sin uno salvo que quieras escribir en todas las etiquetas del alcance.
Leer un banco de memoria es el diagnóstico seguro; escribir el EPC o la memoria de usuario es la operación que daña datos.
Las escrituras deben verificarse con una lectura posterior, en la misma sesión, y no asumirse por un estado de éxito.
Las contraseñas de acceso deben tratarse como secretos; un bloqueo sin contraseña registrada es un error irreversible.
Una operación de acceso fallida devuelve un código de estado, y el código suele ser más útil que un reintento.

Gestión de errores: códigos de estado que merecen ramificación

Casi todos los clientes LLRP tratan cualquier no-éxito como un fallo genérico, lo que hace imposible el diagnóstico de campo.

Distingue errores de parámetro de errores de estado: los primeros significan que el mensaje estaba mal, los segundos que el lector estaba en el estado equivocado.
Un desajuste de capacidades debe gestionarse volviendo a una opción soportada, no abortando el despliegue.
Los timeouts repetidos suelen significar una sesión TCP caída más que un lector lento, así que revise el socket antes de reintentar.
Registre el identificador de mensaje junto al código de estado; sin él, una secuencia de varios mensajes no se puede depurar.
Trate también un éxito inesperado como un error: una respuesta correcta con carga vacía a menudo significa que el lector ignoró la petición.

Mantener el código LLRP portable entre fabricantes

La portabilidad es una decisión de diseño tomada al principio y muy cara de retrofit.

Use solo mensajes y parámetros estándar allí donde el estándar cubra su necesidad.
Detecte características mediante el mensaje de capacidades en lugar de asumir que un fabricante soporta una opción.
Aísle las extensiones del fabricante tras un adaptador delgado, para que el resto de la pasarela nunca las importe.
Pruebe la misma configuración en una segunda marca antes de fijar el diseño; las diferencias aparecen pronto y baratas.
Versione sus archivos de configuración, porque un ROSpec que funciona es un activo que debe sobrevivir al reemplazo de un lector.