MRP S3 — OEE-Überwachung in Echtzeit (Industrial IoT, Odoo Community)

MRP N3 — IoT & OEE in Echtzeit (DYONYSOS)

Überwachung der Anlageneffektivität (OEE / TRS) anhand von Maschinenereignissen, ohne auch nur einen OPC-UA- oder MQTT-Client in Odoo einzubetten.

Wichtig — was die App leistet, und was nicht. Ein klassisches Odoo-Modul hat keinen dauerhaften Daemon-Prozess: Es kann keine OPC-UA- oder MQTT-Verbindung zu einer Steuerung offen halten. Diese Anwendung behauptet das daher nicht. Sie stellt einen generischen HTTP-Webhook bereit, gesichert durch ein Token je Arbeitsplatz, der die Maschinenereignisse (Start, Stopp, Gutteil, Ausschussteil, Störung) empfängt. Werkstattseitig leitet eine Brücke — ein kleines Python-Skript, ein Node-RED-Flow oder ein am Markt erhältliches OPC-UA/MQTT-zu-HTTP-Gateway — die Ereignisse der Steuerungen an diesen Webhook weiter. Das ist eine gewollte und dokumentierte Entscheidung (siehe die README), kein versteckter Kompromiss: Es ist dasselbe Prinzip, das DYONYSOS bereits bei Bank Sync, Click to Call und Social Marketing anwendet.

• Zugriffstoken je Arbeitsplatz: automatisch erzeugt, mit einem Klick neu erzeugbar.

• Webhook `POST /mrp_iot/event/<jeton>`: generisches JSON (Ereignistyp, Zeitstempel, freie Stillstandsursache, Menge); 404 bei unbekanntem Token, 400 bei ungültigem Payload, sonst 200. Jedes Ereignis wird vollständig gespeichert (Audit) im neuen Modell dyo.mrp.iot.event.

• OEE in Echtzeit je Arbeitsplatz: Verfügbarkeit (tatsächliche Laufzeit / Öffnungszeit des beobachteten Zeitraums, aus den Ereignissen Start/Stopp/Störung), Leistung (produzierte Teile × theoretische Zykluszeit / tatsächliche Laufzeit – Zykluszeit konfigurierbar am Arbeitsplatz oder am laufenden Produkt), Qualität (Gutteile / (Gutteile + Ausschuss)), OEE = Produkt der drei Faktoren.

• Verlauf: stündliche Momentaufnahme (dyo.mrp.iot.oee.snapshot, Cron) zusätzlich zur Berechnung im laufenden Betrieb für das Dashboard „jetzt“; Diagramm der letzten Tage je Arbeitsplatz.

• Optionale automatische Auslösung (standardmäßig deaktiviert, je Arbeitsplatz): Ein Ereignis „Start“ startet den an diesem Arbeitsplatz wartenden Arbeitsauftrag, wenn er eindeutig ist (oder im Payload unmissverständlich referenziert wird); ein Ereignis „Stopp“ schließt ihn auf dieselbe Weise ab. Bei Mehrdeutigkeit: keine Aktion, protokollierte Warnung.

Demodaten: drei Arbeitsplätze mit einer simulierten Ereignishistorie über den laufenden Tag.