J’ai ajouté une prise connectée avec mesure de consommation à mon lave linge, ce qui me permet de savoir si un cycle est en cours ou non et donc de déclencher des notifications en début et fin de cycle pour me tenir informé. J’ai créé un virtuel « Lave linge » basé sur ma prise connectée sur laquelle j’ai ajouté une info « Cycle en cours » que je passe à 1 ou à 0 en fonction de seuils de consommation (cette partie fonctionne nickel, c’est pour vous donner du contexte).
Evidemment, il m’arrive encore de passer à côté de la notif de fin de cycle (malgré la notif sur téléphone et un bandeau de led qui clignote dans le salon ).
Je souhaitais donc améliorer tout ça en ajoutant des relances à intervalle régulier jusqu’à ce que le linge soit effectivement sorti de la machine.
Pour détecter si le lave linge a été vidé (est-ce que le hublot a été ouvert après un cycle terminé), j’ai ajouté un capteur d’ouverture de porte sur mon hublot. J’ai commencé par ajouter une info « Hublot ouvert » dans mon virtuel « Lave linge » qui reprend l’état de mon capteur de porte fixé sur le hublot.
Dans une première étape, je pense que ça serait judicieux de compléter mon virtuel « Lave linge » avec une nouvelle info (ex. « Linge présent ») me permettant de savoir si du linge est encore dans la machine (Linge présent = 1 dès que Cycle en cours = 1 et Linge présent = 0 dès que Cycle en cours = 0 et Hublot ouvert = 1).
Je suis un peu perdu sur la suite. Quelle serait selon-vous la meilleure approche pour mettre en place des relances régulières et pour les désactiver dès que la porte du hublot est ouverte ?
J’ai actuellement le scénario suivant pour les notification de début et fin de cycle :
(Déclencheur sur scénario : #[Buanderie][Lave linge][Cycle en cours]#)
Je pensais créer un scénario spécifique pour la relance qui utilise un bloc « DANS » et qui s’appelle lui-même à la fin. Et utiliser un autre scénario pour « stopper » les cron mais je crois que ce n’est pas possible d’appeler remove_inat pour un autre scenario ?
Ça me parait un poil compliqué ton besoin.
Comment sais-tu que le lave-linge est vidé avec la seule info porte ouverte ?
A moins que tu ne considère que parce qu’il a été ouvert qu’il a forcement été vidé.
Si c’est le cas, ton scénario devient beaucoup plus simple.
2 scénarios, un pour le démarrage du lave-linge, un pour son arrêt.
Le 1er avec pour declencheur la puissance au démarrage (à calculer), le 2ème déclencheur puissance à l’arrêt (à calculer également.
Le premier lance le deuxième et se désactive, pareil pour le 2ème après qu’il ait terminé tout son traitement.
Après, tout ce qui concerne le vidage se traite dans le scénario d’arrêt, notamment le traitement de la porte ouverte qui peut être mis en déclencheur également.
Heu… Cette histoire de machine à laver pleine ou pas… de notif de rappel…
Ça me fait bigrement penser à ce qu’on met en place pour la gestion d’une boite à lettre, non?
J’avais un truc du genre:
Scenario A: Puissance au dessus du seuil => Dépose de courrier, BàL+=1
Scenario B: Ouverture hublot => Relève du courrier donc BàL = 0 et envoi d’une notif signalant la relève
Scenario C: Déclenché régulièrement (2x/jour) sur CRON et envoi de notif de rappel si BàL différent de 0
Je ne te passerai pas de screenshot, j’ai tout perdu (sauvegardes paramétrées de travers ) lors du passage en V4 qui à mal fonctionné…
En effet, quand un cycle est terminé, si nous ouvrons la porte c’est systématiquement pour sortir le linge (l’étendre ou transvaser dans le sèche linge).
Mon scénario actuel se déclenche sur un état ‹ ‹ Cycle en cours › › qui est calculé au sein de mon virtuel (solution que je préfère à l’utilisation d’un scénario pour calculer cet état).
Ce scénario me permet actuellement simplement de me notifier au moment où l’état passe de 0 à 1 ou inversement.
Ce que j’ai du mal à saisir c’est qu’elle serait la solution la plus maintenable et celle qui permet de mieux séparer les responsabilités.
Si je mets toute la logique de ‹ ‹ rappel de déchargement du linge › › dans un scénario et use celui est appelé à partir de mon scénario existant lors une détection de fin de cycle, ca me va bien.
Mais si je fonctionne ainsi je ne vois pas comment stopper tous les cron en cours lors du changement d’état ‹ ‹ Linge présent = 0 › › ?
Est ce qu’ajouter un déclenchement ‹ ‹ Linge présent= 0 › › sur ce scénario de rappel (pour déclencher un remove_inat) serait une bonne idée ?
Si oui, comment je peux savoir dans ce scénario qu’il a été appelé pour faire un reset (remove_inat) des crons potentiellement déclenchés ?
Par contre ce qui diffère c’est le moment de la relance / l’intervalle.
Dans ce que tu décris ça semble moins souple que ce une j’avais l’intention de faire : je voulais faire des rappels aux intervalles suivant par ex
Les 4 premiers rappels toutes les 10/15min
Les 2 suivant toutes les 30min
Les 2 suivant toutes les 1h
Les 2 suivant toutes les 2h
Ensuite toutes les 4h
Y aurait il une manière de dériver ta solution pour arriver à ce que je souhaite ?
Ca ne va pas très vite devenir exaspérant tout ces rappels ?
Mets une prise connectée sur la tv et n’autorise la mise en route de la tv que si la machine a été vidée. La au moins c’est radical
Je plaisante bien sur … quoique en y réfléchissant
Ca ne va pas très vite devenir exaspérant tout ces rappels ?
Ahah si ! Mais c’est le but recherché ! Une machine vient de tourner, donc… il faut l’étendre (je pense affiner par la suite évidemment (de signaler seulement si on est à la maison et/ou de signaler / rappeler quand on rentre à la maison).
Mets une prise connectée sur la tv et n’autorise la mise en route de la tv que si la machine a été vidée. La au moins c’est radical
C’est une idée !! Avec la diffusion d’un message sur la télé
Bon après, évidemment la fréquence et les intervalles (les intervaux ? ) sont à affiner ^^
Le but, c’est que soit plus chiant que de sortir le linge.
Par exemple, une petite sirène qui corne de plus en plus fort…
Et coupe aussi internet.
Ou encore
Non, tu programmes l’envoi d’un SMS à quelqu’un d’autre avec comme message « X n’a pas sorti son linge depuis Y heures ». Ainsi, si tu ne veux pas avoir la honte, tu te dépêcheras de sortir le linge.
Je vois bien une solution, mais c’est surement pas dans la philosophie du langage Jeedom! Le seul langage qui me cause un peu, c’est le « C »: if, while, for et switch, case. Mais le CRON, les Commandes, les Virtuels… je galère encore sévère.
Tu souhaites:
faire des déclenchements successifs à intervalles non identiques.
et je suppose, pouvoir modifier assez facilement le nombre de fois qu’on répète un intervalle donné.
Si j’avais à faire cela:
Je créer un scenario déclenché toutes les 5 minutes
Dedans, je teste si la MàL est pleine
Si la MàL est pleine, j’y incrémente une variable globale de 5 (minutes).
Puis je place autant de test SI pour tester si ladite variable globale vaut le nombre de minutes correspondant à l’heure d’un rappel: 15, 30, 45, 60, 90, 120, 180, 240, 360, 480
Enfin test si Variable plus grande que 480, test si variable multiple de 240 (pour intervalle de 4 heures)
C’est bien bourrin , mais c’est facilement compréhensible et modifiable.
En C, j’aurai parcouru un tableau avec dedans la liste des délais au bout desquels il faut faire un rappel.
Je ne sais pas si l’équivalent d’un tableau peut être déclaré sous Jeedom; ce serait plus élégant…
Fonctionnement :
Sur ouverture de hublot → suppression de tous les cron et notification si besoin.
Sur déclenchement d’un début de cycle → notification
Sur déclenchement d’une fin de cycle →
Si présent → Notification rappel de sortir le linge et cela autant de fois que défini
Si a la fin de ces 5 relances, aucune ouverture n’a été faite sur le hublot, alors le scénario s’arrête.
Si absent → relance du scénario dans x min, jusqu’a ce qu’une présence soit détecté, puis ensuite IDEM que 1)
Règlage :
Premier bloc DANS → fréquence pour vérifier la présence, 1mn pour l’exemple mais doit être augmenter a mini 15/20mn je pense, pour éviter un lancement trop repetitif du scénario.
2ème bloc DANS → fréquence de rappel de notification.
Je suis parti sur l’approche suivante (je n’ai pas encore pu tester en condition réelle, je vous tiendrais au courant ) :
2 scénarios :
Mon scénario existant de détection de début et fin de cycle auquel j’ai rajouté le lancement d’un second scénario qui a pour but de gérer uniquement les relances.
Un second scénario qui gère uniquement les relances à l’aide d’un bloc DANS et qui me permet d’affiner le rythme des relances. Ce scénario peut donc être déclenché depuis mon premier scénario de détection de fin de cycle, mais il peut aussi être déclenché sur le changement d’état du capteur d’ouverture du hublot afin de pouvoir utiliser la fonction remove_inat. J’ai donc ajouté une condition me permettant de savoir comment a été déclenché le scénario (pour savoir si je dois annuler les crons ou au contraire programmer le prochain).
Je pense qu’en prenant un peu de mon scénario (gestion de présence) et du tient (affinage du rythme des relances) tu peut arriver a un scénario bien complet
Yes carrément !! Je n’ai pas eu l’énergie d’intégrer / réfléchir à la présence (voire même d’exclure la période entre le moment du coucher et du lever (puisque ça ne sert à rien de notifier à ce moment-là en tout cas, pas pour des urgences).
Mais je dois appliquer cette gestion de notification (intégrant le coucher et la présence) de manière plus intelligente à l’ensemble de mon installation domotique. J’aimerais centraliser tout ça pour éviter de dupliquer la logique dans tous mes scénarios.
J’ai déjà avancé sur ce point à l’aide d’un scénario pour faire de la notification visuelle avec certaines lumières via un scénario. Je peux passer un tag qui définit le level de notif (success, info, warning, danger). Je vais y ajouter la gestion de notif sur smartphone
Eh bien après quelques machines, je peux vous dire que ça fonctionne à la perfection
Je dois juste ajuster mon mécanisme de notifications et de relances (globalement). Ca n’a pas de sens par exemple de notifier en pleine nuit ou quand personne n’est à la maison ^^
).
Cette histoire de machine à laver pleine ou pas… de notif de rappel…
je galère encore sévère.
, mais c’est facilement compréhensible et modifiable.
