Je souhaite faire une automatisation qui respecte les critères suivant :
Allumage (couleur/luminosité selon mode jour/soirée/nuit)
Extinction si capteur de mouvement n’indique plus de mouvement depuis 30 secondes
Le premier point fonctionne, mais je bloque sur le second, car :
Si on fait un wait/sleep pendant 30 sec, tout est bloqué. De plus si dans il y’a du mouvement continu (aller/retour dans la pièce), alors ça s’éteint quand même après 30 sec.
Si on fait un « dans » 1 minutes (pas possible de faire en secondes…), et vérifier si après cela mouvement, si non éteindre, si oui recommencer un « dans » 1 minutes, mais on rentre dans une boucle infernal, soit il n’y a plus de mouvement et ok (mais ça fait tout de même 2 minutes), soit on recommence et il faut prévoir une infinité de boucle. J’ai également voulu faire un remove_inat mais pas pu mieux m’en sortir.
Salut. Oui j’ai un scénario de ce type et ça marche très bien.
Par contre ne t’embêtes pas à essayer de boucler ou de vérifier si il y a de nouveau un mouvement, perso je pars sur le principe suivant :
Si il y a mouvement je déclenche le scénario qui allume la lumière pour X minutes en programmant l’arret de l’éclaiage avec un DANS
Si il n’y a pas de nouveau mouvement j’arrive au bout de ma tempo, le DANS se déclenche et arrete la lumière
Si entre temps il y a eu un nouveau mouvement, le scénario s’est relancé je supprime la prog précédente avec un remove_inat (pas forcément obligatoire mais je préfère faire ça) et je reprogramme le DANS x minutes plus tard.
Pas besoin de retester à l’expiration du délai si il y a toujours mouvement ou pas, si c’était le cas un nouveau DANS aurait été reprogrammé.
Par contre honnement le coup des 30s je suis pas fan. Quand j’allume la lumière c’est pour minimum 5 minutes, ça m’évite d’allumer/éteindre/allumer si je fais des allers retours entre deux pièces. Et vu la conso en 2023 des lampes LED clairement ça économise quasi rien comme conso élec tout en « coutant » des cycles de vie à l’ampoule.
En complément de mon message d’hier, quelques petites particularités que j’ai dans mon scénario par rapport à ce qu’à fait @Sigri :
J’utilise des tags et non des variables pour définir le niveau et la couleur de l’éclairage (vu que je ne me sers pas de ces infos en dehors du scénario en lui même je n’ai pas jugé utilise d’utiliser des variables).
J’ai plusieurs capteurs qui peuvent déclencher mon scénario mais certains lancent la tempo et d’autres non. Par exemple un capteur de présence relance la tempo alors que le capteur de luminosité va lancer le scénario (pour par exemple augmenter le niveau d’éclaiage si il fait plus sombre) mais lui ne relancera pas la tempo
En fait je lance deux tempos différentes avec deux blocs A disjoints : un à X-1 minutes et un autre à X minutes. Ca me permet de changer la couleur du plafonnier lorsque j’arrive à 1 minute de la fin de la minuterie : ça me permet de me rendre compte que la lumière va bientot s’éteindre plutot que de me retrouver dans le noir d’un coup.
J’utilises le plugin Mode pour définir un mode d’éclairage par pièces. Je mets 4 modes systématiquement :
– On (forçage de l’allumage de toutes les lampes à 100%)
– Off (forçage de l’extinction de toutes les lampes)
– Auto (Gestion de l’éclairage automatique en fonction de la détection de présence, de la luminosité, l’heure du jour …)
– Manuel (pour pouvoir forcer mes scénarios à ne rien toucher si je veux régler un éclairage particulier)
En plus, je peux être amené à en ajouter d’autres spécifiques, par exemple un mode TV quand je regarde un film et que je veux avoir un éclairage spécifique.
Alors pour la partie que tu explique, je suis d’accord avec toi, mais alors tu as un scénario / pièce je suppose ?
Car j’avais essayé ton système, mais le soucis est que si je vais dans couloir + entrée, un DANS 5 min, que je repasse dans couloir, alors remove_inat va tout faire sauter (car après avoir creusé la doc, ça remove TOUS les DANS d’un scénario), et alors ça va recréer un DANS couloir 5 min, mais mon entrée sera restée allumée indéfiniment.
Réellement je suis à 1 min (car mes capteurs n’ont pas un refresh plus fin), et donc avec la vérif double ça donne 2 min, ça me convient bien.
J’ai voulu, mais un ami l’utilisant depuis un moment et voyant aucun update, et ma version 4 + docker + python semblant assez capricieux, j’ai pas souhaité tenter l’expérience.
Oui effectivement j’ai un scénario par pièce.
J’ai bâti mon systeme sur un mode par pièce et un scénario par pièce.
Après en mode auto je gère à la fois la présence ET la luminosité (plus il fait jour moins j’éclaire) donc cette différentiation se fait aussi par pièce.
Mais du coup oui avec remove_inat tu est obligé de supprimer tous les blocs DANS d’un même scénario donc forcément tu n’a pas le choix que de scinder par scénario si tu veux utiliser cette fonctionnalité.
Ok effectivement c’est un concept ! Je voulais mutualiser au max (c’est le côté dev) et regrouper tout ce qui est redondant, afin d’éviter les doublons, et surtout en cas de MàJ, éviter de devoir repasser à 50 endroits.
Je vais réfléchir à cela, merci !
PS : Y’a aussi la contrainte de DANS n’est que en minutes si je dis pas bêtises, alors qu’un wait est en secondes (mais le wait bloque le process, donc pas top).
Oui bien sur je comprends et j’ai tendance à vouloir faire pareil.
Mais bon la pour l’éclairage, j’ai un principe de base et après selon les cas j’adapte (par exemple pour la salle de bains qui est une pièce aveugle sans fenêtre je ne tiens pas compte de la luminosité ambiante contrairement aux pièces où il y a des fenêtres et des volets). Bon bien sur avec le truc super bien développé tu peux gérer les cas généraux et les exceptions mais bon pour mon besoin je suis pas rentré dans un truc overkill
Oui DANS est en minutes mais comme je l’ai dit précédemment ça ne me pose pas de soucis car en général j’allume pour minimum 5 minutes. Vu la conso d’une lampe LED d’aujourd’hui quand je fais des allers/retours entre les pièces je préfère que ça reste allumé quelques minutes que de faire du on/off/on/off en permanence.
Le wait est effectivement en secondes MAIS :
déja dans le cas d’une temporisation il faut utiliser sleep et pas wait (wait c’est quand tu veux attendre qu’une condition change, pas attendre qu’un délai s’écoule même si il existe une notion de timeout sur délai la fonction n’est pas conçue pour ça.
le sleep ou le wait s’exécutent en interactif dans le scénario alors que le dans programme un « sous scénario ». C’est la deuxième option qui m’intéresse car vu que j’ai plusieurs déclencheurs pour un même scénario, si je ne passe pas par du sous scénario je ne peux pas « réarmer » ma tempo par le passage devant un autre capteur (à moins de faire un truc plus compliqué à base de timestamp stocké quelque part mais je ne veux pas m’amuser à ça).
Effectivement ça se tient, allez c’est week-end repos, je tente une pièce déjà voir ce que ça va donner. Tu aurais une capture de la partie déclenchement du scénario, ainsi que les blocs histoire que je m’inspire d’un professionnel stp ?
Je partage ce que j’ai fait ci dessous mais j’ai pas vocation à dire que je suis un professionnel de Jeedom
Ca peut paraitre un peu complexe mais c’est le résultat de plusieurs années de retour d’expérience de choses qui me manquaient dans les versions précédentes.
