Je suis tout nouveau sur Jeedom et je découvre progressivement…
Je souhaite gérer l’allumage temporisé d’une fontaine sur ma terrasse lorsque je détecte quelqu’un :
*Je voudrais qu’alors la lumière s’allume pendant x minutes, et que le timer associé soit réarmé à x minutes à chaque fois que quelqu’un est de nouveau détecté.
Je souhaite que cela fonctionne du lever au coucher du soleil.
Le nombre de x minutes doit pouvoir varier selon la saison (ex.: 10 minutes en été, 5 minutes en hiver)
Pour l’instant, voilà comment j’ai codé ça :
Un virtuel avec une info « Timer », une action « ResetHiver » qui fixe le timer à 3 et une action « ResetÉté » qui fixe le timer à 6
Un scenario A qui se déclenche avant le lever du soleil et qui :
Avec un bloc A, lorsque le soleil se lève, active un scenario B et active un scenario C
Avec un bloc A, lorsque le soleil se couche, désactive le scenario B, arrête le scenario B, arrête le scenario C et arrête la fontaine
Un scenario B qui se déclenche lorsque quelqu’un est détecté sur la terrasse, qui :
Lance un Reset selon la saison
Met en marche la fontaine
Un scenario C qui se déclenche toutes les minutes, qui :
Décrémente l’info « Timer » de mon virtuel
Si le timer a atteint 0, arrête la fontaine
Mes questions sont les suivantes :
J’imagine qu’il y a plusieurs moyens alternatifs de faire. J’aimerais savoir ce que vous en pensez, s’il y a moyen de faire mieux, plus propre, moins gourmand en ressources.
Je suppose qu’il y a moyen de se passer de virtuel en utilisant une variable globale commune aux différents scenarios. Outre le fait que je n’aime pas trop le principe de variable globale, je ne maîtrise pas la portée des variables au sein des scenarios. Quelle est la portée d’une variable par défaut ? Est-il possible de déclarer explicitement la portée d’une variable ?
Avec mon code, la pompe reste en marche pendant 2 à 3 minutes, selon le moment où le réarmement du timer s’effectue (en début ou en fin de minute…). Je préférerais gérer ça plus finement mais j’ai pas trouvé sans m’engager dans des boucles et des wait dans lesquels je n’ai pas vraiment envie de m’engager…
Je suppose que lorsqu’on désactive un scenario il (i.e. toutes ses instances, le cas échéant) est immédiatement arrêté. Confirmez-vous ? Pour l’instant j’ai préféré explicitement arrêter le scenario B après l’avoir désactivé car je n’en suis pas sûr du tout
Sauf erreur, l’arrêt d’un scenario n’annule pas les tâches qu’il a programmées (les blocs A). J’imagine, à tort peut-être, qu’une désactivation du scenario ne les annule pas non plus. Du coup on se retrouve avec des tâches programmées ici ou là, avec des risques de dysfonctionnement potentiellement difficiles à identifier en cas d’erreur. Est-il possible de les voir quelque part ? (je suis allé voir le moteur de tâches mais je ne les y trouve pas) Est-il possible de les annuler, et si oui comment ?
Merci pour ces premières réponses. A priori pour les points que tu abordes on fait la même chose, donc.
J’ai lu quelque part qu’il ne fallait pas abuser des virtuels pour cause de consommation de ressources, mais je ne retrouve plus où…
C’est exact, mais ca concerne essentiellement un cas d’usage, à savoir la duplication des tous ses équipements en virtuels pour simplifier la maintenance. C’était à la monde il y a quelques temps, et il y a eu une info de @Loic pour dire que ce n’état pas l’usage initial prevu des virtuels et que ce n’était pas conseillé à cause d’une consommation excessive de ressources.
Donc dans ton cas, c’est OK, tu peux y aller avec les virtuels.
Concernant ton scenario. il y a en effet plus simple je pense :
scenario avec declencheur le capteur de presence
contenu du scenario :
Si saison == ete alors
tag timer = 10
Sinon
tag timer = 5
Si time_between(#time#,<heure lever>,<heure coucher>) alors
remove_inat // le remove_inat permet de supprimer la planif precedente et donc de relancer le timer
Si Etatl Lampe == 0 alors
Allumage Lampe
Si Etat fontaine == 0 alors
Allumage fontaine
Dans tag(timer)
Eteindre Lampe
Eteindre fontaine
cette solution traite tous tes points :
1 - pas de virtuel, pas de variables « globales », juste 1 tag propre au scénario
2 - tache d’arret planifiée exactement Xmin après le demarrage ou la derniere detection et pas sur des minutes pleines
3 - pas de problématiques de taches qui restent en cours lorsqu’on désactive le scenario … vu qu’on ne desactive aucun scenario
Norbert
ps : le remove_inat n’est pas utile car une replanification supprimera automatiquement l’ancienne planification, mais je trouve celà plus parlant
Je me rends compte que mon message n’était pas complètement clair car j’y parlais au début d’allumage lumière au lieu de mise en marche fontaine. Je ne souhaite gérer que la mise en marche de la fontaine. Bon, ceci dit ça ne change rien.
Si je comprends bien ta proposition, chaque détection relance le scenario, ce qui dans les faits interrompt l’instance précédente si elle est dans le « DANS », et donc réarme le timer. C’est bien ça ?
Je n’aime pas trop l’idée de scenarios qui se déclenchent pour rien à tout bout de champ (en l’occurrence lorsque le soleil est couché). Je pense donc conserver le scenario A d’activation / désactivation, ce qui n’empêche pas de réunifier les scenarios B et C comme tu l’as proposé…
Mis à part ça, j’avais aussi oublié de préciser qu’il y a en fait 2 détecteurs de présence, qui chacun doivent déclencher le timer. Comme ils peuvent être déclenchés dans la même seconde, cela veut dire que le scenario pourra être déclenché plusieurs fois. D’après la doc ça peut poser des problèmes avec les tags. Je ne sais pas comment éviter la chose…
D’ailleurs, je ne maîtrise pas du tout la notion de tag que je n’ai fait qu’effleurer de loin pour l’instant. Quoi qu’il en soit je ne comprends pas pourquoi tu proposes d’utiliser un tag plutôt qu’une variable pour le timer (?)
…et enfin, tu m’as fait découvrir le remove_inat, qui au passage répond à une de mes interrogations (comment supprimer les tâches programmées par les blocs A d’un scenario…)
Je me réponds à moi-même concernant les tags après avoir été lire 2/3 trucs. J’en comprends le principe. C’est juste un peu bizarre qu’ils puissent du coup faire office de variable locale…
…et sinon, j’ai fait un petit test : Un scenario est bien interrompu lorsqu’il est redéclenché et qu’il n’est pas coché comme étant multi-lancement.
Reste l’histoire des déclenchements possibles dans la même seconde…
Pour les déclenchements possibles dans la même seconde, tu peux effectivement avoir un scénario A de déclenchement avec les détecteurs en déclencheur, et qui lance le scénario B de timer tout en se désactivant également. Donc pas de nouveau lancement possible. Évidemment à la fin du scénario B (ou après une durée definie) tu réactives A.