Scenario d'éclairage avec baisse d'intensité avant extinction

Bonjour à tous,

J’aimerais avoir un scenario d’eclairage dans ma cuisine où :

  • Si mouvement detecté → ON
  • Si pas de mouvement detecté apres 1 min → Baisse d’intensité des lumieres
    → Si mouvement, retour des lumieres à leurs intensité de base
    → Si pas de mouvement dans les 20 secs, lumiere OFF

L’idée est de ne pas me retrouver dans le noir si je suis dans la cuisine et que je ne suis pas détecté en mouvement (lecture, attente d’un café, d’une cuisson, etc…) mais d’avoir une baisse de luminosité comme sur un ecran de PC lorsqu’il n’y a plus d’activités.

Voici le scenario que j’utilise jusqu’ici et qui est un peu capricieux :

(Screen en deux parties)


J’ai deux blocs distincts. Le premier concerne l’interrupteur de la cuisine, le deuxième est celui qui m’intéresse ici (detection de mouvement).

Oh, et voici ma config :
Un capteur de mouvement Xiaomi modifié, detection sur 5 sec
Un interrupteur murale Xiaomi qui commande des ampoules classics au plafond
Un bandeau LED (MagicHome) pour éclairer le plan de travail
Un bandeau LED (MagicHome) pour éclairer le sol

La cuisine fait un peu n’importe quoi, des fois lorsque j’arrive tout s’allume à 10%, des fois elle ne s’éteint pas, des fois elle s’éteint sans réduire la luminosité.

Je commence à perdre des cheveux sur ce scenario, si quelqu’un à d’autres méthodes, qu’il n’hesite pas :slight_smile:

Merci beaucoup et bonne journée

Déjà je vois plusieurs problèmes qui peuvent entraîner bien pire qu’une lumière qui s’allume pas ou qui s’éteint pas.

Premièrement je ne vois pas d’action remove_inat qui permet de supprimer la programmation du bloc « Dans » dans le cas ou un nouvel événement arrive avant son délai (1 minute pour ton cas) car cela peut entraîner des empilements et donc de la charge machine inutile et surtout des comportements non souhaités.
Deuxièmement le bloc wait est un élement bloquant pour le scénario donc si tu n’as pas coché la case multi-lancement (ce qui est pas forcement conseillé) le scénario ne se relancera pas tant que le wait n’est pas terminé.
Tu pourrais remplacer le wait par un déclenchement manuel du scénario (scenario start) (pour le trigger cf la documentation)

Du coup je t’invite à tester ton scénario avec des délais plus long (Dans à 5 minutes et un wait à 2 minutes par exemple) et de valider ton scénario en réalisant des tests réels précis pour valider les différents conditions et en vérifiant les logs du scénario pour t’assurer qu’il fait bien ce que tu penses qu’il doit faire, on a souvent des mauvaises surprises par rapport a des événements déclencheurs non prévus.

Bonjour Cadavor,

Je réécris mon message qui s’est supprimé :frowning:

Concernant le ‹ remov_inat › j’ai lu à plusieurs reprise qu’il ne s’appliquait pas dans ce cas puis un bloc ‹ dans › se réécrit s’il est appelé par le meme scenario. Peux-tu confirmer ?

Ensuite, j’ai corrigé un soucis sur mon scénario, j’avais un appel manuel configuré sur ‹ Aucun ›. J’ai edit mon premier post.

Et concernant les délais, au vu de l’architecture de ma maison, si les lumières de la cuisine restent allumé trop longtemps, cela est désagréable pour les gens dans le salon. De plus, ma cuisine est un lieu de passage, c’est pourquoi j’aimerais conservé les délais 1min et 20 sec.
J’avais un scenario bien plus simple par le passé avec 2 min d’éclairage et 1 min de luminosité réduite mais cela était déjà trop long.

Voici un exemple de comportement que je ne comprends pas.

------------------------------------
[2020-01-22 23:34:47][SCENARIO] Start : Scenario execute automatiquement sur evenement venant de : [Cuisine][Mouvement][Mouvement].
[2020-01-22 23:34:48][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-01-22 23:34:48][SCENARIO] Suppression des blocs DANS et A programmés du scénario
[2020-01-22 23:34:48][SCENARIO] Exécution du sous-élément de type [condition] : if
[2020-01-22 23:34:48][SCENARIO] Evaluation de la condition : [0 == 1
] = Faux
[2020-01-22 23:34:48][SCENARIO] Exécution du sous-élément de type [action] : else
[2020-01-22 23:34:48][SCENARIO] Exécution du sous-élément de type [condition] : if
[2020-01-22 23:34:48][SCENARIO] Evaluation de la condition : [1 == 1 ] = Vrai
[2020-01-22 23:34:48][SCENARIO] Exécution du sous-élément de type [action] : then
[2020-01-22 23:34:48][SCENARIO] Exécution d'un bloc élément : 320
[2020-01-22 23:34:48][SCENARIO] Exécution du sous-élément de type [condition] : if
[2020-01-22 23:34:48][SCENARIO] Evaluation de la condition : [2334 > 1900  ] = Vrai
[2020-01-22 23:34:48][SCENARIO] Exécution du sous-élément de type [action] : then
[2020-01-22 23:34:48][SCENARIO] Exécution de la commande [Cuisine][Interrupteur double][On Cuisine]
[2020-01-22 23:34:48][SCENARIO] Exécution de la commande [Cuisine][Plan de travail][On]
[2020-01-22 23:34:48][SCENARIO] Exécution de la commande [Cuisine][Sol][On]
[2020-01-22 23:34:48][SCENARIO] Exécution d'un bloc élément : 322
[2020-01-22 23:34:48][SCENARIO] Exécution du sous-élément de type [condition] : in
[2020-01-22 23:34:48][SCENARIO] Evaluation de la condition : [1] = 1
[2020-01-22 23:34:48][SCENARIO] Tâche : 322 programmée à : 2020-01-22 23:35:48 (+ 1 min)
[2020-01-22 23:34:48][SCENARIO] Exécution d'un bloc élément : 370
[2020-01-22 23:34:48][SCENARIO] Exécution du sous-élément de type [action] : action
[2020-01-22 23:34:48][SCENARIO] Pause de 3 seconde(s)
[2020-01-22 23:34:51][SCENARIO] Changement de [Cuisine][Mouvement][Mouvement] à 0
[2020-01-22 23:34:51][SCENARIO] Fin correcte du scénario
------------------------------------

Et rien ensuite. Pourquoi la tache programmé ne s’est elle pas exécuté ? Laissant ma cuisine allumé

Je ne sais pas, dans le doute…

Je te proposais d’augmenter les délais pour réaliser plus facilement des tests, si les tests sont bons tu pourras repasser aux valeurs que tu souhaites.
Cela te laissera plus de temps pour vérifier par exemple qu’une entrée a bien été créé dans le moteur de tache pour l’exécution du bloc Dans à l’heure prévue

Peux-tu nous mettre une capture d’écran du scénario plutôt que seulement l’export (c’est plus visuel)

Après ce bout de log, il n’y a plus rien?

Dans le doute s’est remis :slightly_smiling_face:

J’ai édité le post originel avec un screenshot (en deux parties).

Rien du tout.

Je n’ai mis que la fin du log ne pouvant ajouter de fichier avec un nouveau compte utilisateur (résolu)

Un bloc DANS ou À va remplacer (changer sa programmation) le bloc correspondant qui aurait été programmé lors d’une exécution précédente du scénario.

Donc si plusieurs blocs dans se suivent dans le même scénario ils seront tous programmés comme voulu (le dernier n’aura pas remplacé tous les autres)

Par contre si tu as un scénario avec un bloc SI et que dedans tu as un bloc DANS :

  • admettons qu’à la première exécution la condition soit valide alors le DANS est programmé.
  • deuxième execution (et le DANS n’a pas encore eu lieu) mais cette fois la condition n’est pas valide, le bloc DANS n’est pas programmé (normal) et la programmation précédente reste active.

Un remove_inat désactive tous les blocs DANS et À du scénario que ceux si soient reprogrammés ou pas.

J’espère que c’est plus clair :relaxed:

2 « J'aime »

Beaucoup plus clair merci :slight_smile:

Ce sujet a été automatiquement fermé après 24 heures suivant le dernier commentaire. Aucune réponse n’est permise dorénavant.