Exemple d'alarme de température

Exemple d'alarme de température

Cet exemple présente une rulechain simple qui génère une alarme dès qu'une valeur de température dépasse un seuil de 5 °C. Lorsque la valeur retombe à 5 °C ou en dessous, l'alarme est de nouveau supprimée.

Cet exemple permet ainsi de bien comprendre la structure de base d'une rulechain :

• des messages entrent dans la chaîne
• plusieurs nœuds vérifient les conditions étape par étape
• selon le résultat, une alarme est créée ou supprimée

Vue d'ensemble de la règle d'exemple

La rulechain complète se compose de plusieurs nœuds reliés les uns après les autres.

Le déroulement est le suivant :

1. Un message entre dans la rulechain via l'Input.
2. Le nœud Filter Devices vérifie si le message provient de l'un des appareils souhaités.
3. Le nœud Filter Message vérifie si le canal de température souhaité est présent dans le message.
4. Le nœud Temperature Threshold évalue le seuil.
5. Dans le cas True, une alarme est créée.
6. Dans le cas False, une alarme existante est de nouveau supprimée.

Étape 1 : filtrer les appareils

Le premier nœud fonctionnel est le filtre d'appareils.

Ce nœud reçoit :

• un nom
• la sélection des appareils auxquels la règle doit s'appliquer

Dans cet exemple, deux appareils de démonstration ont été sélectionnés. Seuls les messages de ces appareils peuvent poursuivre leur parcours dans la rulechain. Les messages des autres appareils sont bloqués à ce stade.

La règle est ainsi limitée de façon ciblée à un périmètre d'appareils défini.

Étape 2 : vérifier le contenu du message

L'étape suivante vérifie si le message entrant contient le canal de température à contrôler.

Ici :

• un nom est attribué au nœud
• sous Message Data, le canal à vérifier est sélectionné ou saisi manuellement

info

Pour saisir le canal manuellement, il suffit de le taper et de confirmer par la touche Entrée. La saisie manuelle du canal à vérifier est sensible à la casse.

L'option Check that all selected keys are present garantit que seuls les messages contenant effectivement la clé choisie sont transmis.

Si le canal est absent du message, le traitement s'arrête à ce stade.

Étape 3 : vérifier le seuil avec un script

Vient ensuite un nœud de script qui vérifie le seuil proprement dit.

Dans cet exemple, la logique est volontairement simple :

return msg.temperature > 5;

Le script signifie :

• True si la valeur de température est supérieure à 5
• False si la valeur est inférieure ou égale à 5

Le nœud possède en conséquence deux sorties :

• True
• False

La rulechain se divise ainsi, à cet endroit précis, en deux chemins fonctionnels.

remarque

Le nom exact de la variable dans un nœud de script peut varier selon le type de nœud ou le contexte. Pour la logique fonctionnelle de l'exemple, l'essentiel est que la valeur de température soit lue et comparée au seuil.

Étape 4 : créer l'alarme

Lorsque la condition est remplie, le message passe par le chemin True vers le nœud d'alarme.

On définit ici :

• quel type d'alarme doit être créé
• quel niveau de gravité l'alarme possède

Dans l'exemple, une alarme de type Temperature Alarm avec le niveau de gravité Critical est créée.

Des détails supplémentaires pourraient être ajoutés à cet endroit, par exemple :

• la valeur de température actuelle
• des informations supplémentaires calculées
• des métadonnées d'alarme mises à jour

Pour l'exemple de base, le nœud reste volontairement simple.

Étape 5 : supprimer l'alarme

Lorsque la condition n'est plus remplie, le message passe par le chemin False vers le nœud de suppression de l'alarme.

On indique ici quel type d'alarme doit être supprimé. Dans cet exemple, il s'agit du même type :

• Temperature Alarm

Une alarme active est ainsi de nouveau clôturée dès que la température ne dépasse plus le seuil.

Étape 6 : intégrer à la Root Rule Chain

Pour que la nouvelle règle soit effectivement exécutée, elle doit être raccordée à une chaîne de traitement active, c'est-à-dire la règle racine (Root Rule Chain).

Dans l'exemple présenté, la rulechain créée est intégrée après le chemin Save Time Series de la Root Rule Chain. Cela est nécessaire ici parce que la température est envoyée par l'appareil sous forme de canal de données de télémétrie et parvient donc à la Rule Engine par le chemin de télémétrie. Elle est intégrée après le nœud Save Timeseries afin de ne pas interrompre le traitement de base normal. Il en résulte donc :

L'appareil envoie « Temperature » -> « Temperature » est traitée normalement et enregistrée dans la base de données -> Après l'enregistrement dans la base de données, « Temperature » est transmise à la règle d'évaluation d'alarme.

Ce n'est que par cette intégration que la logique créée devient effective dans le système en fonctionnement.

Résultat

Après l'enregistrement et l'activation, la règle fonctionne comme prévu :

• une température supérieure à 5 °C génère une alarme
• une température de 5 °C ou moins supprime de nouveau l'alarme

Mise en perspective

Cet exemple présente une rulechain volontairement simple, mais contient déjà les principaux schémas de base :

• filtre d'entrée
• contrôle des données
• logique conditionnelle
• chemins différents pour True et False
• action basée sur le résultat

Sur cette base, des rulechains plus complexes peuvent également être construites, par exemple pour :

• une alerte à plusieurs niveaux
• des notifications par e-mail ou par d'autres canaux
• le raccordement d'API externes
• la combinaison de plusieurs conditions d'appareils ou de données

Retour à l'introduction générale :

• Notions de base des rulechains