El Impinj R700 es fácil de comprar y sorprendentemente difícil de integrar bien, porque no es un lector en el sentido tradicional. Corre Linux, aloja aplicaciones y puede decidir por su cuenta. Quien lo trata como un dispositivo serie acaba con una cadena frágil; quien lo trata como un pequeño servidor acaba con una limpia.

Qué es realmente el R700

Entender el dispositivo decide la arquitectura.

Es una plataforma de cómputo edge con radio RFID, no un periférico USB con un juego de comandos.
Ejecuta aplicaciones en contenedor, así que la lógica puede vivir en el lector y no en un servidor.
Expone LLRP, una API REST y una interfaz de gestión, cada una con su papel.
Puede almacenar eventos localmente, lo que importa cuando la red cae en pleno turno.
Se gestiona como flota, con perfiles empujados centralmente en lugar de configurar a mano.

Tres capas, tres propietarios

El patrón limpio es aburrido, y lo aburrido es lo que sobrevive.

El lector es dueño de la radio: potencia, sesión, filtros, planificación de antenas y conectividad.
El middleware es dueño de la semántica: deduplicación, mapeo de zonas, eventos de negocio y buffer.
Odoo es dueño del inventario: movimientos, lotes, ubicaciones y su consecuencia contable.
Nunca dejes que los workers web de Odoo hablen LLRP; una conexión de protocolo no va en un hilo de petición.
Nunca dejes que el lector escriba movimientos de stock; un dispositivo que puede contabilizar es un incidente de seguridad esperando.

Dos caminos de integración

Hay un camino de plataforma y uno directo, y resuelven problemas distintos.

ItemSense o una plataforma equivalente agrega muchos lectores en una API, con la lógica de zonas ya resuelta.
El camino directo habla con la interfaz REST de cada lector y construye tú el modelo de eventos.
El camino de plataforma es más rápido en sitios multi-lector y más lento de adaptar a lógica rara.
El camino directo es más ligero para pocos lectores y da control total del modelo de datos.
Elijas el que elijas, mantén idéntico el conector de Odoo en ambos lados, para que cambiar no sea reescribir.

El contrato de eventos hacia Odoo

Define la carga una vez y versiona.

Campos: id de dispositivo, sitio, zona, antena, EPC, primera y última vez visto, número de lecturas, RSSI y secuencia.
Envía observaciones, no conclusiones; que el middleware decida si una observación es un movimiento.
Agrupa por zona y ventana corta para reducir charla, pero mantén la ventana bajo un segundo en portales.
Haz el endpoint idempotente en dispositivo, EPC y ventana, para que un reintento no duplique un movimiento.
Devuelve respuesta clara: aceptado, duplicado o rechazado con motivo, para que el lector pueda actuar.

Lectura, gateways y realidad de red

El lector vale lo que vale su red, y un almacén no es un centro de datos.

Usa Ethernet cableado donde puedas; el Wi-Fi en un muelle es una moneda al aire en hora punta.
Dimensiona el buffer local para el corte más largo esperado y prueba que reproduce correctamente.
Monitoriza latido y deriva de configuración por dispositivo, porque un lector offline en silencio parece ausencia de movimientos.
Sincroniza los lectores a una fuente común, o el orden de eventos será conjetura.
Despliega configuración por el plano de gestión, no entrando en cada dispositivo.

Seguridad y ciclo de vida

Un dispositivo edge que corre contenedores es un ordenador pequeño en tu red y debe tratarse como tal.

Cambia credenciales por defecto antes de la puesta en marcha y usa certificados por dispositivo, no contraseña compartida.
Restringe el tráfico saliente al endpoint del middleware y al plano de gestión.
Registra versiones de firmware en el inventario de activos, porque una flota mixta se comporta de forma inconsistente.
Rota credenciales al reemplazar dispositivos y elimina el antiguo del middleware.
Registra cada cambio de configuración con quién y cuándo, porque ayer funcionaba no es un diagnóstico.

Probar antes del primer palé real

Un lector que pasa una prueba de banco no ha demostrado nada del pasillo.

Prueba con palés llenos a la distancia real y con el stock que estará allí de verdad.
Verifica el límite de zona: camina una caja etiquetada hacia la zona vecina y observa dónde aparecen lecturas.
Corta la red a mitad de turno y confirma que el buffer reproduce sin duplicados.
Reinicia el lector y confirma que la aplicación vuelve con la configuración correcta.
Ejecuta un día completo de tráfico real y compara eventos con conteos físicos antes de salir a producción.

Cómo se ve el éxito tras un año

El éxito se mide en métricas aburridas, no en la demo de lanzamiento.

Pérdida de eventos por debajo de una fracción de punto, y cada pérdida explicable.
Sin reconciliación manual en operación normal, solo para excepciones reales.
Cambios de configuración desplegables a toda la flota en una acción.
Un lector nuevo instalable en menos de una hora, porque el patrón es repetible.
Odoo sigue respondiendo en pico de lecturas, porque el lector nunca lo toca directamente.

Si la arquitectura respeta las tres capas, un despliegue de R700 se convierte en infraestructura ordinaria: funciona, informa y nadie habla de él. Ese es el mayor elogio que puede ganar una integración.

Lectores multi-sitio y multi-cliente

Una flota que creció sede a sede casi siempre lleva un error de multi-tenencia en algún sitio.

Da a cada lector una identidad con ámbito de sitio y nunca permitas que la carga lleve solo un nombre de dispositivo.
Particiona temas y esquemas de base de datos por sitio, para que un lector mal configurado no escriba en datos de otro cliente.
Mantén una plantilla de configuración por perfil de sitio y trata una sede nueva como despliegue, no como instalación manual.
Centraliza versiones de firmware y aplicación, porque las versiones mixtas vuelven ambiguo cada informe de fallo.
Escribe la regla de tenencia; es invisible hasta el día en que se incumple.

Fallos frecuentes y sus síntomas

Casi todos los problemas de integración se anuncian con una firma reconocible.

Movimientos duplicados: el endpoint no es idempotente o la ventana de deduplicación es menor que el intervalo de reintento.
Eventos perdidos tras un corte: el buffer es pequeño o el lector se configuró con sesión limpia.
Odoo lento en hora punta: alguien puso una llamada síncrona al lector dentro de una petición web.
Lecturas que se cuelan en el pasillo vecino: potencia y orientación se ajustaron en banco de pruebas.
Un lector que «funciona» pero nunca aparece en informes: se monitoriza el latido, no el flujo de eventos.

Cada uno es barato de arreglar una vez nombrado y caro de diagnosticar con la planta en marcha. Nómbralos en el runbook antes de salir a producción, y el primer mes de operación será rutina en lugar de discusión.