> 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/node-reference.md).
# Référence des nœuds
Référence des nœuds pour le moteur de règles — Début, Fin, Script, Passerelle, Définir alarme, Enrichissement, Limite.
Chaque règle d’automatisation est construite à partir d’un ensemble de types de nœuds que vous faites glisser sur le canevas de l’éditeur visuel, que vous reliez par des flux et que vous configurez via un panneau de propriétés. Cette page documente chaque type de nœud — ce qu’il fait, quand l’utiliser, comment il apparaît sur le canevas et chaque champ de son panneau de propriétés.
Cette page documente les nœuds actuellement disponibles dans la palette active : **Événement de début**, **Événement de fin**, **Tâche Script**, **Passerelle exclusive**, **Définir une alarme**, **Exécuter la commande**, **Enrichissement**, et **Événement d’erreur de bordure**. Les nœuds transitoires ou prévus sont volontairement exclus tant qu’ils ne font pas partie de la surface active de l’éditeur.
Pour un aperçu du canevas lui-même — palette, barre d’outils et flux de travail général d’édition — voir [Éditeur visuel](/kilo-docs-fr/kilo-iot-server/rules-engine/visual-editor.md).
***
## Événement de début
Le Start Event est le point d’entrée de chaque règle. Il décide de ce qui déclenche la règle — soit les relevés de capteur d’un appareil, soit un déclencheur enregistré [déclencheur](/kilo-docs-fr/kilo-iot-server/rules-engine/triggers.md) qui évalue une condition pour un ou plusieurs appareils. Chaque règle doit comporter exactement un Start Event.
### Apparence visuelle
Un cercle avec une icône d’enveloppe à l’intérieur.
### Quand l’utiliser
Chaque règle commence ici. Vous ne pouvez pas construire une règle valide sans Start Event.
### Panneau de propriétés
Sélectionnez le Start Event sur le canevas — une icône de crayon et une icône de corbeille apparaissent en dessous. Cliquez sur le **crayon** pour ouvrir son panneau de propriétés à droite.
**Nom** — Un champ texte pour l’étiquette du nœud. Texte indicatif : *p. ex. Alarme incendie*.
**Source de démarrage** — Une liste de sélection avec deux options qui détermine ce que le reste du panneau demande. Un Start Event nomme l’une ou l’autre source ; indiquer les deux, ou aucune, est rejeté.
| Option | Ce à partir de quoi la règle démarre |
| ------------------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Lecture du capteur** | Les relevés d’un appareil. La règle se déclenche à chaque rapport de ce capteur. |
| **Condition de déclenchement** | Un déclencheur enregistré [déclencheur](/kilo-docs-fr/kilo-iot-server/rules-engine/triggers.md). Sa condition peut agir immédiatement ou après une durée et peut évaluer un ou plusieurs appareils indépendamment. La règle s’exécute lorsque le déclencheur lui envoie un signal. |
**Filtre d’événement** — Affiché lorsque **Source de démarrage** est **Lecture du capteur**. Une section intitulée « Définissez quels appareils peuvent initier cette règle. » contenant deux champs :
| Champ | Description |
| ------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Appareil** | Liste déroulante d’autocomplétion consultable. Texte indicatif : *Sélectionner un appareil*. Répertorie tous les appareils de votre organisation. |
| **Capteur** | Liste déroulante d’autocomplétion. Texte indicatif : *Sélectionner un capteur*. Désactivé jusqu’à ce qu’un appareil soit choisi. N’affiche que les capteurs appartenant à l’appareil sélectionné. |
**Condition de déclenchement** — Affiché à la place du Filtre d’événement lorsque **Source de démarrage** est **Condition de déclenchement**. Une seule autocomplétion, texte indicatif *Sélectionner un déclencheur*, listant les déclencheurs définis dans l’onglet **Déclencheurs** onglet.
> Seule la première page de déclencheurs est chargée, et le champ le signale lorsqu’il y en a davantage. Si le déclencheur dont vous avez besoin n’est pas dans la liste, c’est pour cette raison — voir [Déclencheurs](/kilo-docs-fr/kilo-iot-server/rules-engine/triggers.md).
**Activer la planification** — Un interrupteur à bascule (désactivé par défaut). Lorsqu’il est activé, les champs suivants apparaissent :
| Champ | Description |
| ------------------ | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Plage horaire** | Apparaît lorsque la planification est activée, avec l’intitulé *« Plage horaire. La règle n’est active que pendant cette période : »*. Un **bouton Modifier la planification** ouvre l’éditeur, où vous choisissez les jours de la semaine pendant lesquels la règle peut s’exécuter et les **De** et **À** heures. En dehors de cette fenêtre, la règle ne s’exécute pas. Pour une source déclencheur, la surveillance et les décomptes continuent ; seule l’exécution de règle tentée est ignorée. |
| **Fuseau horaire** | Une liste déroulante des fuseaux horaires standard, afin que la fenêtre signifie la même chose quel que soit l’endroit où se trouve le lecteur. |
**Entrées** — Facultatif. Une liste d’expressions CEL avancées pour la préparation des données. La plupart des règles laissent ce champ vide et lisent directement la valeur entrante. Chaque entrée comporte :
* Un nom d’entrée (champ texte)
* Un indicateur de type (verrouillé sur « Expression »)
* Un champ d’expression CEL
* Ajoutez de nouvelles entrées avec le **+ Ajouter une entrée** bouton. Supprimez une entrée avec son bouton de suppression.
**Sorties** — Facultatif. Même structure que les Entrées, avec son propre **+ Ajouter une sortie** bouton. Utilisez les sorties pour publier des valeurs nommées dans `vars` pour les nœuds en aval.
**Enregistrer / Annuler** — En bas du panneau. Cliquez sur **Enregistrer** pour appliquer les modifications, ou **Annuler** pour les abandonner.
### Comment les données circulent depuis le Start Event
Les variables de processus dépendent de ce que le **Source de démarrage**.
**Lecture du capteur** fournit :
| Variable | Contenu |
| ---------------- | --------------------------------- |
| `vars.value` | La valeur signalée par le capteur |
| `vars.sensor_id` | L’identifiant unique du capteur |
| `vars.timestamp` | L’horodatage de la mesure |
**Condition de déclenchement** fournit :
| Variable | Contenu |
| ------------------- | ------------------------------------------------------------------------------------------------- |
| `vars.device_name` | Le nom de l’appareil surveillé qui a satisfait le déclencheur |
| `vars.subject_kind` | Le type de ressource surveillée ; actuellement `device` |
| `vars.subject_id` | L’identifiant unique de l’appareil surveillé |
| `vars.sensor_id` | L’identifiant du capteur utilisé pour associer l’exécution et toute alarme à l’appareil surveillé |
| `vars.detector_id` | L’identifiant unique du déclencheur |
| `vars.timestamp` | L’heure du signal du déclencheur en secondes Unix |
Une règle déclenchée par un trigger ne reçoit pas `vars.value`. Voir [Données disponibles pour la règle](/kilo-docs-fr/kilo-iot-server/rules-engine/triggers.md#data-available-to-the-rule) avant la conversion d’une règle déclenchée par un capteur.
Le Start Event peut également reformater les données entrantes avant l’exécution du reste de la règle :
* **Entrées** créer des variables d’aide locales au nœud pour cette étape
* **Sorties** écrire des valeurs nommées dans les variables de processus que les nœuds en aval peuvent référencer
### Exemple
Une règle de conformité pour chaîne du froid dans un entrepôt pharmaceutique associe le Start Event à une sonde de température à l’intérieur de l’unité de stockage. La planification est laissée désactivée, puisque la sonde mérite d’être surveillée en continu ; s’il s’agissait d’une règle qui ne devait s’exécuter qu’en dehors des heures ouvrées, **bouton Modifier la planification** cela définirait ces jours et ces heures selon le fuseau horaire local de l’installation. Aucune entrée n’est nécessaire — la valeur brute de température suffit pour que la passerelle en aval l’évalue.
***
## Événement de fin
Le End Event met fin à une branche de flux. Lorsque l’exécution atteint un End Event, cette branche de la règle est terminée.
### Apparence visuelle
Un cercle avec une bordure épaisse.
### Quand l’utiliser
Chaque branche de votre règle doit se terminer par un End Event. Une règle comportant plusieurs branches (après une Passerelle exclusive, par exemple) nécessite plusieurs End Events — un par branche.
### Panneau de propriétés
| Champ | Description |
| ------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Nom** | Un champ texte pour l’étiquette du nœud. Généralement laissé comme « End » ou nommé pour décrire le résultat de cette branche (p. ex. « Normal — aucune action », « Alarme déclenchée »). |
Aucune autre configuration n’est requise.
### Exemple
Une règle qui vérifie si un relevé de température est supérieur ou inférieur à un seuil comporte deux branches sortant d’une Passerelle exclusive. Chaque branche se termine par son propre End Event — l’un intitulé « Dans la plage », l’autre passant par un nœud Définir une alarme.
***
## Tâche Script
La Tâche Script évalue une [CEL](https://cel.dev) expression. Utilisez-la pour transformer des données entrantes, calculer des valeurs dérivées, classer des relevés ou préparer des variables pour les décisions en aval.
### Apparence visuelle
Un rectangle aux coins arrondis avec une icône de script (document avec des lignes) dans le coin supérieur gauche.
### Quand l’utiliser
* Convertir une valeur brute de capteur en classification de gravité
* Calculer une différence entre deux valeurs (après enrichissement)
* Préparer une chaîne formatée pour un message d’alarme
* Définir un indicateur que les passerelles en aval évaluent
### Panneau de propriétés
| Champ | Description |
| ---------- | ---------------------------------------------------------------------------------------------------------- |
| **Nom** | Un champ texte pour l’étiquette du nœud. Valeur par défaut : « Script ». Exemple : « Classer la gravité ». |
| **Script** | Un champ d’expression CEL multiline (6 lignes). C’est ici que vous écrivez l’expression à évaluer. |
**Entrées** — Une liste de paramètres d’entrée évalués avant l’exécution du script. Chaque entrée comporte un nom, un indicateur de type (verrouillé sur « Expression ») et un champ d’expression CEL. Utilisez-les pour créer des variables d’aide locales pour la tâche. Ajoutez des entrées avec **+ Ajouter une entrée**. Supprimez-les avec le bouton de suppression.
**Sorties** — Même structure que les Entrées, avec son propre **+ Ajouter une sortie** bouton. Utilisez-les pour publier des valeurs nommées pour les nœuds en aval.
**Enregistrer / Annuler** — En bas du panneau.
### Comment les résultats sont stockés
Le schéma le plus clair consiste à demander à la Tâche Script de renvoyer une **carte** (une structure clé-valeur). Chaque clé est fusionnée individuellement dans les variables de processus. Par exemple, si l’expression de la Tâche Script est :
```cel
{"level": vars.value > 80 ? "critical" : "normal", "needs_action": vars.value > 80}
```
Alors les nœuds en aval peuvent référencer `vars.level` (une chaîne) et `vars.needs_action` (un booléen) indépendamment.
Vous pouvez également utiliser la **Sorties** section de la tâche pour publier des valeurs nommées supplémentaires après l’exécution du script. En pratique, les cartes et les sorties explicites sont le modèle le plus simple à examiner, restaurer et dépanner plus tard.
### Exemple
Une équipe d’exploitation qui surveille des capteurs de vibration classe les relevés avant de les router via une passerelle :
```cel
{"severity": vars.value > 90 ? "critical" : vars.value > 70 ? "warning" : "normal"}
```
La Passerelle exclusive en aval vérifie ensuite `vars.severity == "critical"` sur une branche et `vars.severity == "warning"` sur une autre, avec une branche par défaut pour les relevés « normal » qui mène à un End Event.
***
## Passerelle exclusive
La Passerelle exclusive est un point de décision. Elle évalue les conditions sur ses flux sortants et dirige l’exécution vers exactement **une** branche — la première dont la condition est vraie. C’est un routage XOR : un seul et unique chemin est emprunté.
### Apparence visuelle
Une forme de losange.
### Quand l’utiliser
* Orienter vers différentes actions selon un seuil (au-dessus vs en dessous)
* Faire une branche selon une classification de gravité (critique, avertissement, normal)
* Vérifier si les données enrichies modifient la décision
* Fournir un chemin de repli par défaut lorsqu’aucune condition spécifique ne correspond
### Panneau de propriétés
Cliquez sur la Passerelle exclusive sur le canevas pour ouvrir son panneau de propriétés. En haut, un message indique : *« Les conditions sont évaluées séquentiellement (de haut en bas). La première condition satisfaite exécute son flux, et toutes les conditions restantes sont ignorées. »*
**Nom** — Un champ texte pour l’étiquette du nœud. Texte indicatif : *p. ex. MSG Smoke*.
**Flux** — Une liste de toutes les connexions sortantes de cette passerelle. Chaque élément de flux affiche :
| Élément | Description |
| --------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Poignée de déplacement** | Réorganisez les flux par glisser-déposer. L’ordre détermine la priorité d’évaluation — la première condition correspondante l’emporte. |
| **Numéro de flux** | « Flux 1 », « Flux 2 », etc. Si ce flux est le flux par défaut, une étiquette « Flux par défaut » apparaît. |
| **Nom système** | Un champ texte pour l’identifiant interne du flux. |
| **Libellé** | Un champ texte pour l’étiquette affichée sur la flèche du canevas. Masqué pour le flux par défaut. |
| **Couleur** | Un sélecteur de couleur pour distinguer visuellement les branches sur le canevas. Masqué pour le flux par défaut. |
| **Condition (Expression)** | Une expression CEL qui doit évaluer à `vrai` pour que ce chemin s’exécute. Texte indicatif : *p. ex. vars.value > 10*. Masqué pour le flux par défaut. |
| **Définir comme flux par défaut** | Un bouton qui désigne ce flux comme chemin de repli. Info-bulle : *« Choisissez l’une des conditions pour servir de chemin de repli lorsque toutes les autres conditions sont Fausses. »* |
| **Supprimer** | Supprime le flux. Une boîte de dialogue de confirmation avertit : *« Cela supprimera également la connexion correspondante sur le canevas. »* |
Lorsque vous modifiez quel flux est le flux par défaut, un avertissement apparaît : *« Lors de la modification du flux par défaut, le champ Condition sera définitivement supprimé du flux défini comme défaut. »* Le flux précédemment défini par défaut récupère son champ Condition.
Si la passerelle n’a encore aucune connexion sortante, la section Flux affiche un état vide : *« Tracez des connexions depuis cette passerelle sur le canevas pour ajouter des flux. »* Vous devez d’abord tracer des connexions sur le canevas — les flux ne peuvent pas être ajoutés uniquement depuis le panneau de propriétés.
**Entrées** — Facultatif. Même structure que la section Entrées du Start Event (nom, type, expression CEL, + Ajouter une entrée).
**Sorties** — Facultatif. Même structure que la section Sorties du Start Event (nom, type, expression CEL, + Ajouter une sortie).
**Enregistrer / Annuler** — En bas du panneau.
### Ai-je besoin des paramètres d’entrée et de sortie ?
Non. Les deux sont facultatifs, et une passerelle qui vérifie simplement si une valeur est au-dessus d’un seuil n’a besoin d’aucun des deux — laissez-les vides et écrivez `vars.value > 70` directement dans la condition du flux.
Utilisez-les lorsqu’une condition serait autrement longue, ou lorsque vous répétez le même calcul sur plusieurs flux.
**Une entrée** calcule une valeur avant que la passerelle ne décide et lui donne un nom court que les propres conditions de flux de la passerelle peuvent utiliser. Pour convertir une mesure en Celsius une seule fois et la comparer deux fois, ajoutez une entrée :
| Champ | Valeur |
| --------------- | ----------------------------- |
| Nom de l’entrée | `tempF` |
| Expression | `vars.temperature * 1.8 + 32` |
Écrivez ensuite les conditions du flux comme `vars.tempF > 158` et `vars.tempF > 104` au lieu de répéter la conversion dans chacune.
Une entrée appartient à la passerelle sur laquelle vous l’avez définie. Les nœuds ultérieurs ne peuvent pas la lire.
**Une sortie** fonctionne à l’inverse. Elle est évaluée après la sélection de la branche et écrit son résultat dans les variables de la règle, afin que les nœuds plus loin puissent l’utiliser — un message d’alarme peut faire référence à `vars.tempF` même si la conversion a eu lieu à la passerelle.
Il en va de même partout où les Entrées et les Sorties apparaissent : une entrée est une aide pour le nœud que vous configurez, une sortie est la manière dont ce nœud transmet quelque chose.
### Comment fonctionne l’évaluation des conditions
Les conditions sont évaluées **de haut en bas** dans l’ordre de la liste des Flux. La première condition qui renvoie `vrai` est le chemin emprunté. Toutes les conditions restantes sont ignorées, qu’elles soient également vraies ou non.
Le flux par défaut n’a pas d’expression de condition. Il s’exécute uniquement lorsque **toutes les autres conditions renvoient false**. Chaque Passerelle exclusive devrait avoir un flux par défaut — sans lui, si aucune condition ne correspond, l’exécution de la règle s’arrête sur cette branche.
Le flux par défaut couvre le cas où rien ne correspond. Il ne couvre pas une condition qui échoue à s’évaluer : si une expression ne peut pas être évaluée — généralement parce qu’elle référence une variable que la règle n’a pas, ou renvoie autre chose que `vrai`/`false` — la passerelle s’arrête là et la règle ne va pas plus loin sur ce chemin. Lors d’une session de débogage, la passerelle est contourée en rouge ; voir [Débogage des règles](/kilo-docs-fr/kilo-iot-server/rules-engine/debugging-rules.md#what-the-markers-on-the-canvas-mean).
Une passerelle doit aussi effectuer une branche ou une fusion : donnez-lui deux flux sortants ou plus pour prendre une décision, ou deux flux entrants ou plus pour réunir des chemins. Une passerelle avec un flux entrant et un flux sortant est rejetée lorsque vous construisez la règle — reliez plutôt directement ces deux nœuds.
### Exemple
Une règle de taux d’humidité d’entrepôt utilise une Passerelle exclusive avec trois flux :
| Flux | Condition | Mène à |
| ---------------------- | ----------------- | ---------------------------------------------------- |
| Flux 1 — Critique | `vars.value > 85` | Définir une alarme (dépassement critique d’humidité) |
| Flux 2 — Avertissement | `vars.value > 70` | Définir une alarme (alerte d’humidité) |
| Flux 3 — Par défaut | *(aucune)* | End Event (aucune action) |
Parce que les conditions sont évaluées de haut en bas, un relevé de 90 % correspond au Flux 1 et ignore le Flux 2. Un relevé de 75 % échoue au Flux 1, correspond au Flux 2. Un relevé de 60 % échoue aux deux et bascule vers le flux par défaut.
***
## Définir une alarme
Le nœud Définir une alarme déclenche une alarme sur la base d’une définition d’alarme préconfigurée. Lorsque l’exécution atteint ce nœud, il crée un événement d’alarme qui lance la politique d’escalade, envoie des notifications via les canaux configurés et apparaît dans la boîte de réception des alarmes.
### Apparence visuelle
Un rectangle aux coins arrondis avec une icône de cloche dans le coin supérieur gauche.
### Quand l’utiliser
* Déclencher une alerte critique lorsqu’un relevé de capteur franchit un seuil dangereux
* Déclencher une alarme d’avertissement qui notifie l’équipe des opérations par e-mail et SMS
* Générer des alarmes avec des messages dynamiques qui incluent les valeurs réelles du capteur
### Prérequis
Avant de pouvoir utiliser un nœud Définir une alarme, vous devez disposer d’au moins une **Définition d’alarme** configurée dans la section Alertes. Les définitions d’alarme spécifient le niveau de gravité, les étapes d’escalade, les canaux de notification et les politiques de destinataires. Le nœud Définir une alarme référence une définition existante — il n’en crée pas une.
Voir [Alerting opérationnel](/kilo-docs-fr/kilo-iot-server/alarm.md) pour savoir comment créer et gérer les définitions d’alarme.
### Panneau de propriétés
L’en-tête du panneau indique **« Définir une alarme »** avec le sous-texte : *« Sélectionnez une alarme. Une nouvelle alarme peut être créée sur la page Alarmes. »* Le terme « page Alarmes » renvoie à la section [Alertes et notifications](/kilo-docs-fr/kilo-iot-server/alarm.md) section.
| Champ | Description |
| ------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Nom** | Un champ texte pour l’étiquette du nœud. Exemple : « Déclencher une alarme critique ». |
| **Choisir une alarme** | Une liste déroulante d’autocomplétion consultable. Répertorie les définitions d’alarme existantes dans votre organisation. Recherchez par nom d’alarme pour trouver la définition dont vous avez besoin. |
| **Message de motivation** | Un champ d’expression CEL multiline (3 lignes). Texte indicatif : `« La température est de " + string(vars.temp) + " degrés"`. L’expression doit évaluer une chaîne — ce texte est joint à l’événement d’alarme, fournissant aux intervenants un contexte sur ce qui a déclenché l’alarme et pourquoi. |
**Entrées** — Une liste de paramètres d’entrée. Chaque entrée comporte un nom, un indicateur de type (verrouillé sur « Expression ») et un champ d’expression CEL. Ajoutez des entrées avec **+ Ajouter une entrée**. Supprimez-les avec le bouton de suppression.
**Sorties** — Même structure que les Entrées, avec son propre **+ Ajouter une sortie** bouton.
**Enregistrer / Annuler** — En bas du panneau.
### Exemples de message de motivation
Le message de motivation est une expression CEL, vous pouvez donc y intégrer des valeurs de capteur en direct et des variables calculées :
```cel
« La température " + string(vars.value) + " degrés dépasse le seuil de sécurité »
```
```cel
« Relevé d’humidité de " + string(vars.value) + "% dans la zone A — au-dessus du niveau " + string(vars.severity) + " »
```
```cel
« Concentration de CO2 à " + string(vars.value) + " ppm, dépassant la limite de " + string(vars.value - 800) + " ppm »
```
### Ce qui se passe lorsque le nœud s’exécute
1. Un événement d’alarme est créé avec la gravité et la configuration de la définition d’alarme sélectionnée
2. L’expression du message de motivation est évaluée et jointe à l’événement
3. La politique d’escalade de l’alarme démarre — les notifications sont envoyées via les canaux et aux destinataires définis dans la définition d’alarme
4. L’événement d’alarme apparaît dans la boîte de réception des alarmes pour le suivi et la résolution
Le nœud Définir une alarme ne **pas** définit lui-même la gravité, les canaux, les horaires ou l’escalade. Tout cela provient de la définition d’alarme sélectionnée. La règle décide **quand** déclencher ; la définition d’alarme décide **comment** cette alarme est traitée.
### Exemple
Une règle de surveillance environnementale d’une salle serveur atteint le nœud Définir une alarme lorsque la température dépasse 35 degrés Celsius. Le nœud est configuré avec une définition d’alarme nommée « Surchauffe salle serveur » (gravité : Critique, escalade : SMS à l’ingénieur d’astreinte immédiatement, e-mail au responsable du site après 5 minutes). Le message de motivation est le suivant :
```cel
« La température de la salle serveur est de " + string(vars.value) + " degrés — intervention immédiate requise »
```
***
## Exécuter la commande
Le nœud Exécuter une commande envoie une commande à un appareil lorsque la règle l’atteint — l’action qui permet à une règle de contrôler du matériel, et pas seulement de le signaler. Il envoie l’une des [Commandes des appareils](/kilo-docs-fr/kilo-iot-server/devices/commands.md) commandes prédéfinies d’un appareil comme un downlink, afin qu’une règle puisse fermer une vanne, pousser un point de consigne ou commuter un relais automatiquement dès que ses conditions sont remplies.
Pour le flux de travail complet, les exemples et le modèle agir-et-alerter, voir [Exécution de commandes d’appareils](/kilo-docs-fr/kilo-iot-server/rules-engine/running-device-commands.md). Cette entrée couvre les champs du nœud.
### Apparence visuelle
Un rectangle aux coins arrondis avec une icône de commande dans le coin supérieur gauche. Il se trouve dans le même groupe d’activité que Définir une alarme et Enrichissement.
### Quand l’utiliser
* Fermer une vanne, commuter un relais ou arrêter une pompe dès qu’un seuil est franchi
* Envoyer un nouveau point de consigne à un contrôleur en réponse à un relevé
* Définir une valeur proportionnellement — par exemple, une vitesse de ventilateur dérivée de la température mesurée
### Prérequis
L’appareil cible doit être **pilotable** (MQTT, ou un appareil LoRaWAN de classe C) et doit déjà avoir **au moins une commande définie** dans son **Commandes et états** onglet. Le nœud exécute des commandes existantes ; il n’en crée pas. Voir [Créer des commandes](/kilo-docs-fr/kilo-iot-server/devices/commands/creating-commands.md).
### Panneau de propriétés
| Champ | Description |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Nom** | Un champ texte pour l’étiquette du nœud. S’il est laissé vide, il se remplit avec le nom de la commande sélectionnée. Exemple : « Fermer la vanne d’admission ». |
| **Appareil** | Une liste déroulante d’autocomplétion consultable affichant les appareils de votre organisation. Sélectionne l’appareil auquel la commande est envoyée. |
| **Commande** | Une liste déroulante d’autocomplétion des commandes définies de l’appareil choisi. Désactivée jusqu’à ce qu’un appareil soit sélectionné. |
| **Paramètres** | Une ligne par paramètre attendu par la commande sélectionnée. Chaque paramètre est fourni sous forme de littéral **Valeur** (validé selon le type et l’intervalle du paramètre) ou une **Expression CEL** (évaluée à l’exécution, avec `vars` disponible). |
| **Entrées / Sorties** | Expressions CEL nommées facultatives pour une structuration avancée des données, selon le même schéma que les autres nœuds. |
**Enregistrer / Annuler** — En bas du panneau. L’enregistrement est désactivé jusqu’à ce qu’un appareil et une commande soient tous deux sélectionnés et que chaque paramètre soit valide.
### Ce qui se passe lorsque le nœud s’exécute
1. Chaque paramètre est résolu — les littéraux tels quels, les expressions évaluées par rapport au `vars`.
2. La commande est transmise à l’appareil en tant que liaison descendante (MQTT ou LoRaWAN), exactement comme le ferait une exécution manuelle.
3. L’envoi est consigné dans l’historique d’exécution de l’appareil avec son résultat (En attente, Confirmé, Livré, Avertissement mineur ou Échec). Toute vérification configurée sur la commande s’applique également ici.
Associez un nœud Exécuter la commande à un [Événement d’erreur de bordure](#boundary-error-event) lorsqu’un envoi échoué doit quand même parvenir à une personne via un chemin de repli.
### Exemple
Une règle de détection de fuite associe son événement de début à un capteur de fuite. Une porte exclusive achemine une lecture « fuite détectée » vers un nœud Exécuter la commande qui envoie une `fermer` commande à la vanne d’arrêt d’eau, suivie d’un nœud Définir l’alarme qui déclenche une alarme critique. L’eau est arrêtée automatiquement, et l’équipe est informée que cela s’est produit.
***
## Enrichissement
Le nœud Enrichissement récupère la lecture la plus récente d’un autre capteur. Cela vous permet de prendre des décisions basées sur des données provenant de plusieurs capteurs dans une seule règle, sans avoir à créer des règles séparées pour chacun d’eux.
### Apparence visuelle
Un rectangle arrondi avec une icône de téléchargement dans le coin supérieur gauche.
### Quand l’utiliser
* Comparer une lecture de température intérieure à la température extérieure actuelle
* Vérifier un capteur d’humidité avant de décider si une hausse de température est préoccupante
* Mettre en corrélation une lecture de CO2 avec un capteur de présence pour déterminer si des niveaux élevés sont attendus
* Vérifier un capteur de référence avant de déclencher une alarme
### Panneau de propriétés
L’en-tête du panneau indique **« Enrichissement des données »** avec le sous-texte : *« Joindre les métadonnées pertinentes aux données de l’appareil entrantes avant le traitement. »*
| Champ | Description |
| ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| **Nom** | Un champ texte pour l’étiquette du nœud. Espace réservé : *par ex., Joindre la température de la pièce aux données du capteur*. |
| **Appareil** | Liste déroulante d’autocomplétion consultable. Répertorie tous les appareils de votre organisation — le même modèle de sélection que pour l’événement de début. |
| **Capteur** | Liste déroulante filtrée. Désactivée jusqu’à ce qu’un appareil soit sélectionné. Affiche uniquement les capteurs appartenant à l’appareil choisi. |
| **Variable de sortie** | Un champ texte pour le nom de la variable sous laquelle les données récupérées sont stockées. Espace réservé : *Métadonnées utilisateur*. Une fois le nœud exécuté, le résultat est disponible en tant que `vars.`. |
**Entrées** — Une liste de paramètres d’entrée. Chaque entrée comporte un nom, un indicateur de type (verrouillé sur « Expression ») et un champ d’expression CEL. Ajoutez des entrées avec **+ Ajouter une entrée**. Supprimez-les avec le bouton de suppression.
**Sorties** — Même structure que les Entrées, avec son propre **+ Ajouter une sortie** bouton.
**Enregistrer / Annuler** — En bas du panneau.
### Structure des données enrichies
Une fois le nœud Enrichissement exécuté, la lecture récupérée est disponible en tant que `vars.` avec la structure suivante :
| Propriété | Contenu |
| ----------------------------------- | ----------------------------------------- |
| `vars..sensor_id` | L’identifiant du capteur |
| `vars..value` | La valeur de la lecture la plus récente |
| `vars..type` | Le type de données du capteur |
| `vars..timestamp_ms` | Horodatage de la lecture en millisecondes |
Par exemple, si le nom de la variable est `outdoor_temp`, les nœuds en aval peuvent faire référence à `vars.outdoor_temp.value` pour obtenir la lecture la plus récente de la température extérieure.
### Gestion des erreurs
Le nœud Enrichissement peut échouer si le capteur cible est hors ligne, n’a jamais envoyé de rapport ou est inaccessible. Associez toujours un nœud Enrichissement à un **Événement d’erreur de bordure** (voir ci-dessous) pour gérer ces échecs avec élégance. Sans gestion des erreurs, un enrichissement échoué arrête ce chemin d’exécution.
### Exemple
Une règle de surveillance d’un centre de données compare la température ambiante à l’intérieur d’une salle de serveurs avec le capteur de température extérieure du bâtiment. Le nœud Enrichissement récupère les données du capteur extérieur dans une variable appelée `external_temp`. Une tâche de script en aval calcule l’écart :
```cel
{"temp_delta": vars.value - vars.external_temp.value}
```
Une porte exclusive vérifie ensuite si `vars.temp_delta > 15` — un écart important pourrait indiquer une défaillance du système CVC, car la température intérieure augmente indépendamment des conditions extérieures.
***
## Événement d’erreur de bordure
L’événement d’erreur de bordure est un gestionnaire d’erreurs qui se rattache à un nœud de tâche. Si la tâche à laquelle il est attaché échoue pendant l’exécution, l’événement d’erreur de bordure capture l’échec et oriente l’exécution vers un chemin de repli au lieu de mettre fin à la règle.
### Apparence visuelle
Un petit cercle avec une icône d’éclair, positionné sur le bord du nœud de tâche auquel il est attaché. Il se trouve sur la bordure du nœud parent plutôt que comme un élément autonome sur le canevas.
### Quand l’utiliser
* Un nœud Enrichissement récupère les données d’un capteur qui pourrait être hors ligne
* Une tâche de script évalue une expression qui dépend de données facultatives
* Un nœud Définir l’alarme fait référence à une définition d’alarme qui a peut-être été désactivée
* Toute tâche dont l’échec doit déclencher une réponse spécifique plutôt que rester sans effet
### Comment l’attacher
Faites glisser un événement d’erreur de bordure depuis la palette et déposez-le sur un nœud de tâche existant (Tâche de script, Définir l’alarme ou Enrichissement). Il s’accroche au bord de ce nœud. Tracez ensuite une seule connexion sortante depuis l’événement d’erreur de bordure vers le chemin de repli — généralement un autre nœud Définir l’alarme, une tâche de script qui journalise le contexte de l’échec, ou un événement de fin.
### Règles
* Un événement d’erreur de bordure doit être attaché à un nœud de tâche. Il ne peut pas exister comme nœud autonome sur le canevas.
* Il doit avoir exactement **une** un flux sortant.
* Il ne peut pas avoir de flux entrants (autres que son attachement implicite à la tâche parente).
### Panneau de propriétés
| Champ | Description |
| ----------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Nom** | Un champ texte pour l’étiquette du nœud. Par défaut : « Erreur ». Exemple : « Repli capteur hors ligne ». |
| **Code d’erreur** | Un champ texte. Espace réservé : *Indiquez le code d’erreur ici*. Utilisé pour l’étiquetage et l’annotation dans l’éditeur — voir la mise en garde ci-dessous. |
| **Message** | Un champ texte multiligne (3 lignes). Espace réservé : *Saisissez ici le message d’erreur*. Utilisé pour l’étiquetage et l’annotation dans l’éditeur — voir la mise en garde ci-dessous. |
**Entrées / Sorties** — Le panneau des propriétés peut afficher des champs Entrée et Sortie sur l’événement d’erreur de bordure. Cependant, le moteur d’automatisation ne traite pas les Entrées ou Sorties sur ce type de nœud. Si vous devez transformer des données ou publier des valeurs sur le chemin d’erreur, ajoutez des Entrées et Sorties au **nœud en aval** auquel le flux sortant de l’événement de bordure se connecte — par exemple, la tâche de script de repli, Définir l’alarme ou l’événement de fin.
**Enregistrer / Annuler** — En bas du panneau.
**Mise en garde importante :** Les champs Code d’erreur et Message sont des champs d’étiquetage et d’annotation dans l’éditeur. Ils ne permettent pas de correspondance sélective à l’exécution par code d’erreur. Le moteur achemine **toutes** les erreurs de la tâche attachée via l’événement de bordure, quel que soit le code saisi. Le comportement principal pris en charge est le chemin de repli lui-même : lorsque la tâche attachée échoue pour quelque raison que ce soit, le chemin d’erreur s’exécute au lieu d’arrêter silencieusement cette branche.
### Exemple
Une règle de conformité multi-capteurs enrichit les lectures intérieures avec un capteur de référence extérieur. Le nœud Enrichissement pour le capteur extérieur a un événement d’erreur de bordure attaché. Si le capteur extérieur est injoignable :
1. L’événement d’erreur de bordure capture l’échec
2. Son flux sortant mène à un nœud Définir l’alarme configuré avec une définition d’alarme « Capteur hors ligne »
3. L’équipe des opérations reçoit une notification indiquant que le capteur de référence extérieur ne remonte pas de données, elle sait donc que la comparaison de conformité n’a pas pu être effectuée
Sans l’événement d’erreur de bordure, l’échec de l’enrichissement arrêterait silencieusement ce chemin d’exécution — et l’équipe ne saurait pas que le capteur était hors ligne.
***
## Connexions (flux de séquence)
Les connexions sont les flèches entre les nœuds sur le canevas. Elles définissent l’ordre d’exécution — les données circulent le long de ces flèches d’un nœud au suivant.
### Tracer des connexions
Utilisez l’ **outil de connexion global** depuis la palette, ou survolez un nœud source jusqu’à ce que les poignées de connexion apparaissent, puis faites glisser de la source vers le nœud cible.
### Règles de connexion
| Règle | Détails |
| -------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------- |
| **Événements de début** | Un flux sortant. Aucun flux entrant. |
| **Événements de fin** | Aucun flux sortant. Un ou plusieurs flux entrants. |
| **Nœuds de tâche** (Tâche de script, Définir l’alarme, Exécuter la commande, Enrichissement) | Un flux sortant. Un flux entrant (ou une pièce jointe d’événement d’erreur de bordure). |
| **Portes exclusives** | Un flux entrant. Plusieurs flux sortants (un par branche). |
| **Événements d’erreur de bordure** | Exactement un flux sortant. Aucun flux entrant (attaché implicitement au parent). |
### Conditions sur les flux des portes
Chaque flux sortant d’une Porte exclusive — à l’exception du flux par défaut désigné — doit avoir une expression de condition CEL. Ces conditions doivent être évaluées à booléen (`vrai` ou `false`).
Le flux par défaut doit **pas** avoir une condition. Il ne s’exécute que lorsque toutes les autres conditions sont évaluées à faux.
Si vous créez un flux à partir d’une porte sans définir de condition, l’étape de génération le signalera comme une erreur et la règle ne sera pas générée avec succès.
### Étiquettes et couleurs des flux
Les flux issus des portes exclusives peuvent avoir des étiquettes et des couleurs (configurées dans le panneau des propriétés de la porte). Utilisez-les pour rendre les diagrammes complexes lisibles en un coup d’œil — par exemple, étiquetez une branche « Critique » en rouge et une autre « Avertissement » en ambre, avec la branche par défaut « Normal » en vert.
---
# 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/node-reference.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.
