Pendant les canicules, les volets sont fermés la journée. J’ouvre les volets lorsque la température extérieur se rapproche de la température intérieure. Pour cela,
je fais une boucle de 60 itérations qui compare les températures et ouvre les volets si la différence entre les deux est inférieure à 2,5°. Si cette différence n’est pas attente, je fais un wait de 5 minutes (300sec).
Normalement, la boucle devrait s’executer pendant 5 heures.
Cependant dans les logs, la boucle ne dure qu’une heure sans que le résultat ne soit atteint :
En fait, je pense que le scénario est pas concu de façon optimale. Il faudrait revoir la logique denton wait.
Pourquoi attendre 5min dans le scénario alors que les cron ou Dans sont fait pour cela. Voir cette discussion par exemple :
Merci pour ta réponse rapide !
oui en effet je pense que c’est pas optimal ; j’avais concu cette boucle à mes débuts en domotique et ça mériterai peut être une évolution …
peut être en jouant avec deux scénarios :
A l’heure d’ouverture des volets des chambres, j’execute un scénario enfant.
dans ce scénario
Boucle de 1 à 60
—> Dans 5 minutes
Tester temperature. Si température OK, alors
Ouvre les volets
Remove_inat et Arrêt du scénario
Sinon
Il se passe rien et le Dans fera le job dans 5 minutes.
Je ne connais pas trop les boucles. En fait, je préfère les éviter dans un scénario.
Pour mes volets, je fais au plus simple. En hiver, j’ouvre, en été j’ouvre à minima. Il est rare d’avoir trop chaud en hiver et réciproquement trop froid en été.
Puis les réglages fins sont morts, dès que la famille utilise la pièce.
Intéressants vos réponses, mais je trouve que la fonction boucle est limité.
Est ce que je peux faire de la programmation évènementielle complexe ?
car le SI dans ma boucle est le suivant :
SI
#[Températures][Sonde Nord][Température]# - 2.5 < max(#[Températures][Sonde Chambre AA][Température]#,#[Températures][Sonde Salle de bain][Température]#)
ALORS
peut être en utilisant une variable liée à ce test ?
En fouillant le forum, j’ai trouvé un autre article ou mich0111 tu propose de faire :
mich0111
Tu peux par exemple faire un scénario qui contient un bloc A qui après son action relance le même scénario.
Le bloc A pouvant avoir pour paramètre une variable.
je vais essayer de voir si ça repond à mon besoin.
merci!
Ce modèle ne fonctionne pas car le DANS possède un seul ID ; et non un ID par boucle.
Par conséquent, la BOUCLE execute le même DANS qui est reporté (dans mon cas, de minutes en minutes).
==> pas concluant.
Deuxième essai : le scénario A exécute le scenario B.
Le scénario B boucle sur lui même tant que la condition n’est pas atteinte et se réexecute lui même toutes les X minutes.
dans votre cas, je suis plutot d’avis que ni les boucles ni les 2 scénarios ne sont une bonne idée => bientôt vous allez chercher pourquoi votre charge cpu a explosé et que tout est lent.
En déclencheur vous mettez toutes les commandes qui vont servir au test dans le scénario, une commande par ligne de déclencheur; càd :
#[Températures][Sonde Nord][Température]#
#[Températures][Sonde Chambre AA][Température]#
#[Températures][Sonde Salle de bain][Température]#
=> donc 3 déclencheurs dans ce cas.
Dans le scénario, vous faite juste un Si #[Températures][Sonde Nord][Température]# - 2.5 < max(#[Températures][Sonde Chambre AA][Température]#,#[Températures][Sonde Salle de bain][Température]#) et ensuite vos actions et c’est terminé. Vous pouvez rajouter des tests ou des actions si nécessaires, je n’ai pas lu entièrement le scénario.
Le principe est que dès qu’une info change, le scénario va démarrer et évaluer la situation selon vos choix et faire les actions requises et ensuite stop.
Aucun besoin d’avoir des scénarios qui tournent en permanence ou qui se rappellent l’un l’autre à l’infini, c’est une très mauvaise idée.
Bonjour a tous
Je suis d’accord avec @Mips (pas trop de boucle / pas trop de multiples scénarios quand on peut faire autrement).
Pour info votre scénario s’arrête car il dépasse le temps max.
Si vous faite le même qui se declenche toute les heure avec 11 boucles de 5 min, il fonctionnera.
Les déclencheurs : je mettrai tout dedans !
Il faut pas oublier qu’ils peuvent etres tres riche et puissant avec des virtuels !!
Vituel condition d’heure : Vh = vrai si heure comprise entre x et y
Virtuel de température extérieur : Vtx = vrai si température extérieur comprise entre x et y
Virtuel de température intérieur : Vti = vrai si….
Virtuel delta température : Vdt = vrai si température intérieur - temperature extérieur >= 1
Virtuel mode activé : Vm = vrai si ….
Le déclencheur devient
Vh==1 && Vtx==1 && Vti==1 && Vdt==1 && Vm==1 &&…. && #température extérieur#
Dans cette exemple, c’est bien la modification de la température extérieur qui va declencher le scénario mais que dans certaines conditions !
(Tous les virtuel à vrai).
On peut même avoir des conditions qui dependent que des virtuels.
Bref, il faut faire sa sauce avec mais….
Virtuel + déclencheur = on fait déjà beaucoup de filtration et c’est trèssss riche !
le (mauvais) raisonnement avant était :
déclenchement programmé du scénario à 4H du mat avec des programmation « A » et dont un « A conditionnel » :
A partir de 19H ; je test le delta de temperature
SI OK, j’ouvre les volets
SI KO, je re-essaye dans 5 minutes…
Le raisonnement maintenant est :
déclencheur du scenario : les sondes de température
SI #time# > 1900 && #time# < 2359 && Condition temperature && variable(volets)==fermés ; alors
on ouvre et on met une variable(volets) == ouverts
Sinon il se passe rien.
Du coup j’ai tout dans un seul scénario, pas de boucles, ni de wait/sleep
autre approche possible : Utiliser des déclencheurs complexes, un peu comme un « SI », dépendants de variables positionnées dans des virtuels (pour avoir un visuel coté dashboard aussi ça peut être sympa). j’étudierai cette piste pour mes prochains scénarios !
