Est il possible de faire un « TANT QUE » à la place d’un « SI » dans un scenario JEEDOM ?
Je m’explique, j’ai crée un scénario qui m’envoie une notification quand le soleil tape sur une fenêtre avec des volets bois ( à l’aide d’Héliotrope + température ext et int) et me dis de la fermer. Le problème c’est qu’il m’envoie des motifs toutes les 5 minutes (REFRESH de la station météo). J’aurai souhaité faire un :
« tant que » le soleil tape sur la fenêtre > « fermer les volets » au lieu d’un « SI ».
petit rappel: il faut exprimer le besoin et pas son idée personnelle de la solution
Donc tu veux quoi? ne recevoir la notification qu’une seule fois?
Dans ce cas il suffit de cocher la case de non-répétition de la condition sur le SI
et « tant que » le résultat de la condition ne changera pas il ne re-executera pas le contenu du SI.
Donc il faudra que le résultat revienne à faux puis à vrai pour recevoir une nouvelle notif
Une idée pour faire un tant que est de relancer le scénario si la condition n’est pas bonne…
Ex:
Scénario X:
Si test==1
Alors…
Sinon
Dans y min, démarrer scénario X
Cette option, c’est bien, on obtient le fonctionnement voulu, mais le scénario est tout de même déclenché plein de fois pour rien et les log défilent inutilement. Quel est l’impact en terme de performances de faire ceci sur de nombreux scénarios ?
@Mathatak Il y a la solution de passer passer par un virtuel avec un état « FenetreQuiTape ». L’idée est de changer d’état uniquement si l’état « FenetreQuiTape » était dans un état différent. (Ex, on allume une lumière éteinte ou on éteint une lumière allumée, inutile d’allumer une lumière déjà allumée)
Tu crées 2 scénarios :
1 premier pour activer l’état « FenetreQuiTape » et envoyer une notif
1 second pour désactiver l’état « FenetreQuiTape »
Dans le déclencheur du scénario qui active, tu rajoutes la condition « FenetreQuiTape » == 0
et inversement, dans le déclencheur du scénario qui désactive, tu rajoutes la condition « FenetreQuiTape » == 1.
Ainsi, les scénarios se déclencheront exactement qu’une seule fois aux bons moments.
Mettre à jour un virtuel est plus « lourd » que déclencher un scénario, la mise à jour d’une commande info (de virtuel ou pas) va relancer le check de scénario; et la maintenance encore plus de boulot.
En fait il y a bien plus simple ici si le but est juste de notifier (une fois) en cas de « dépassement » d’une valeur: ce sont les actions sur valeur dans la config avancé de la commande, exemple:
Ok, c’est plus lourd à mettre en place, certes, mais c’est fiable.
Pour le check du scénario, dans tous les cas, il y en a un.
Donc, autant ne pas avoir de déclenchement inutile dans les log.
Là, on retourne au problème initial, une notif à chaque changement de valeur.
Pour un état binaire, on peut encore cocher « Ne pas répéter la valeur ». Mais pour une température, il y aura une notif à chaque changement de valeur.
Ici il y aura donc un deuxième, je te garanti que multiplier les virtuel ce n’est pas le bon conseil.
Non pas du tout.
Si on choisit de déclencher l’action des que la valeur est < que, l’action sera déclenchée quand on passe le seuil et uniquement quand on passe le seuil.
Pas à chaque changement de valeur en dessous du seuil.
Bonjour, je fais suite à votre discution et je note:
Perso je passe tous mes équipements Zwave, zigbee ext sur des virtuels pour séparer la partie plugin (connecteur) du reste, je pensais à tors que c’était une bonne pratique.
Si je comprend bien le probléme ici c’est que les valeurs infos sont mises à jour sur tous les tableaux (plugin et virtuel) et cela charge la box juste?
Voilà, cela double purement et simplement la charge.
Je suis bien conscient que c’est ce qui est souvent conseillé, je pense que cela apporte plus de désavantages pour zéro réel gain.
Zero gain car il est utopique de penser qu’il sera plus facile de changer le module physique parce qu’on a créé un virtuel au dessus.
En plus de la charge je trouve que cela complexifie vraiment la maintenance.
Ceci étant dit, « chacun trouve chaussure à son pied » et je respecte cela mais je ne peux que le déconseiller.