MRP N3 — OEE-opvolging in realtime (industrieel IoT, Odoo Community)

MRP N3 — IoT & OEE in realtime (DYONYSOS)

Opvolging van de industriële prestatie (OEE / TRS) op basis van machine-events, zonder ook maar één OPC-UA- of MQTT-client in Odoo in te bouwen.

Belangrijk — wat de app doet, en wat ze niet doet. Een klassieke Odoo-module heeft geen persistent daemonproces: ze kan geen open OPC-UA- of MQTT-verbinding naar een automaat onderhouden. Deze toepassing beweert dat dus niet. Ze stelt een generieke HTTP-webhook beschikbaar, beveiligd met een token eigen aan elk werkcentrum, die de machine-events ontvangt (start, stop, goed stuk, afgekeurd stuk, storing). Aan de werkplaatszijde geeft een brug — klein Python-script, Node-RED-flow, of OPC-UA/MQTT-naar-HTTP-gateway uit de handel — de events van de automaten door naar deze webhook. Het is een bewuste en gedocumenteerde keuze (zie de README), geen verborgen compromis: het is hetzelfde principe dat DYONYSOS al toepast op Bank Sync, Click to Call en Social Marketing.

• Toegangstoken per werkcentrum: automatisch gegenereerd, met één klik te hergenereren.

• Webhook `POST /mrp_iot/event/<jeton>`: generieke JSON (type gebeurtenis, tijdstempel, vrije oorzaak van stilstand, hoeveelheid); 404 bij onbekend token, 400 bij ongeldige payload, anders 200. Elke gebeurtenis wordt volledig opgeslagen (audit) in het nieuwe model dyo.mrp.iot.event.

• OEE / TRS in real time per werkcentrum: Beschikbaarheid (werkelijke bedrijfstijd / openingstijd van de waargenomen periode, op basis van de gebeurtenissen start/stop/storing), Prestatie (geproduceerde stuks × theoretische cyclustijd / werkelijke bedrijfstijd — cyclustijd instelbaar op het werkcentrum of op het lopende product), Kwaliteit (goede / (goede + afgekeurde)), TRS = product van de drie factoren.

• Historiek: uurlijkse momentopname (dyo.mrp.iot.oee.snapshot, cron) naast de berekening op het moment zelf voor het dashboard “nu”; grafiek van de laatste dagen per werkcentrum.

• Optionele automatische trigger (standaard uitgeschakeld, per werkcentrum): een event “start” start de wachtende werkorder op dat centrum als hij eenduidig is (of ondubbelzinnig in de payload wordt vermeld); een event “stop” sluit hem op dezelfde manier af. Bij dubbelzinnigheid: geen enkele actie, gelogde waarschuwing.

Demonstratiegegevens: drie werkcentra met een gesimuleerde gebeurtenishistoriek over de lopende dag.