Pour gérer le chauffage selon l’occupation des chambres de la maison, je pensais mettre un calendrier unique « chambres », et dedans des évènements qui indiquaient si la chambre était occupée (si pas d’évènement, la chambre est vide donc pas de chauffage).
Or, pour mon automatisation je ne peux pas savoir si 2 évènements ont lieu en même temps dans le même calendrier, je n’ai l’information que du premier évènement créé (Ch2) et pas du second (Ch1). Du coup, je ne vais pas chauffer Chambre1 car je ne sais pas qu’elle est occupée…
{{ state_attr(‘calendar.chambres‘, ‘message’) }}
répond uniquement “Ch2”
Comment faire pour avoir conscience des 2 évènements, sans devoir créer 1 calendrier par chambre ?
Salut, ils n’ont même pas besoin d’être simultanés, à partir du moment où un événement est en cours, tant qu’il n’est pas terminé, l’intégration ne t’affichera pas les autres événements qui débutent.
À ma connaissance il n’y a pas de solution à ce problème là, à part comme tu l’as évoqué de créer un calendrier par chambre.
J’ai sorti les rames, et j’ai un piste qui je pense me conviendra. Mon dernier souci est que si l’évènement « Ch1 » existe, l’état du calendrier est « Activé ». Si j’ajoute un deuxième évènement « Ch2 », le calendrier reste « Activé » donc mon template listant les évènements ne se recalcule pas. Je pense que je vais le faire calculer toutes les 5 minutes pour ne rien rater.
Donc si ça peut aider quelqu’un, j’ai un template qui liste dans son STATE les évènements du calendrier, avec un « ; » à la fin, ce qui me donne « Ch2; Ch1 » :
Pourquoi ne pas te baser sur les démarrage d’événements de ton calendrier et t’en servir pour passer à ON un input_boolean par chambre (input_boolean.chambre_1_occupée par exemple) ?
Autre piste, plutôt qu’un calendrier utiliser un scheduler ?
Tu peux très bien créer un scheduler par chambre (c’est fait une fois pour toute) ou un scheduler unique.
Ca marche très bien pour un planning à la semaine, moins si tu veux gérer les vacances des enfants…
Dis nous en un peu plus sur ton besoin de départ, tu n’es peut-être pas parti sur la solution la plus optimale pour ton besoin.
je fais une description de mes automatisation de chauffage dans ma presentation si jamais: j’utilise un scheduler pour les plages de chauffage (resp clim) de la semaine, et je viens moduler ça en fonction du tarif et d’un mode « temporaire » que je trouve très pratique:
si le tarif tempo est rouge: on ne chauffe pas, quel que soit le mode du scheduler…
si le scheduler n’est plus d’actualité (ex vacances) je bascule en mode « manuel pur » et par exemple je coupe tout.
si le mode actuel du scheduler ne me plait pas, mais que je veux laisser l’automatisme pour ne pas oublier de gérer le chauffage plus tard (exemple: je suis en télétravail et le scheduler ne chauffe pas avant la fin d’après midi) je bascule en mode « temporaire manuel » et je vais rester en mode manuel (chauffage ON) jusqu’à la prochaine bascule du scheduler (=> retour automatique en mode « auto » à la prochaine phase de chauffe, en fin d’apres midi dans l’exemple du télétravail)
J’avais déjà essayé, mais j’ai re-testé. Cela ne me convient pas pour 2 raisons :
mes occupations-type seront un créneau 18h-10h. Si à 20h je créé par habitude un évènement 18h-10h, l’automatisation ne va pas se déclencher et ne va pas activer le input_boolean
si je ne me trompe pas, le calendrier se rafraichit toutes les 15 minutes, donc si je créé un évènement qui commence moins de 15 minutes plus tard l’automatisation ne se lancera pas et n’activera pas le input_boolean d’occupation.
C’est pour ça que l’idée était de passer par l’état du calendrier, qui lui fonctionne dans ces 2 cas (mais à condition qu’il n’y ait pas plusieurs évènements simultanés).
L’objectif de base est de gérer l’occupation occasionnelle et aléatoire des chambres (amis, famille, …)
J’ai déjà un Scheduler par chambre, qui me permet de créer le planning hebdomadaire de chauffe comme si la chambre était occupée en continu. Scheduler Card me remplit un « mode_scheduler_chX » par chambre (confort, éco, hors-gel).
Ensuite, l’idée est d’avoir pour chaque chambre un template « mode_template_chX » qui modifie (downgrade) ce mode selon des conditions (non-occupation, couleur jour Tempo, autres conditions…). (d’ailleurs, c’est facile à faire avec une température car j’ai uniquement à retirer 2°C à la consigne, mais là c’est peu pratique de dire « descend d’un niveau de consigne »)
Enfin, j’ai une automatisation qui se déclenche quand « mode_template_chX » change et modifie la valeur du boitier fil pilote du radiateur de la chambre X.
J’ai jeté un coup d’œil rapide à ta gestion du chauffage, je vais devoir relire en détail pour voir ça et m’inspirer.
Attention, ma façon de faire est un peu spécifique à mon install pour ma PAC gainable qui chauffe tout l’étage (avec un pilotage de la PAC mitsubishi via Mel Cloud donc au travers du cloud)
Du coup comme je veux conserver le pilotage via la télécommande au cas où et qu’entre HA (via mel cloud) et la télécommande, c’est « le dernier qui parle qui a raison »:
Plutôt qu’un pilotage par changement d’état, j’utilise un pilotage périodique.
Donc toutes les 10 min je lance l’automatisation qui va tester l’ensemble de mes booléens:
tarif rouge (tempo)
mode auto (auto/manuel)
mode manuel temporaire (auto / manuel temporaire)
scheduler (confort/reduit)
et en fonction régler la target de chauffage…
Ceci me permet si HA ou melcloud ou internet est KO de continuer à pouvoir allumer / éteindre la PAC via la télécommande.
Et si quelqu’un touche à la télécommande alors qu’HA tourne normalement, au bout de 10min max (sauf en mode manuel), HA reprend le contrôle.
Si je n’avais pas Mel cloud, j’aurais fait les choses différemment, mais les pannes ça arrive, et le chauffage c’est important :
des pannes de mel cloud (~1 x tous les deux ans)
des pannes d’internet (~1 x tous les 10ans)
Par contre la gestion des booléens peut être copiée sans soucis, ça c’est universel…
Donc en fait ce que tu veux gérer c’est l’absence ou la présence occasionelle dans tes chambres ?
Quel est le cas le plus courant, quelle est la fréquence d’occurrence du cas le moins courant ?
Par exemple tu ne vas pas traiter de la même façon:
une chambre inoccupée 90% du temps
une chambre occupée 60% du temps, genre quasi un jour sur deux.
Dit autrement tu peux imaginer un booléen par chambre : « chambre chauffée ». Si ce booléen change une fois de temps en temps (un week end de temps en temps, les vacances scolaires) tu peux imaginer de le contrôler à la main (via le dashboard, via un bouton physique dans la chambre, via un contrôle vocal).
Rien ne t’empêche d’avoir un contrôle uniquement pour l’allumage et une automatisation qui coupe au bout de x jour pour éviter d’oublier d’éteindre…
Si ce booléen change souvent, il faut essayer de l’automatiser:
Quelques pistes :
via des présences (par exemple ma freebox me remonte les connections au wifi, je peux ainsi savoir que les enfants sont connectés au wifi, donc présents, et ainsi decider de chauffer l’étage)
via de la localisation (mais pour des gens qui ont l’appli home assistant installée => ça peut marcher pour du télétravail occasionnel par exemple)
via des capteurs de présence (si presence détectée dans la chambre => passage en mode « chambre chauffée » pour 24h)
etc…
Perso, chez moi je gère ça via le mode temporaire et des scripts qui permettent la commande vocale et le passage en mode temporaire. Donc « à la main », mais assisté quand même…
je n’ai pas tout suivit mais il y a un moyen simple de faire ce que tu veux, c’est à dire si j’ai bien compris avoir dans un même calendrier plusieurs évènements à la même heure et déclencher pour chaque évènement une même automation. Dans le doute je viens de faire le test et ça fonctionne.
Le principe c’est seulement de dire à l’automation qu’elle peut se déclencher au même moment plusieurs fois soit pour traiter ces déclenchement les uns à la suite des autres soit en //.
Pour cela il faut changer le mode d’execution de cette automation.
Le problème de cela, c’est que si à 20h je créé un évènement de 18h le jour même à 10h le lendemain matin (parce que par habitude c’est le créneau-type), l’automatisation ne va pas se déclencher (car le trigger “début de l’évènement” sera passé) et ne va pas activer le input_boolean.
Même si effectivement, mon objectif est de créer ces évènements à l’avance.
J’ai lu tes automatisations et ton fonctionnement (et je vais en profiter pour t’emprunter tes room cards personnalisées à coup de mushroom, elles me plaisent bien ).
Ton fonctionnement correspond dans les grandes lignes à ce que je cherche à faire, mais je veux aller encore plus loin :
même si c’est une fois de temps en temps je ne veux pas contrôler à la main le jour J, je veux pouvoir programmer ces évènements non-récurrents. Tu actives ton mode « manuel temporaire » à la volée, mais j’aimerai programmer ce mode et plusieurs évènements à l’avance (d’où l’idée du calendrier, par rapport à un input_datetime de début et un autre de fin pour chacune des chambres).
reproduire ce fonctionnement pour toutes les pièces de la maison en les chauffant de manière indépendante (donc avoir 6 à 10 fois tout ce que tu as fait, je dois donc réduire le code et les endroits où c’est situé au maximum)
avoir plus de conditions pour modifier le mode de base (Tempo, occupation de la pièce, soleil qui chauffe la pièce par la fenêtre, …), et donc avec des automatisations je trouve que cela devient de plus en plus compliqué même si on peut mettre des Template dans les automatisations.
je veux avoir le même fonctionnement pour chaque pièce (qu’elle soit majoritairement occupée comme le salon ou les chambres principales à 98% du temps, ou occasionnellement occupée comme une chambre d’amis à 5% du temps), pour éviter de me tordre le cerveau quand j’aurai une condition à rajouter (j’aurai juste la même condition à copier/coller dans 10 templates à la structure identique)
Sinon, j’ai effectivement déjà les possibilités suivantes comme tu as fait :
override de la consigne via HA jusqu’au prochain changement (de Scheduler, de couleur Tempo, de présence, ou autre évènement recalculé par le Template) (compatible avec du télétravail imprévu, un retour à la maison plus tôt que prévu, …)
pour les radiateurs connectés pilotés par une température de consigne, override de la consigne physiquement sur le radiateur (malheureusement pas possible sur les radiateurs pilotés par module Zigbee fil pilote, mais pas grave)
désactivation du mode automatique (en désactivant l’automatisation finale qui pilote les radiateurs)
Il faut que je prenne le temps de creuser l’idée de mon post 3, je pense qu’elle fonctionne.
Je n’ai qu’une PAC et les registres de l’étage ne sont pas pilotables par HA, donc 'est thermostat dans les chambres réglés une fois pour toute sur la temperature de confort et ça ferme le registre lorsque la temp est atteinte…
Mais si un jour je domotise le bas (pour l’instant géré par fil pilote avec une centrale delta dore) j’aurais 8 radiateurs à piloter, donc comme toi 8 x la complexité à gérer…
Je ne sais pas si tu as regardé versatile thermostat, mais je crois qu’il intègre pas mal de chose de ce type direct dans son thermostat, c’est peut être interressant pour toi:
Je suis peut être encore hors sujet mais tu peux aussi ajouter une automation qui « toutes les minutes » regarde si ton calendrier est dans l’état actif et si tes input sont pas vrai alors les activer…
Edit : par contre tu ne sauras pas quel évènement active ce calendrier
Oui j’avais regardé, mais je pense que je n’aurai pas pu mettre toutes mes spécificités dedans, et si jamais le dév du module s’arrête ou qu’il ne devient plus compatible avec une nouvelle version de HA pendant l’hiver je suis coincé. Là avec uniquement des éléments natifs HA, je ne crains pas les MAJ.
Vu l’activité du Dev sur le forum, il y a peu de risque… et si ça marche pas lors d’une maJ HA, il suffit de revenir au soft HA précédant et de ne pas refaire la MaJ tant qu’il n’y a pas de fix…
Tu n’as aucun module HACS du coup dans ta chaine de chauffage?
Bah quelle idée de créer un évènement qui commence avant l’heure de création de cet événement
Forcément comme tu le dis il ne sera pas pris en compte mais rien ne t’empêche quand tu crées un événement de se genre de basculer toi même l’input_boolean correspondant et la même chose pour les histoires du 1/4 d’heure avant la prise en compte.
Autre solution quand tu crées un evenement du le fait débuter à minima un 1/4 d’heure après son heure de création.
Puisque l’objectif normal est de les créer en avance, je ne chercherai pas plus loin et forcerai l’input_boolean dans les cas que tu as cité.
Comme dit plus haut versatile plus sheduler. Le premier gère les paramètres (absent, fenêtre ouvert, consigne…) le deuxième le calendrier de consigne selon les besoins (tempo, jour de la semaine, meteo….). En combinant les deux tu trouveras forcément ton bonheur.
?
).