Le DANS programme une tache dans la cron, la reprogrammer la remplace
Donc ta boucle n’est aucunement arrétée, elle se déroule et reprogramme 5 fois la même CRON
Au final au bout de 5minutes les actions mises dans le DANS seront exécutées, une seule fois car il n’y a pas 5 CRON
par contre dans ce cas il faut que je rajoute des conditions dans le bloc « si » de mon scénario afin que seul la dernière partie (la gestion du départ) soit lancé, et non le début ? ou je peux le géré d’une autre façon (je voudrait éviter deux scénario, toujours pour la simplicité)
Peut être via une variable qui ce met à un une fois le début du scénario déjà exécuté, que je rajoute dans ma condition du premier bloc ? pour n’exécuter que le second au prochain lancement ?
Car le scénario complet ressemble à ça
@anon53349806
Merci pour l’info, je n’avais pas subtilité du bloc « dans »
De toute façon ma boucle est foireuse dés le début, car dans ma têtes ça faisait
à 5h30 : dans 5mn faire le check
à 5h35 : dans 5mn faire le check
à 5h40 : dans 5mn faire le check
etc etc
Perso je ne suis pas pour le fait de contrôler un statut toutes les x temps pour voir si il a changé ou pas, je trouve que cela alourdit considérablement la charge de la machine et que c’est inutile.
Pour moi une domotique c’est entre autre, déclencher des actions en fonction de l’état d’un truc !
Donc plutot que de faire une boucle et me prendre la tête, je mettrai si pixel 6 Alva statut == 0 en déclencheur et je fais les actions liées a ce chanegment !
Ou tu fais cela dans un scénario dédié ou alors tu utilises les trigger pour connaitre le declencheur du scénario si c’est l’état du scénario ben tu fais tes actions
j’avais reflechie à cette solution, mais par contre je risque d’avoir des déclenchement de ce scénario en journée si elle quitte le domicile non ?
pas si apres le test trigger pour connaitre le declencheur tu ajoutes un SI pour tester la plage horaire !
je connais pas du tout les trigger, faut que je trouve de la doc la dessus, mais ça semble une bonne solution si ça répond à mon besoin
Dans le scénario en déclencheur tu mets pixel 6 Alva statut == 0 donc le statut du téléphone
Ensuite tu crées un bloc SI avec comme test
trigger(pixel 6 Alva statut) == 1 && time_between(time,start,end) donc tu testes si c’est le statut du tél qui a déclenché l’exécution du scénario et tu testes une tranche horaire
ALORS les actions que tu as envie de faire !
Ca te fait un scénario, sans boucle sans rien a tester toutes les x temps
Tu as un scénario qui se déclenche suite à un changement d’état et basta
Je pense que vouloir 1 seul scenario est beaucoup plus complexe que 2 (ou plus) scenarios. Don’t act. Si tu veux 1 seul scenario, ce que je propose (mix des proposition de @anon53349806)
1 - 2 declencheurs :
2 - tu rajoute dans le 1er SI :
...[Evenement (label)] == 'Boulot Sego' && trigger(schedule)
tu supprimes le 1er A (celui de 455) puisque c’est l’heure de lancement du scenario
Ensuite, tu ne garde que le SI de la seconde boucle (suppression des blocs A >> DE >> DANS) et dans le SI tu mets
SI trigger(#[maison][Pixel 6 Alva][Statut]#) && time_between(time,0530,0600)
Explication, tu declenches ton scenario à 455 et si le telephone est absent, et via les fonctions trigger, tu ne lance dans ce cas que telle ou telle partie du scenario
Norbert
après d’un coté si c’est plus simple avec deux scénario, dont l’un qui me permet de géré la présence de façon global, peut être que je peut me tourner vers cette solutions
je vais voir à tester / mettre en place vos deux solutions (ou l’une des deux ^^), et je passerais le sujet en résolue par la suite (ou je continuerais de faire mes remonté de bug ^^)
merci à toi et @anon53349806 pour votre aide en tout cas 
Edit : je ne savais pas qu’on pouvais mettre dans les déclencheurs le « résultat » d’une condition, en plus de la conditions,
je n’ai toujours mis que
#[maison][Pixel 6 Alva][Statut]#
et jamais
#[maison][Pixel 6 Alva][Statut]# == 0
C’est bon savoir en tout cas
Je me permet le double poste, j’ai fait les modifs tel que conseillé par @ngrataloup, c’est vrais que ça simplifie pas mal le scénario déjà
résultat demain
par contre pour ma compréhension personnel sur les trigger (j’ai trouvé un post ici [Tuto] Les déclencheurs de Scénarios : les triggers - Forum Communauté Jeedom et de la doc là https://doc.jeedom.com/fr_FR/core/4.1/scenario, mais ça reste vague dans ma têtes après lecture)
Comment ça marche, quel est l’intérêt principal par rapport à d’autre type de condition, bref, je suis perdu, car j’ai l’impression que ça pourrais m"être utile dans pas mal de mes scénario (idem le « time_between » que je ne connaissait pas, faut que je regarde ou je peut trouver toute ces infos/capacité qu’il me manque)
j’ai l’impression d’avoir découvert la roue, sans savoir comment l’utiliser 
Ca marchera pas, faut que tu mette à la racine (pas dans le 1er SI), le second SI
Concernant les triggers, c’est ce qui lance ton scenario !
Donc c’est typiquement à utiliser lorsque tu as besoin de savoir ce qui a lancer le scenario.
(ici schedule ou une commande). Ca te permet donc d’avoir des actions différenciées en fonction dyu declencheur
Tu peux aussi mettre des conditions. A utiliser par exemple si tu ne souhaites gérer qu’un condition dans ton scenario :
Ex : si tu souhaite lancer une action si quelqu’un est present
declencheur : presence == 1
Contenu : action à lancer
Au lieu de :
déclencheur : présence
Contenu :
Si presence == 1 alors
action à lancer
Autre avantage, dans le premier cas, le scenario est lancé que lorsque la valeur presence est 1
Dans le second cas, le scenario est lancé à chaque changement de valeur de presence
Norbert
Bonjour a tous.
Deux précisions :
C’est exactement cela. Mais comme ici, cela est parfois pas embétant / nécessaire car c’est la dernière action de ton scénario.
Présence via Wifi :
Je n’ai pas de nut donc je sais pas s’il y a le même problème, mais en wifi, il peut y avoir des mini « décrochage » (la connexion passe de 1 à 0 puis 1 en quelque minutes). Pour cela je n’utilise pas l’information directement, mais je passe par un virtuel qui gomme cela (ça fonctionne si bien que je n’ai plus aucun problème de détection de présence, et c’est d’ailleurs pour ça que je suis pas passé aux Nuts. Évidemment le système est moins réactif, c’est la limite…)
Exemple cette nuit :
La présence = 0 (donc l’absence ) est ici décalée de 15 minutes (dans mon utilisation c’est pas ennuyant, mais à savoir). La présence est elle instantanée.
Sinon, pour ton scénario :
Tu peux t’inspirer des proposition faite ici, mais tu peux également simplement :
Bon test !
merci pour l’info, j’ai fait la correction, et c’était logique après réflexion ^^
Ha donc au final avec plusieurs conditions de scénario, je peux lancer tel ou tel bloc d’un scénario en fonction du déclencheur, très pratique ça
idem pour les conditions dans le déclencheur, j’ai justement eu souvent à faire à ce type de problème comme tu l’énonce, donc je rajoutais un « si » dans mon scénario, inutile si je met la conditions dans le déclencheur
j’ai naïvement cru que comme c’était pas proposé via le petit bouton (qui sert à aller chercher l’équipement qui régit la condition), ça n’était pas possible de le rajouter contrairement au scénario qui le propose lors de la sélection manuel
Merci pour l’info (a quand un post qui rassemble tout ce genre de petit détail fort pratique mais bien caché ^^
Je passerais le post en résolue si ok demain en tout cas
@Henri
Merci pour l’info pour le virtuel de présence, 15mn de décalage c’est pas un soucis non plus dans mon cas, et si en plus pas besoin de Nut, c’est parfait (bon faut juste avoir toujours de la batterie dans le téléphone), je vais probablement m’inspire de tes infos pour faire la même chose chez moi
Y’a pas une carte quelques part qui rescence les utilisateur jeedom, j’ai l’impression d’en apprendre tellement en échangeant ici, que ça serait encore mieux autour d’un café ou d’une bière ^^
ça à l’air assez calme de part chez moi ^^
Bon aller, je stop le HS, à demain pour le résultat du scénario
Bon au final le scénario n’a marché qu’a moitié ce matin
La partie qui déclanche sur la base de la programmation est ok
la seconde partie qui gère le départ est KO
le log :
j’ai l’impression que la condition du second « si » ne c’est pas validé
(j’avais modifier le time_beetwen jusqu’à 8h, jour de travail particulier aujourd’hui, mais je pense pas que le soucis vienne de là)
une idée de la cause ?
Edit :
En grattant un peu le forum sur le « time_beetwen », il semblerais qu’il faille plutôt mettre
time_between(#time#,0530,0800)
Dans le testeur d’expression :
avec juste « time »
Donc je pense que mon soucis vient de là (à valider au prochain lancement)
Exact #time# au lieu de time
Norbert
Bonjour
Le #time# est bien l’erreur
Mais juste pour info
Si madame part à 8h01, les lumières resteront allumée toute la journée. Idem si madame oublie sont tel.
S’était l’avantage d’un wait. La condition aurait forcément finis par être validée (par dépassement du temps max) et les lumières, dans tout les cas, se seraient éteintes…
il est prévu à terme que je gère la présence autrement, pour le moment je remonte mon jeedom, nouveau lieux, nouvelle habitude, nouveau scénario, les choses sont amenée à être modifier/affiner dans le futur, pour justement éviter les cas que tu décrit
Si elle part en retard, je pense justement augmenter possiblement de 30mn le délais dans le « time_beetwen », ce qui je l’admet ne résout pas totalement le problème
Je vais voir aussi à terme à coupler ça a du Geofencing (mais toujours soucis en cas d’oublie de téléphone, ce qui vu le métier et la personne, équivaut à oublier ses lunettes, bien embêté sans ^^)
à terme il est prévu que des Nut ou autre produit sois ajouté en plus du wifi du téléphone
logiquement, elle ne devrait pas partir, sans ses clé de voiture ni sont téléphone 
Mais dans tout les cas, la remarque est pertinente c’est sûr
Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.
