Bonjour,
J’ai créé un scénario pour que, lorsque le nut est détecté par l’antenne BT, le portail s’active.
Pour le coup, ça fonctionne mais trop bien puisqu’il s’ouvre tout le temps.
J’ai désactivé la répétition pour justement éviter qu’il renvoie l’information en continu de sa présence, mais malgré cela le portail est actionné.
J’ai parcouru pas mal de sujets sur ce type de scénario, mais la je sèche 
Merci pour votre aide.
Tu testes 2 nut avec un ou, dc si un change d’etat la.non répétition ne fonctionne pas
Regarde dans ton log on le voit
En fait, le « ou » est lié au fait que l’un des nut est avec moi et l’autre avec ma femme.
Dans mon esprit, il faut que l’un puisse ouvrir si l’autre est absent, mais également s’il est présent.
A part « ou », je ne vois pas ce que je pourrai mettre.
Ou alors faire 2 scénarios distinctes pour chaque nut ?
Bonjour @nakime,
Quelle plugin utilises tu pour détecter ton Nut ? Et tu souhaites que ton portail s’ouvre uniquement lorsque tu viens de l’extérieur, ou aussi quand tu sorts de chez toi ?
J’utilise Theengs gateway et MQTT Discovery.
L’objectif c’est que lorsque j’arrive de l’extérieur le portail s’ouvre, mais pas quand je sors de chez moi.
Dans ce cas c’est exactement comme moi.
En fait il faut faire deux scénarios, un pour ouvrir le portail, et un pour reseter les variables qui vont éviter les faux positifs.
Scénario ouverture portail :
Scénario reset variables :
Les imprim écran ne sont pas complés mais permettent de comprendre la logique.
Je fais aussi un contrôle si le portail est bien fermé avant ouverture car deux commandes de suite le bloque (SOMFY).
Pour l’éclairage utilise plutôt la commande time_between
time_between(#time#, #[Ceyssat][Ceyssat][Crépuscule Civil]#, #[Ceyssat][Ceyssat][Lever du Soleil]#) == 1
A mettre dans un bloc Si comme condition. Dans l’exemple si dessus, si l’heure courante est comprise entre le crépuscule civile et le lever du soleil, alors la valeur du résultat doit être égal à 1.
Salut,
Par resetter les variables, tu veux dire les remettre en « absent » après un certain temps ?
Non, pour les mettre à 0 (absent) sur le Nut qui n’est plus présent dans la propriété.
Je fais aussi un check des variables via un scénario récurent :
Pour résumer :
Au préalable lorsque je quitte la propriété, le tracker qui est avec moi passe en « Absent » et dans ce cas, la variable de celui-ci passe de 1 à 0.
Lorsque je reviens chez moi (l’antenne est au niveau de mon portail), le tracker est détecté et passe en « Présent », le scénario check si la variable du tracker est bien à 0 et si le portail est bien en position fermé (pour éviter le blocage de ce dernier à l’ouverture si double commande car plusieurs trackers comme ma montre en plus de mon Tile dans ma voiture). SI ces conditions sont OK, la variable de ce tracker passe à 1 et le portail s’ouvre.
La variable de ce tracker étant maintenant à 1, je n’aurais pas d’ouverture intempestive tant que le tracker sera présent. Il peut parfois y avoir des déconnexion intempestive du Nut de l’antenne, c’est pour cela que je temporise avec les variables.
SI une déconnexion se fait sur plusieurs minutes, le scénario récurent permet de checker l’état de présence de chaque tracker et remettre les variables à la bonne valeur.
En fait j’ai 5 antennes, une notamment dans le garage et ce système me protège d’un basculement/déconnexion d’une antenne à l’autre. D’autant plus qu’avant j’utilisais BLEA.
Avec cet ensemble de scénario, je peux utiliser plusieurs trackers, et cela marche avec tous les véhicules de la maison, et même à pied (montre).
Autre point, dans ton scénario initial tu mets un bloc Si dans un bloc Action, cela n’est pas nécessaire, et tu avais oublié de mettre aussi le Nut « trombonne » comme déclencheur.
La commande trigger permet de bien dissocier les déclencheurs.
Je fais les tests de tous cela ce soir et te tiens au courant 
Bonjour
Ton problème vient surtout du fait que ton nuts se déconnecte parfois quelques secondes / minutes.
Pour cela, il faut que ton scénario soit activé par un virtuel intermédiaire « présence monsieur »
Présence monsieur est égale à 1 si nuts = 1, mais égale a zero que si nuts vaux zero depuis plus de X minutes.
(C’est comme ça que je gère les presences, car moi aussi, via détection de présence d’un téléphone connecté au wifi, j’avais de petits décrochage)
L’IP d’aujourd’hui (voir toutes les micro coupure la nuit / journée)
Ceci est déjà implémenté dans Theengs Gateway avec l’argument timeout.
La valeur par défaut est de 120 secondes à 2 minutes. Peut-être trop court pour ce que vous voulez.
@Mips - Peut-être un autre argument à ajouter au Plug-In ?
Cela pourrait réduire le besoin de ce type de variable distincte intermédiaire.
Alors j’ai fais les essais et il doit y avoir un loupé.
Déjà, un soucis (mais c’est parce qu’il me reste encore beaucoup de choses à apprendre), c’est que je recopie sans trop comprendre le principe, notamment sur la notion du « log ».
Ensuite, et c’est peut être pour cela que ça ne fonctionne pas, le portail n’a pas de fonction ouverture / fermeture. Il s’agit juste d’un toggle (Module Delta dore sur le moteur). J’aurai donc à penser que comme pas de retour d’état, le scénario n’arrive pas à faire la nuance.
Dans un premier temps, je n’ai pas inclus à la notion de lumière pour éviter que ça s’allume/s’éteint tout le temps et compte tenu du résultat, j’ai désactivé le scénario.
Je vous mets les screenshots pour compléter
La notion de log, c’est juste une information que je mets dans le log du scénario, pas nécessaire. Si cela ne fonctionne pas au début c’est normal car il faut mettre 0 dans les valeurs des deux variables. Pour cela tu fais un simple scénario sans déclencheur, un bloc action avec une action par variable et tu mets la valeur 0 à chaque variable.et tu cliques sur Exécuter pour lancer le scénario :
Ou bien tu fais passer ton (tes) nut en absence, le deuxième scénario fera passer les variables à 0.
Il faudrait regarder les logs de tes scénarios pour comprendre ce qu’il se passe. Il faut sortir de la propriété, attendre environ 2 minutes, se présenter devant le portail (bien relever l’heure), et analyser les logs en se basant sur l’heure relevée.
Désolé, mais je vais passer pour un idiot, mais j’ai du mal à comprendre.
Ce que tu appelles variables, ça va être le changement d’état du nut, c’est bien cela ?
Ce que je ne comprends pas, c’est que si je mets la variable à 0, ça ne va pas déclencher le portail, si ?
Variable c’est lié au changement d’état des nut. Les deux scénarios vont initialiser les variables correspondantes à chaque nut avec comme valeur 0 ou 1 suivant l’état d’absence ou de présence des nut. Elles permettent dans ce cas précis de s’assurer que les nuts sont présents ou non malgré des déconnexions intempestives. Elles permettent de temporiser pour éviter que le portail ne s’ouvre à chaque reprise de connexion des nut.
Comme le scénario d’ouverture interroge la valeur des variables, il faut bien qu’elles soient initialisées dans une valeur lors du premier lancement pour déjà d’une part qu’elles soient existantes. Pour comprendre comment ton scénario se comporte il faut consulter son log lorsque tu test l’ouverture du portail avec le nut. Commence par cela et partage nous ce log pour que l’on puisse t’aider.
Pour fiabiliser mes scénarios, j’ai mis plusieurs antennes TGW. En effet lorsque mes véhicules sont devant la maison ou dans le garage, les trackers situés dans les voitures se déconnectent de l’antenne du portail située à 40 mètres de la maison. Comme cela j’évite les états d’absence alors que mes véhicules sont bien présents.
De ton côté les nut sont peut-être suffisamment près de l’antenne de ton portail quelque soit leur emplacement dans ta propriété et des antennes supplémentaires ne sont alors pas nécessaire. Cependant une deuxième antenne permettrait de fiabiliser l’état de présence lors d’une déconnexion intempestive sur une antenne.
Bonjour
Une variable est une information qui est mémorisée dans ton jeedom, utilisable partout (dans d’autres scénarios, dans les virtuels, etc…) et qui garde sa valeur même quand le scénario est fini.
Dans ton scénario c’est cela
Ps: tu devrais test ma proposition. Mais c’est vrai qu’il faut utiliser un virtuel et donc se lire une autre doc. Mais idem, pour avancer, les virtuels sont super important à bien comprendre.
Je ne vois pas l’intérêt de ces variables. Je trouve cela une mauvaise idée de rajouter cette couche autant d’un point de vue logique (c’est complexe sans apporter de plus value) que technique surtout en utilisant des « variables ».
Il y a déjà tout ce qu’il faut pour « temporiser » l’absence des trackers et éviter les déco non voulue => config à faire sur l’équipement du nut.
