"Instalar un módulo RFID en Odoo" esconde detrás una frase tres decisiones de ingeniería completamente distintas. La tienda de apps contiene módulos llamados RFID; Enterprise incluye una IoT Box; y la mayoría de los sistemas RFID en producción acaban usando una tercera cosa — middleware fuera de Odoo que escribe en él vía XML-RPC o JSON-RPC. Ninguna ruta es universalmente mejor, pero cada una tiene límites claros. Este artículo las pone las tres lado a lado.
Ruta 1: módulos de la tienda de apps de Odoo
Los módulos relacionados con RFID en la tienda caen aproximadamente en dos familias:
- Módulos de mapeo de etiquetas: representados por "RFID/NFC Tags for Stock Barcode" (app_rfid_stock_barcode), que mapea cada serie de etiqueta a un código de barras real, de modo que el personal escanea etiquetas RFID dentro del flujo de código de barras existente — el operario de inventario no aprende ninguna interfaz nueva.
- Módulos puente de hardware: como yudha_rfid_base, que aporta la capa base para hablar con el hardware lector, dejando los flujos superiores al desarrollador.
Las ventajas son el coste, la instalación rápida y la disponibilidad inmediata. Las debilidades son igual de explícitas: alcance limitado al flujo de un solo módulo (mayormente el app de códigos de barras de stock), fijación estricta de versión (construidos para una edición concreta, con las actualizaciones pendientes del autor), y lectores fijos, robots y automatización entre módulos fuera de alcance en gran medida.
Ruta 2: la IoT Box de Enterprise
La IoT Box es el contenedor oficial de dispositivos de Odoo: una placa basada en Raspberry Pi que, al añadirse al menú IoT, descubre automáticamente los periféricos soportados. Su ventaja es ser oficial — drivers y versiones de Odoo los mantiene el mismo equipo y la configuración es fluida.
Sus límites también vienen de ser oficial: solo Enterprise, una lista limitada de periféricos RFID soportados, y un modelo de escala de una caja por estación — los despliegues multi-puerta y multi-zona crecen cajas y mantenimiento linealmente. Para proyectos ya en Enterprise que necesitan uno o dos dispositivos de la lista soportada, la IoT Box es una opción por defecto razonable.
Ruta 3: middleware
El middleware no es un módulo; es un servicio independiente que habla los idiomas de los lectores por un lado (LLRP, SDKs de fabricantes, MQTT, HTTP) y el idioma de Odoo por el otro (XML-RPC o JSON-RPC). Sus características:
- Independiente de versión. El mismo middleware conecta con Odoo 17, 18, 19 y 20 con comportamiento idéntico en Community y Enterprise — el middleware de SpidersRFID está diseñado para todas las versiones 17-20 en ambas ediciones, así que actualizar Odoo nunca significa volver a comprar la integración.
- Orientado a eventos. Los flujos continuos de lecturas que producen lectores fijos, portales de muelle, AGV y drones los deduplica y agrega el middleware antes de escribir, en lugar de empujarlos por una interfaz diseñada para escaneo humano.
- Entre módulos. Un evento de lectura puede impulsar a la vez cantidades de inventario, entradas y salidas de activos y consumo en fabricación, porque el enrutamiento vive en la capa de middleware, no en un módulo concreto.
El coste es el despliegue y mantenimiento de un componente independiente, y una inversión inicial mayor que la de un módulo.
Las tres rutas comparadas
| Dimensión | Módulo de la tienda | IoT Box | Middleware |
|---|---|---|---|
| Versiones Odoo | Fijado a la versión de compilación, seguimiento por versión | Solo Enterprise | 17-20, Community y Enterprise por igual |
| Alcance hardware | Un handheld, según módulo | Periféricos de la lista oficial | Handhelds + lectores fijos + robots/drones |
| Flujos cubiertos | Un módulo (mayormente barcode de stock) | Conectividad de dispositivos | Automatización de eventos entre módulos |
| Riesgo de actualización | Verificar en cada versión mayor | Sigue las actualizaciones de Enterprise | Bajo (capa API estable) |
| Coste típico | Decenas a cientos de USD por módulo | Suscripción Enterprise + hardware | Inversión por proyecto, según tamaño de sitio |
Cómo elegir
- Un handheld, personal escaneando etiquetas en el flujo de barcode de stock, presupuesto ajustado: módulo de la tienda. Los módulos de mapeo como app_rfid_stock_barcode son el camino más corto.
- Ya en Enterprise, dispositivos en la lista oficial, solo una o dos unidades: la IoT Box.
- Lectores fijos en muelle, sincronización de quant en tiempo real, puntos de lectura en robots o drones, vínculo entre activos y fabricación, o una integración en cualquier versión 17-20 (incluida Community): middleware.
La arquitectura madura más común es una combinación: el middleware lleva los puntos de lectura fijos y los flujos de eventos, mientras los flujos handheld concretos se quedan en la app Barcode o en un módulo ligero. Aclara antes tus tipos de punto de lectura y tu plan de versiones — invertir el orden suele duplicar el coste.
Preguntas frecuentes
**¿Puede usarse RFID en Odoo Community?** Sí. Community no tiene IoT Box, pero las otras dos rutas funcionan: un módulo propio o de terceros sirve para handhelds, y el middleware usa las API públicas XML-RPC/JSON-RPC con comportamiento idéntico en Community 17-20 y Enterprise.
**¿Pueden convivir la IoT Box y el middleware?** Sí. La IoT Box gestiona los periféricos de su lista soportada y el middleware los lectores fijos y la automatización de eventos; ambos escriben en la misma instancia de Odoo sin conflicto, con la deduplicación en la capa de middleware para evitar dobles escrituras.
**¿Aguanta la carga de producción un módulo RFID de la tienda?** Para un handheld con escaneo de baja frecuencia, sí. Su debilidad no son las funciones sino los límites: fijación de versión, alcance de un solo módulo, y ausencia de puntos de lectura fijos y de colas. Cuando el volumen de lecturas y los puntos crecen, lo habitual es migrar a middleware.
