"Ein RFID-Modul auf Odoo installieren" verbirgt hinter einem Satz drei völlig verschiedene Ingenieursentscheidungen. Der Apps Store enthält tatsächlich Module namens RFID; Enterprise bringt eine IoT Box mit; und die meisten RFID-Systeme im Produktionsbetrieb nutzen am Ende ein Drittes — Middleware außerhalb von Odoo, die über XML-RPC oder JSON-RPC hineinschreibt. Kein Weg ist universell besser, aber jeder hat klare Grenzen. Dieser Beitrag legt alle drei nebeneinander.
Weg 1: Module aus dem Odoo Apps Store
RFID-relevante Module im Apps Store fallen grob in zwei Familien:
- Tag-Mapping-Module: vertreten durch "RFID/NFC Tags for Stock Barcode" (app_rfid_stock_barcode), das jede Tag-Serie auf einen echten Barcode abbildet, sodass Mitarbeiter RFID-Tags im bestehenden Barcode-Workflow scannen — Lagermitarbeiter lernen keine neue Oberfläche.
- Hardware-Brücken-Module: etwa yudha_rfid_base, das die Basisschicht für die Kommunikation mit Leserhardware liefert und die Workflows darüber dem Entwickler überlässt.
Die Stärken sind Kosten, schnelle Installation und Sofortverfügbarkeit. Die Schwächen sind ebenso explizit: Scope auf den Workflow eines einzigen Moduls beschränkt (meist die Stock-Barcode-App), enge Versionsbindung (für eine bestimmte Odoo-Version gebaut, Upgrades warten auf den Autor), und feste Leser, Roboter und modulübergreifende Automatisierung weitgehend außer Reichweite.
Weg 2: die Enterprise-IoT-Box
Die IoT Box ist Odooos offizieller Gerätecontainer: ein Raspberry-Pi-basiertes Board, das nach dem Anbinden ans IoT-Menü unterstützte Peripheriegeräte automatisch erkennt. Ihr Vorteil ist, offiziell zu sein — Treiber und Odoo-Versionen pflegt dasselbe Team, und die Konfiguration ist reibungslos.
Ihre Grenzen stammen ebenfalls aus der Offiziell-Sein-Eigenschaft: nur Enterprise, eine begrenzte Liste unterstützter RFID-Peripherie, und ein Skalenmodell von einer Box pro Station — Multi-Tor- und Multi-Zonen-Deployments wachsen Boxen und Wartung linear. Für Projekte, die bereits Enterprise sind und ein oder zwei Geräte von der Unterstützten-Liste brauchen, ist die IoT Box eine vernünftige Voreinstellung.
Weg 3: Middleware
Middleware ist kein Modul; sie ist ein eigenständiger Dienst, der auf der einen Seite die Sprachen der Leser spricht (LLRP, Hersteller-SDKs, MQTT, HTTP) und auf der anderen Odooos Sprache (XML-RPC oder JSON-RPC). Ihre Merkmale:
- Versionsunabhängig. Dieselbe Middleware verbindet sich mit Odoo 17, 18, 19 und 20 mit identischem Verhalten auf Community und Enterprise — die SpidersRFID-Middleware ist für alle Versionen 17-20 in beiden Editionen ausgelegt, sodass ein Odoo-Upgrade nie den Wiederkauf der Integration bedeutet.
- Ereignisgetrieben. Die kontinuierlichen Leseströme von festen Lesern, Torportalen, AGVs und Drohnen dedupliziert und aggregiert die Middleware, bevor sie schreibt — statt sie durch eine für menschliches Scannen entworfene Schnittstelle zu drücken.
- Modulübergreifend. Ein einziges Leseereignis kann gleichzeitig Bestandsmengen, Asset-Ein- und -Ausgaben und Fertigungsverbrauch treiben, weil das Routing in der Middleware-Schicht lebt, nicht in einem einzelnen Modul.
Der Preis sind Deployment und Wartung einer unabhängigen Komponente und eine höhere Anfangsinvestition als bei einem Modul.
Die drei Wege im Vergleich
| Dimension | Apps-Store-Modul | IoT Box | Middleware |
|---|---|---|---|
| Odoo-Versionen | an Build-Version gebunden, Folgebarem pro Release | nur Enterprise | 17-20, Community und Enterprise gleichermaßen |
| Hardwareumfang | ein Handheld, modulabhängig | offiziell unterstützte Peripherie | Handhelds + feste Leser + Roboter/Drohnen |
| Abgedeckte Workflows | ein Modul (meist Stock-Barcode) | Geräteanbindung | modulübergreifende Ereignisautomatisierung |
| Upgraderisiko | Prüfung bei jedem Hauptrelease | folgt Enterprise-Upgrades | gering (stabile API-Schicht) |
| Typische Kosten | Zehn- bis Hunderte USD pro Modul | Enterprise-Abo + Box-Hardware | Investition auf Projektebene, je Standortgröße |
Wie man wählt
- Ein Handheld, Personal scannt Tags im Stock-Barcode-Workflow, knappes Budget: ein Apps-Store-Modul. Mapping-Module wie app_rfid_stock_barcode sind der kürzeste Weg.
- Bereits Enterprise, Geräte auf der offiziellen Liste, nur ein oder zwei Stück: die IoT Box.
- Feste Leser am Tor, Echtzeit-Bestandssync, Lesepunkte an Robotern oder Drohnen, Asset- und Fertigungsverknüpfung, oder eine Integration über jede Version 17-20 (Community inklusive): Middleware.
Die reifste Architektur ist meist eine Kombination: Middleware trägt feste Lesepunkte und Ereignisströme, während einzelne Handheld-Workflows in der Barcode-App oder einem leichten Modul bleiben. Klären Sie zuerst Ihre Lesepunkt-Typen und den Versionsplan — die umgekehrte Reihenfolge verdoppelt die Kosten üblicherweise.
Häufig gestellte Fragen
**Kann die Odoo Community Edition RFID nutzen?** Ja. Community hat keine IoT Box, aber beide anderen Wege funktionieren: ein eigenes oder Drittanbieter-Modul bedient Handhelds, und Middleware nutzt die öffentlichen XML-RPC/JSON-RPC-APIs mit identischem Verhalten auf Community 17-20 und Enterprise.
**Können IoT Box und Middleware zusammenlaufen?** Ja. Die IoT Box betreut die Peripherie ihrer Unterstützten-Liste, die Middleware feste Leser und Ereignisautomatisierung; beide schreiben in dieselbe Odoo-Instanz ohne Konflikt, mit Deduplizierung in der Middleware-Schicht, um Doppelschreibungen zu vermeiden.
**Hält ein RFID-Modul aus dem Apps Store die Produktionslast aus?** Für einen Handheld mit seltenem Scannen: ja. Seine Schwäche sind nicht die Funktionen, sondern die Grenzen: Versionsbindung, Ein-Modul-Scope und fehlende feste Lesepunkte sowie Warteschlangen. Wachsen Lesevolumen und Lesepunkte, migrieren Projekte typischerweise zu Middleware.
