J’ai un petit doute dans la construction de scenarios imbriqués :
Je souhaite que le scenario « fermeture volets RDC » se termine et ensuite après un sleep le sous scenario « Fermeture volets Etg » se lance
Le premier sous scenario « Fermeture volets RDC » peut prendre du temps avant de se terminer car la fermeture se fera que si le nb de lux est inférieur à une certaine valeur (avec un wait Image 2), donc la durée est variable.
Bonjour Iperena,
Je pense que mon niveau d’anglais me permet de saisir le sens des mots wait et sleep et avant que tu poses la question j’ai lu la doc :
Attendre (wait) : Attend jusqu’à ce que la condition soit valide (maximum 2h), le timeout est en seconde(s).
Pause (sleep) : Pause de x seconde(s).
Et donc je vais reformuler ma question :
Dans un scénario parent qui exécute deux scénarios de manière séquentielle, l’instruction wait du premier scénario est-elle bloquante pour l’exécution du second ?
Ou plus prosaïquement est ce que le second scenario se lancera uniquement si celui placé avant sera terminé quelque soit sa durée.
J’imagine vu la façon dont il à conçu ses scénarios qu’il veut s’en servir comme « boite à outils » et donc ne pas dépendre d’un ordre précis.
Peut être que dans un autre scénario, il ferme les volets de l’étage puis du RDC, ou les deux en même temps
Avec le temps et l’expérience sur jeedom j’ai tendance à faire un peu pareil : un scénario principal qui orchestre des scénarios satellites que je peux appeller indépendamment si besoin.
J’ai bien compris, chacun fait comme il veut… ou comme il peut.
Pourquoi faire simple quand on peux faire compliqué ! ? !
Vu la deuxieme copie ecran, faire tourner un scenario qui attends (wait) toute la journée que la lumière passe en dessous du seuil fixé ne me parait pas le plus judicieux…
Présenté comme ça, ça ne me parait pas judicieux non plus.
Mais ce n’est pas comme ça que je comprends que ça fonctionne.
Déjà ça ne peut pas attendre la journée car la durée max d’un wait est de 2h
Et on voit dans la copie d’écran qu’il à mis 1500s soit 25 minutes.
Il veut d’abord fermer les volets du RDC, en attendant un peu (25 minutes max) si il ne fait pas encore nuit puis une fois ces volets fermés, fermer ceux de l’étage.
Au final ça ne me choque pas : ça permet de décomposer en plusieurs scénarios pouvant être lancés indépendamment une action tout en permettant de faire comme si tout avait été lancé depuis un seul et unique scénario.
Par défaut quand on fait des Démarrer de scénarios depuis un autre, ils s’exécutent à la suite sans attendre que le précédent ait terminé de s’exécuter, cette méthode en faisant un Démarrer (sync) permet de faire comme si tout était fait à la suite dans un seul scénario, tout en gardant la souplesse de pouvoir appeler chaque sous élément indépendamment.
Quand c’est techniquement possible pourquoi vouloir s’en priver
Moi aussi j’utilise cette solution donc loin de moi l’idée de se priver de cette option…
Par contre, vu sa demande : fermer les volets Etg après ceux du RDC, … son « Demarrer (sync) » n’est pas placé au bon endroit.
Merci pour tous vos commentaires je trouve toujours cela très instructif et ça fait se poser des questions sur la façon d’organiser les scénarios et soi même se requestionner.
En plus pour éviter de charger mon post je n’ai pas mis l’ensemble et le contexte mais un grand merci, ça fait toujours grandir de lire le ping pong entre experts.
Quelle émulation.
Je vais clôturer ce sujet car après plusieurs jours je confirme que les scenarios fonctionnent comme prévu.
