> For the complete documentation index, see [llms.txt](https://docs.kiloiot.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kiloiot.io/kilo-docs-fr/kilo-iot-server/rules-engine/automation-patterns.md). # Modèles d’automatisation Modèles d’automatisation pour Kilo IoT — alertes de seuil, enrichissement multi-capteurs, escalade, CEL dynamique. Cette page présente des modèles d'automatisation éprouvés pour les déploiements IoT d'entreprise. Chaque modèle décrit un scénario opérationnel réel, la structure du diagramme BPMN, les expressions CEL impliquées et les cas où utiliser le modèle. La plupart de ces modèles sont construits visuellement en disposant des nœuds sur le canevas BPMN. CEL apparaît aux endroits ciblés où la règle nécessite une logique précise, une classification ou des messages dynamiques. Comme CEL prend en charge les conditions imbriquées, les valeurs calculées, les comparaisons entre capteurs et la génération de texte dynamique, la gamme d'automatisations que vous pouvez modéliser est large — d'une simple vérification de seuil à des workflows multi-étapes, multi-capteurs, avec des chemins de repli et une escalade progressive. Ces modèles s'appuient sur les types de nœuds et les outils de canevas présentés dans [Référence des nœuds](/kilo-docs-fr/kilo-iot-server/rules-engine/node-reference.md) et [Éditeur visuel](/kilo-docs-fr/kilo-iot-server/rules-engine/visual-editor.md). Si vous débutez avec le moteur de règles, commencez par [Créer des règles](/kilo-docs-fr/kilo-iot-server/rules-engine/creating-rules.md) pour en comprendre les bases. *** ## Modèle 1 : alarme de seuil simple Le modèle d'automatisation le plus courant. Un capteur transmet une valeur, la règle vérifie si elle dépasse une limite et déclenche une alarme si c'est le cas. ### Structure du diagramme ``` Événement de début → Tâche de script → Passerelle exclusive → Définir l'alarme → Événement de fin ↓ (par défaut) Événement de fin ``` ### Configuration **Événement de début :** Relié à l'appareil et au capteur cible — par exemple, une sonde de température de chambre froide qui transmet des degrés Celsius. **Tâche de script** — « Vérifier le seuil » : ``` {"above_threshold": vars.value > 30.0} ``` Cette expression crée un indicateur booléen. La passerelle utilise cet indicateur pour décider s'il faut déclencher une alarme. **Passerelle exclusive** — Deux branches : * **Branche d'alarme :** Condition `vars.above_threshold == true` — redirige vers le nœud Définir l'alarme * **Branche par défaut :** Redirige vers un événement de fin (aucune action requise lorsque la mesure reste dans la plage) **Définir l'alarme :** Configuré avec une [Définition d'alarme](/kilo-docs-fr/kilo-iot-server/alarm.md) existante et un message de motivation tel que `"La mesure de température a dépassé 30 °C"`. Le nœud Définir l'alarme déclenche la définition — la gravité, les canaux et l'escalade sont configurés sur la page Alarmes, et non dans la règle elle-même. ### Quand utiliser ce modèle * Surveillance de la température en chambre froide — alerter lorsque la température dépasse le seuil de sécurité * Surveillance environnementale d'une salle serveur — alerter lorsque la température ambiante ou l'humidité dépasse les limites d'exploitation * Surveillance des vibrations des équipements — alerter lorsque l'amplitude des vibrations dépasse la valeur de référence * Tout scénario à capteur unique et seuil unique où une mesure hors plage nécessite une attention immédiate *** ## Modèle 2 : escalade multiniveau Lorsqu'un seul seuil ne suffit pas, ce modèle classe la mesure en niveaux de gravité et dirige chaque niveau vers une définition d'alarme différente — ce qui permet d'utiliser pour chaque gravité des canaux de notification, des chaînes d'escalade et des procédures de réponse distincts. ### Structure du diagramme ``` Événement de début → Tâche de script → Passerelle exclusive → Définir l'alarme (Critique) → Événement de fin ↓ (avertissement) Définir l'alarme (Avertissement) → Événement de fin ↓ (par défaut) Événement de fin ``` ### Configuration **Tâche de script** — « Classer la gravité » : ``` {"level": vars.value > 80 ? "critical" : vars.value > 50 ? "warning" : "normal"} ``` Cette expression évalue la mesure et attribue un niveau de gravité sous forme de chaîne. **Passerelle exclusive** — Trois branches : * **Branche critique :** Condition `vars.level == "critical"` — redirige vers la définition d'alarme Critique (SMS à l'ingénieur d'astreinte, e-mail au responsable du site) * **Branche d'avertissement :** Condition `vars.level == "warning"` — redirige vers la définition d'alarme Avertissement (e-mail à l'équipe d'exploitation) * **Branche par défaut :** Redirige vers un événement de fin (les mesures normales ne nécessitent aucune action) ### Quand utiliser ce modèle * Surveillance CVC avec réponse graduée — avertissement lorsqu'une zone sort de la plage de confort, critique lorsqu'elle atteint des niveaux dangereux * Conformité environnementale — avertissement lorsqu'une mesure approche une limite réglementaire, critique lorsqu'elle la dépasse * Surveillance des batteries — avertissement à 20 %, critique à 10 %, avec une urgence de notification différente pour chacun * Tout scénario où différents niveaux de gravité exigent des vitesses de réponse, des canaux ou des équipes différents *** ## Modèle 3 : comparaison multi-capteurs Certaines décisions nécessitent des données provenant de plus d'un capteur. Ce modèle récupère une deuxième mesure à l'aide d'un nœud d'enrichissement, calcule la relation entre les deux valeurs et décide en fonction du résultat. ### Structure du diagramme ``` Événement de début → Enrichissement → Tâche de script → Passerelle exclusive → Définir l'alarme → Événement de fin ↓ (par défaut) Événement de fin ``` ### Configuration **Événement de début :** Relié à un capteur de température intérieur. **Enrichissement** — « Récupérer la température extérieure » : configuré pour récupérer la dernière mesure d'un capteur de température extérieur sur le même site. La valeur enrichie devient disponible sous forme de variable dans les nœuds suivants. **Tâche de script** — « Calculer le différentiel » : ``` {"delta": vars.value - vars.outdoor_temp.value, "needs_alarm": vars.value - vars.outdoor_temp.value > 10} ``` Cette expression calcule la différence de température entre les capteurs intérieur et extérieur et indique si l'écart dépasse le seuil. **Passerelle exclusive** — Deux branches : * **Branche d'alarme :** Condition `vars.needs_alarm == true` — redirige vers Définir l'alarme * **Branche par défaut :** Redirige vers l'événement de fin **Définir l'alarme :** Configuré avec un message de motivation tel que `"L'écart de température intérieur/extérieur dépasse 10 degrés"`. ### Important : ajoutez une gestion des erreurs Les nœuds d'enrichissement dépendent de données externes — le capteur cible peut être hors ligne, inaccessible ou renvoyer des données obsolètes. Attachez toujours un **événement d'erreur de frontière** au nœud d'enrichissement. Voir [Modèle 4](#pattern-4-error-safe-enrichment) pour l'approche complète de gestion des erreurs. ### Quand utiliser ce modèle * Surveillance de l'efficacité CVC — alerter lorsque l'écart de température intérieur/extérieur indique une défaillance de l'isolation ou un dysfonctionnement du CVC * Surveillance de la pression différentielle — comparer les capteurs de pression entre les zones de salle blanche * Validation de capteurs redondants — comparer les mesures de deux capteurs mesurant la même métrique et alerter s'ils divergent significativement * Tout scénario où une décision dépend de la relation entre deux points de données plutôt que d'un seuil absolu *** ## Modèle 4 : enrichissement tolérant aux erreurs Toute règle qui utilise un nœud d'enrichissement doit gérer la possibilité que l'enrichissement échoue. Ce modèle entoure le nœud d'enrichissement d'un événement d'erreur de bord qui redirige vers une alarme de repli, garantissant que la règle n'échoue jamais silencieusement lorsqu'un capteur de référence est indisponible. ### Structure du diagramme ``` Événement de début → Enrichissement → Tâche de script → Passerelle exclusive → Définir l'alarme → Événement de fin | ↓ (par défaut) [Erreur de bord] Événement de fin ↓ Définir l'alarme (repli) → Événement de fin ``` ### Configuration **Enrichissement :** Même configuration que dans le modèle 3 — récupère une mesure d'un capteur secondaire. **Événement d'erreur de bord :** Attaché au nœud d'enrichissement. Si l'enrichissement échoue pour quelque raison que ce soit (capteur hors ligne, délai d'attente, données manquantes), l'événement d'erreur intercepte l'échec et redirige vers le chemin de repli. **Définir l'alarme (repli) :** Configuré avec une définition d'alarme différente et un message de motivation tel que `"Capteur de référence hors ligne — impossible de calculer le différentiel. Vérification manuelle requise."` Cela garantit que votre équipe d'exploitation sait que la vérification automatisée n'a pas pu être menée à terme. ### Quand utiliser ce modèle * Toute règle qui utilise l'enrichissement et ne peut pas se permettre d'échouer silencieusement * Scénarios de surveillance critiques où l'absence de mesure de comparaison est en elle-même une condition d'alerte * Flux de travail de conformité où chaque lacune de surveillance doit être documentée * En tant que bonne pratique standard : attachez un événement d'erreur de bord à chaque nœud d'enrichissement dans chaque règle *** ## Modèle 5 : pipeline de transformation des données Certaines données de capteurs nécessitent un prétraitement avant de pouvoir être évaluées de manière pertinente. Ce modèle enchaîne plusieurs tâches de script pour transformer les mesures brutes via des étapes de conversion d'unités, d'étalonnage ou de normalisation avant la passerelle de décision. ### Structure du diagramme ``` Événement de début → Tâche de script (Conversion) → Tâche de script (Étalonnage) → Passerelle exclusive → Définir l'alarme → Événement de fin ↓ (par défaut) Événement de fin ``` ### Configuration **Tâche de script** — « Convertir les unités » : ``` {"celsius": (vars.value - 32) * 5.0 / 9.0} ``` Convertit une mesure en Fahrenheit en Celsius. Adaptez la formule à vos besoins de conversion spécifiques. **Tâche de script** — « Appliquer le décalage d'étalonnage » : ``` {"calibrated": vars.celsius - 1.5, "above_threshold": vars.celsius - 1.5 > 25.0} ``` Applique un décalage d'étalonnage connu (dans cet exemple, le capteur indique 1,5 degré de trop) et vérifie la valeur corrigée par rapport au seuil. **Passerelle exclusive** — Deux branches : * **Branche d'alarme :** Condition `vars.above_threshold == true` * **Branche par défaut :** Redirige vers l'événement de fin ### Quand utiliser ce modèle * Capteurs transmettant des unités non standard qui doivent être converties avant la comparaison au seuil * Capteurs présentant des décalages d'étalonnage connus qui doivent être corrigés avant l'évaluation * Normalisation des données pour des capteurs de différents fabricants qui transmettent la même métrique dans des échelles différentes * Tout scénario où les données brutes du capteur nécessitent une ou plusieurs étapes de transformation avant d'être utiles à la prise de décision *** ## Modèle 6 : enrichissement conditionnel avec logique de repli Un modèle plus avancé qui combine enrichissement, transformation, gestion des erreurs et décisions à plusieurs branches dans une seule règle robuste. Ce modèle représente un flux d'automatisation de niveau production. ### Structure du diagramme ``` Événement de début → Enrichissement → Tâche de script (Analyse) → Passerelle exclusive → Définir l'alarme (Critique) → Événement de fin | ↓ (avertissement) [Erreur de bord] Définir l'alarme (Avertissement) → Événement de fin ↓ ↓ (par défaut) Tâche de script (repli) → Définir l'alarme (Hors ligne) → Événement de fin ``` ### Configuration **Enrichissement :** Récupère une mesure de référence (par exemple, l'humidité extérieure pour un entrepôt). **Événement d'erreur de bord :** Intercepte les échecs d'enrichissement et redirige vers une tâche de script de repli dédiée. **Tâche de script (repli) :** ``` {"level": "offline"} ``` Définit le niveau sur "offline" afin que l'alarme de repli se déclenche. **Tâche de script (Analyse) :** ``` {"delta": vars.value - vars.reference.value, "level": vars.value - vars.reference.value > 20 ? "critical" : vars.value - vars.reference.value > 10 ? "warning" : "normal"} ``` **Passerelle exclusive** — Trois branches : * **Critique :** `vars.level == "critical"` * **Avertissement :** `vars.level == "warning"` * **Par défaut :** Événement de fin Ce modèle gère le scénario nominal (l'enrichissement réussit, les données sont analysées, l'alarme appropriée se déclenche), le chemin d'avertissement et le chemin d'échec (l'enrichissement échoue, l'équipe d'exploitation est alertée du problème du capteur) — le tout dans une seule règle. *** ## Bonnes pratiques pour créer des règles d'automatisation ### Commencez simplement, ajoutez de la complexité au besoin Commencez par le modèle 1 (seuil simple) et n'ajoutez l'enrichissement, la classification multiniveau ou les étapes de transformation que lorsque le scénario opérationnel l'exige réellement. Une règle simple qui fonctionne de manière fiable est préférable à une règle complexe difficile à dépanner. ### Nommez vos nœuds de façon descriptive Les noms de nœuds par défaut comme "Tâche de script 1" ne veulent rien dire lors du dépannage. Nommez les nœuds d'après ce qu'ils font : "Vérifier le seuil de température", "Classer la gravité", "Récupérer la mesure extérieure". Votre vous futur — et vos collègues — vous en seront reconnaissants lorsque vous examinerez la règle à 3 heures du matin. ### Ajoutez toujours une branche par défaut aux passerelles Chaque passerelle exclusive devrait avoir une branche par défaut qui redirige vers un événement de fin. Cela garantit que la règle se termine proprement même si aucune des conditions explicites ne correspond. Sans branche par défaut, la règle n'a aucun chemin de sortie pour les valeurs inattendues. ### Attachez toujours des événements d'erreur de bord aux nœuds d'enrichissement L'enrichissement dépend de données externes. Si le capteur cible est hors ligne, supprimé ou temporairement inaccessible, l'enrichissement échouera. Un événement d'erreur de bord fournit un repli gracieux — soit en redirigeant vers une alarme « capteur hors ligne », soit en ignorant entièrement la logique dépendante de l'enrichissement. ### Utilisez des fenêtres de suppression des alarmes pour éviter les tempêtes de notifications Lorsqu'un seuil est continuellement dépassé, les paramètres de suppression et de répétition de la définition d'alarme évitent aux opérateurs d'être inondés de notifications dupliquées. Configurez ces paramètres dans votre [Définitions d’alarme](/kilo-docs-fr/kilo-iot-server/alarm.md) plutôt que d'essayer d'intégrer la logique de suppression dans la règle elle-même. ### Gardez les expressions simples Les expressions CEL doivent être faciles à lire et à comprendre. Si une expression dépasse une seule ligne, découpez la logique en plusieurs tâches de script. Chaque tâche gère un calcul, et les résultats sont transmis à l'étape suivante sous forme de variables. ### Une règle par besoin Résistez à la tentation de construire une seule règle qui surveille simultanément la température, l'humidité, le CO2 et les vibrations. Des règles séparées sont plus faciles à versionner, tester, déployer et dépanner indépendamment. Si une règle doit être mise à jour ou restaurée, les autres continuent de fonctionner sans être affectées. ### Construisez et déployez avec discernement Après avoir effectué des modifications, compilez la règle pour la valider. Vérifiez le nom et le commentaire de l'artefact de build. Déployez uniquement lorsque vous êtes certain que la règle est correcte. Le flux explicite compilation puis déploiement existe pour empêcher que des modifications non testées n'atteignent la production. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.kiloiot.io/kilo-docs-fr/kilo-iot-server/rules-engine/automation-patterns.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.