MRP N3 — Suivi OEE/TRS Temps Réel (IoT Industriel, Odoo Community)

MRP N3 — IoT & OEE temps réel (DYONYSOS)

Suivi de la performance industrielle (OEE / TRS) à partir des événements machine, sans embarquer le moindre client OPC-UA ou MQTT dans Odoo.

Important — ce que l'app fait, et ce qu'elle ne fait pas. Un module Odoo classique n'a pas de processus démon persistant : il ne peut pas maintenir une connexion OPC-UA ou MQTT ouverte vers un automate. Cette application ne le prétend donc pas. Elle expose un webhook HTTP générique, sécurisé par un jeton propre à chaque centre de charge, qui reçoit les événements machine (démarrage, arrêt, pièce bonne, pièce rebutée, panne). Côté atelier, un pont — petit script Python, flux Node-RED, ou passerelle OPC-UA/MQTT-vers-HTTP du marché — relaie les événements des automates vers ce webhook. C'est un choix assumé et documenté (voir le README), pas un compromis caché : c'est le même principe déjà appliqué par DYONYSOS sur Bank Sync, Click to Call et Social Marketing.

• Jeton d'accès par centre de charge : généré automatiquement, régénérable en un clic.

• Webhook `POST /mrp_iot/event/<jeton>` : JSON générique (type d'événement, horodatage, cause d'arrêt libre, quantité) ; 404 si jeton inconnu, 400 si payload invalide, 200 sinon. Chaque événement est stocké intégralement (audit) dans le nouveau modèle dyo.mrp.iot.event.

• OEE / TRS temps réel par centre de charge : Disponibilité (temps de fonctionnement réel / temps d'ouverture de la période observée, à partir des événements démarrage/arrêt/panne), Performance (pièces produites × temps de cycle théorique / temps de fonctionnement réel — temps de cycle configurable sur le centre de charge ou sur le produit en cours), Qualité (bonnes / (bonnes + rebutées)), TRS = produit des trois facteurs.

• Historique : instantané horaire (dyo.mrp.iot.oee.snapshot, cron) en plus du calcul à la volée pour le tableau de bord « maintenant » ; graphique des derniers jours par centre de charge.

• Déclenchement automatique optionnel (désactivé par défaut, par centre de charge) : un événement « démarrage » démarre l'ordre de travail en attente sur ce centre s'il est univoque (ou référencé sans ambiguïté dans le payload) ; un événement « arrêt » le clôture de la même façon. En cas d'ambiguïté : aucune action, avertissement journalisé.

Données de démonstration : trois centres de charge avec un historique d'événements simulé sur la journée en cours.