Règle prise en compte alors qu'elle est désactivée (V5)

Bonjour,

Je me suis rendu compte qu’une règle est active alors que celle-ci est Désactivé.

J’ai fait un test en mettant un NOT devant l’événement planning (planning TOR actif de 22h15 à 5h) [et fait la sauvegarde] : la sortie résultat est passé à ON ; enclenchant de fait la marche du cumulus .

PAR CONTRE le mail n’est pas parti !

Une Idée ??

D’avance merci.

Bonne jounrée

Bonjour @tous30
as-tu vérifié si des liens ou autres règles ne viendraient pas se superposer au fonctionnement ? :thinking:

Bonjour @fgtoul

Pour le moment je n’ai rien trouvé. Et rien sur ipxbrouwer .
Mais si la règle qui était activé ailleurs, j’aurai du recevoir les mails.

Merci

Bonne journée

Bonsoir,

J’ai contrôler depuis l’Ipxv5 j’ai rien trouver.
J’ai supprimé cette rule et je l’ai recréé IDEM.
J’ai fait un nouveau contrôle avec Ipxbrowser idem

Je sèche …

Bonne soirée

Bonjour tous30,
dernier test : effacer la règle, ne pas la recréer et attendre un cycle pour voir sir l’ECS s’enclenche.
Dans ce cas @fgtoul a raison sur l’existence de lien ou règle superposée.

Bonne journée

Bonsoir @grocrabe

Je fais cela de suite !

Je ferais un autre test demain.

J’arrête pas de fouiller mais je trouve rien.

Merci

Bonne soirée

Bonjour @tous30
Une règle est composée de deux parties :

  • Un interpréteur d’événements qui interprète les événements qui lui sont soumis et attribue une valeur « On/Off » à la sortie Result de la règle en fonction des conditions paramétrées.

  • Un générateur d’actions qui exécute des actions préalablement définies, sur ordre de l’interpréteur d’événements et sous réserve que la variable Enable soit On.

Dans IpxBrowser, la variable Enable est placée entre les deux parties pour symboliser sa fonction de connexion/déconnexion entre les deux parties et dans la documentation, il est indiqué en 5.2 :

• La variable Enable de la règle indique si la connexion entre l’interpréteur d’évènements et le générateur d’actions est établie (On) ou non (Off).

Activation/désactivation de la règle
Le terme désactivation est donc trompeur, l’interpréteur d’événements étant toujours actif, quel que soit l’état de sa variable Enable. Le résultat est toujours disponible sur la variable Result. Lorsque la variable Enable est à l’état off, le générateur d’actions est simplement déconnecté de l’interpréteur d’événements. La réactivation de la variable Enable réactive seulement la transmission entre les deux parties de la règle et ne génère aucun message vers le générateur d’action. Il n’y a donc pas de mise à jour des variables de sortie.

Précaution lors de l’utilisation de la variable Enable
Lorsque la variable Enable est à Off, l’interpréteur d’événement étant toujours actif, la valeur de la variable Result peut varier est devenir incohérente avec les valeurs des variables pilotées par le générateur d’actions. Lorsque la règle sera réactivée, il faudra attendre une variation du résultat de l’interpréteur d’événement pour que les valeurs des variables pilotées par le générateur d’actions soient, à nouveau, conformes aux valeurs attendues.

Pour ma part, je n’utilise pas la variable Enable des règles à cause de cette désynchronisation potentielle. Pour le filtrage en fonction d’une plage horaire, j’ajoute simplement la variable de sortie d’un calendrier dans les conditions de la règle :

@gce A mon avis, pour rendre exploitable l’Enable des règles, il faudrait que, lors de la réactivation de la règle, les conditions de l’interpréteur d’événement soit rejouées, pour resynchroniser les valeurs des variables gérées par le générateur d’actions.

Autre point connexe : précaution lors de l’utilisation des variables Enable des scènes et des règles
Une scène dispose d’une variable Enable qui agit sur toutes les règles qu’elle contient. Il n’y a pas de hiérarchie entre la validation par la scène ou par la règle : c’est la validation la plus récente qui conditionne la validation d’une règle. Cela a deux effets induits qui peuvent poser problème :

  • Si l’on a désactivé une règle suite à un dysfonctionnement d’un équipement que l’on veut mettre hors service, la désactivation puis la réactivation de la scène réactivera la règle.

  • La désactivation globale des règles par la scène n’empêche pas leurs réactivations individuelles au niveau des règles. Dans ce cas l’état Off de la variable Enable de la scène ne garantit pas que que toutes les règles quelle gère sont réellement désactivées.

Bonne journée

3 « J'aime »

Bonjour @Michel94

Merci pour toute ces précisions.

Cela ne résout pas mon soucis.

Je n’ai toujours pas trouver pourquoi ma règle transmet un ON à la règle suivante desque la sortie calendrier passe à ON .

Encore merci pour ces infos.

Bonne journée

Edit de la réponse :
Rappel
L’interpréteur d’évènement d’une règle est toujours actif et sa sortie Result est toujours alimentée, même si la règle est désactivée (Enable = Off)

Lorsque le calendrier passe à ON, la sortie Result de la règle 1(Cumulus hiver nuit) passe à ON qui est transmis à la règle 116 (Cumulus NUIT).

Comme les événements de cette règle 116 sont liés par une fonction OU :

  • la sortie Result passe à ON qui est transmis à la règle 110 (Marche cumulus).
  • comme la règle est désactivée (Enable = Off), la sortie on/off1 reste figée et aucun mail n’est envoyé.

Comme la règle 110 (Marche cumulus) est active (Enable = ON), la sortie on/off1 vers le relais passe à ON, ce qui active le relais.

Bonne journée

1 « J'aime »

Bonjour @Michel94

Merci pour la clarté de votre réponse.
Je trouve dommage se comportement de la fonction Enable .

Bonne jounrée

Au sujet des règles, je pense qu’il y a deux points à améliorer ou clarifier :

1-Définition de la règle et utilisation du mot result ou résultat :

Dans la documentation de l’Ipx, il est indiqué :

Les règles vous permettent de mettre en relation des événements avec des résultats via un type d’action.

La tuile Rule peut être utilisée en événement seulement.
• La propriété « Enable » peut être utilisée pour subordonner l’exécution de certaines actions
• La propriété « Résultat » peut être utilisée pour conditionner des scènes sans avoir à répéter toute la clause événement


La zone 3 permet de paramétrer le Résultat*

Le mot Result ou Résultat est utilisé indifféremment pour définir, la sortie de la règle, la propriété Result ou la zone de paramétrage des actions de la règle.

Cela créé une confusion entre la propriété Result qui le résultat de l’interpréteur d’évènements et les sorties de la règle qui modifient des valeurs de variables.

*Sémantiquement, sauf lorsqu’il est lié au scrutin d’un pays « démocratique » comme la Russie ou la RDC, un résultat n’est pas paramétrable.
:relieved:

Le mot Result ou Résultat devrait être réservé à la propriété qui indique le résultat de l’analyse de la partie événement.

La zone permettant de définir les actions de la règle devrait être nommée « actions » ou « sortie » et la définition de la règle devrait être simplement :
« Les règles vous permettent de mettre en relation des événements avec des actions. »

Utilisation de la propriété Result

La propriété doit être réservée pour assembler des règles de façon à créer une règle complexe.
Dans le cas de l’exemple indiqué dans le post, la règle 110 Marche Cumulus a une condition composée d’un assemblage de résultats des règles 1,103, 115 et 116 de la forme :
(110evt1 OU 110evt2 OU ((103evt1 ET 103evt2) OU (115 evt1 ET 115evt2) OU 1evt1))

Pour garantir la fiabilité du résultat de cette règle 110, il semble normal que les résultats des règles intermédiaires ne puissent pas être désactivés.

Dans cette logique, pour chaque règle contribuant à une autre règle,

  • La propriété Result est disponible de façon permanente pour ne pas perturber le fonctionnement de la règle principale.
  • Les sorties actions de la règle sont conditionnées à l’activation ou non de la règle par sa propriété Enable

2-Activation/Désactivation de la règle

Comme indiqué dans un post précédent, lors de la désactivation d’une règle puis de sa réactivation, les états des variables pilotées par la règle peuvent être non conforme à la réalité.

Ex : dans le cadre d’une alarme, une règle surveille l’ouverture d’une porte. On souhaite que cette surveillance ne s’effectue que la nuit et pour cela, on désactive la règle durant la journée.

Si la porte est ouverte au moment de l’activation de la règle, aucune information n’est remontée nous indiquant que les conditions de la règle ne sont pas respectée.

C’est pour cela qu’il serait souhaitable, à mon avis, que l’interpréteur d’événement de la règle réinterprète l’état des variables surveillées à chaque réactivation de la règle.

Bon dimanche

2 « J'aime »

Bonjour @Michel94

C’est même plus logique (et intuitif) de remplacer « Result » par « Action » pour l’intitulé de cette partie et de remplacer la valeur ou propriété « Result » par « Etat » ou « State » !

image

C’est même étonnant que cela soit pas le cas :thinking:

image
Le coche « Enabled » pourrait presque être vu ou remplacé par la somme d’une brique 'Rule enabled" ou 'Rule disabled" et d’une brique 'AND" plus les briques suivantes (d’un point de vue logique seulement car fonctionnellement ce serait pas pratique)

1 « J'aime »