J’ai un scenario d’allumage de lampe simple dans un couloir qui a comme déclencheur un détecteur de présence neo coolcam z-wave et comme actionneur un Sonoff zigbee mini sans neutre.
Lorsque je passe dans le couloir, la détection de présence est quasiment instantanée.
Lorsque j’utilise les commandes de Jeedom pour allumer le ZB mini, l’allumage aussi (malgré un lqi de +/- 120)
Pourtant, lorsque le scenario s’exécute, la lampe met parfois près de 4 secondes à s’allumer, ce qui est évidemment gênant pour un petit couloir…
Quelqu’un saurait-il me dire vers où regarder pour diminuer ce temps d’exécution du scenario ?
Au cas où ça pourrait être utile, je précise que jeedom est relié au réseau en filaire.
Hello
Les delais des scenarios ne sont pas immédiats. Sur un PI3 je ne suis pas étonné.
Chez moi, j’ai 1 sec entre la detection (zigbee) et l’allumage (zwave).
J’avais essayé de faire une detection zwave et allumage zwave aussi pour que çà se fasse directement dans le protocole nativement sans scenario. mais je suis jamais descendu sous la seconde, pourtant mon jeedom est une bête de course sous NUC.
1 seconde, j’aimerais bien, je suis plutôt vers 4-5…
Est- ce que cela signifie que si je change pour un autre Pi je pourrais avoir des délais inférieurs ?
Du coup petite question : mon scenario se lance lui même pour faire un équivalent de boucle « for » ; dans la commande « action », dois je choisir « démarrer » ou « démarrer (sync) » ?
Oula comment ça se lance lui même ? Attention le mode synchrone est dangereux et peut ralentir d’autre truc sur ton jeedom ou même le planter. Faut surtout pas faire de boucle sur ce type de scénario par exemple
L’idée est que la lumière reste allumée tant que le détecteur de présence est sur « on », j’avais lu qq part que c’était le seul moyen de faire une boulce « for »…
Sans ça tout ce que je peux faire c’est mettre un délai fixe d’allumage, et 1 fois sur deux la lumière s’éteint quand on est dans le couloir, ou reste allumée alors qu’on est parti…
Bonjour,
Je ne pense pas que ce soit une bonne méthode…
D’une part parce que l’utilisation d’un ‹ sleep › dans un scénario, ce n’est pas terrible en termes d’utilisation des ressources (qui me semblent comptées vu la charge système), et d’autre part parce que combiné à un fonctionnement en mode synchrone, ce n’est pas du tout recommandé :
(dixit la doc officielle concernant les scénarios)
Pour ma part, je préconiserai plutôt un fonctionnement du type :
Détection > exécution d’un premier scénario pour allumer le luminaire en mode synchrone
Fin de détection > exécution d’un scénario pour éteindre le luminaire après un temps de latence
Concrètement, ça donnerai ça :
1er scénario : allumage du luminaire sur détection
Le scénario d’allumage du luminaire est démarré sur une détection de mouvement (ou de présence). Fin du scénario, la lumière est sur ON.
Au réarmement du détecteur de présence (==0) après x secondes (je ne connais pas pour les néo coolcalm, mais pour les Aqara par exemple, c’est 90 secondes), ET si la lumière est allumée (le retour d’état du SONOFF mini) (déclencheur), on se donne un délais de latence supplémentaire de 2’ (ou d’1’, mais pas moins puisque c’est le pas minimum), et on exécute après ce délai la boucle SI…SINON.
Donc 2’ après, SI on a plus de détection de présence, ALORS on stoppe le luminaire.
SINON, c’est qu’il y a eu une nouvelle détection pendant ce laps de temps. Dans ce cas on laisse la lumière allumée (on ne fait rien), et on supprime l’exécution de la boucle SI…SINON éventuellement programmée (par l’instruction ‹ remove_inat ›).
On n’utilise donc pas de ‹ sleep ›, ni de ‹ wait ›, ou d’autres instructions bloquantes…
Par contre, la lumière s’éteint après un délai incompressible du temps de réarmement du détecteur de présence + 1’ au minimum.
Pour minimiser ce temps de réarmement, perso j’utilise non pas un détecteur de mouvement, mais un détecteur de présence Sonoff SNZB-06P qui (entre autre avantages mais je ne vais pas développer) se réarme après 15".
