Comment gérer un horaire de chauffage couplé à un indicateur de présence avec la box Lifedomus

Apprenez comment gérer un thermostat en créant différents modules logiques qui vous permetttront de vous affranchir d'un programmateur horaire KNX et d'un module de scénarios KNX



Un des intérêts majeurs de la box Lifedomus est la possibilité, pour l'intégrateur comme pour le client final, de créer des modules logiques qui seront déclenchés dans certaines conditions et qui activeront (ou non) certains composants de l'installation domotique.

Avec la Lifedomus, ces modules logiques sont très puissants et permettent de s'affranchir totalement de l'achat d'un module de scénarios KNX. Un tel module coûte environ 200 euros HTVA pour 8 scénarios. La programmation d'un module de scénario KNX peut être relativement complexe mais surtout elle est peu modulable pour le client final si celui-ci ne dispose pas des connaissances nécessaires et du logiciel ETS.

Un autre composant KNX est le programmateur horaire. Ce module permet de définir un nombre d'horaires (limité) et d'y associer des actions (allumer un chauffage, baisser les volets, etc). Bien sûr il peut être combiné à un module de scénarios pour étendre ses fonctionnalités mais une fois de plus, pour le client final, c'est une tâche ardue ou peu intuitive.

Pourquoi ne pas utiliser le superviseur Lifedomus pour gérer des horaires couplés à des scénarios ? C'est ce que le présent article vous propose. La solution décrite ici n'est pas nécessairement la meilleure (quoique ... ?) mais elle a le mérite d'être simple, flexible et va vous donner quelques bons tuyaux sur l'utilisation des modules logiques de la Lifedomus.

Mise en situation

Imaginons le scénario suivant: ma maison, équipée en KNX bien sûr, dispose d'un thermostat dans une pièce de vie (la salle à manger par exemple). Ce thermostat, par KNX, contrôle le chauffage (sol ou radiateurs, peu importe) dans les pièces de vie. Je désire le fonctionnement suivant:

  • En nuit, le chauffage doit passer en régime Economique automatiquement
  • En journée,
    • si il y a quelqu'un à la maison, le chauffage doit passer en régime Confort
    • si il n'y a personne, le chauffage doit être en régime Economique SAUF SI on est en semaine (du lundi au vendredi donc) et qu'il est passé 16h (je reviens du boulot vers 17h et je voudrais que la maison soit chaude quand je rentre)
  • La notion de nuit et de journée sera différente selon les jours de semaine ou de week-end.
  • Je désire également pouvoir outrepasser l'horaire et le fonctionnement prévu et forcer un régime si par exemple je reçois des invités chez moi. Pour simplifier la programmation, cette dérogation ne sera pas basée sur une durée: j'indiquerai moi-même quand la Lifedomus doit reprendre l'horaire.
  • En outre, je désire également pouvoir outrepasser l'horaire en cas de jour férié ou jour de congé. La veille du jour de congé, le chauffage doit se couper plus tard (comme une veille de weekend) et le jour même, le chauffage doit se lancer plus tard également (comme un jour de week-end)
  • Enfin, si je pars en vacances, le thermostat doit se mettre sur mode Réduit jusqu'à mon retour. Pour le jour de mon retour, je dois pouvoir choisir l'heure à laquelle le chauffage se relance.

Voila somme toute un scénario bien classique qui combine les éléments domotiques dans une logique bien définie.

Préparation

Pour réussir correctement la programmation des modules logiques dans la Lifedomus il est impératif de bien se préparer et de mettre en toutes lettres ce qu'on désire faire. Les modules logiques de la Lifedomus se programment sans écrire une ligne de code, ce qui est plus facile pour le néophyte, mais cela ne veut pas dire qu'on peut s'y lancer sans une réflexion préalable.

Si vous n'êtes pas familier avec les modules logiques de la Lifedomus, je vous suggère de commencer par lire le manuel utilisateur qui vous donnera au moins les bases nécessaires pour manipuler et éditer les automates. Cet article suppose par ailleurs que vous avez l'habitude d'utiliser le Config Studio de Lifedomus.

NB: Lifedomus utilise parfois le terme "Automate" pour "Module Logique". Dans le Config Studio le terme "Automate" apparaît mais dans la documentation on utilise "Module Logique". De la même manière, dans ce article, nous utiliserons les deux termes.

Comme je désire être le plus flexible possible :

  • j'essaie de mettre un maximum d'informations dans des variables pour éviter de hardcoder des valeurs (="écrire en dur des valeurs figées dans un programme"). Si ces valeurs sont réutilisées dans d'autres automates, j'ai tout intérêt à placer ces valeurs dans variables, ce qui m'évitera de devoir éditer tous les automates contenant cette valeur si celle-ci devait changer. Imaginons que je change de boulot et que dorénavant je rentre du boulot à 15h au lieu de 17h, alors mon chauffage devrait se relancer à 14h plutôt que 16h comme prévu originellement. Pour plus de flexibilité je place cette valeur dans une variable et dorénavant je peux l'utiliser dans d'autres automates mais aussi la modifier selon d'autres conditions (une demi-journée de congé, etc.) sans toucher aux modules logiques qui s'occupent du chauffage.
  • je scinde les automates en plusieurs autres automates afin d'éviter d'avoir une automate gigantesque qui sera difficile à relire par la suite. A ma connaissance il n'y a pas de limite au nombre d'actions qu'un automate peut contenir mais par contre, plus il contient d'actions, plus il est difficile à lire. Un automate possède une fonction particulière. Tout ce qui ne fait pas strictement partie de cette fonction est scindé dans un autre automate. Par exemple, mon scénario implique de connaître si nous sommes en semaine ou en week-end. Cette information sera non seulement placée dans une variable (voir point précédent) mais également traité dans un automate séparé.

La nuit c'est quand ?

En effet, mon scénario aura un comportement différent en nuit et en journée. Mais quand commence la nuit ? Quand commence la journée ? Et est-ce que la nuit commence tous les jours à la même heure ? Je fixe les valeurs suivantes (sachant qu'elle réguleront mon thermostat sous certaines conditions):

JourFin de la nuitDébut de la nuit
Lundi 06:00 22:00
Mardi 06:00 22:00
Mercredi 06:00 22:00
Jeudi 06:00 22:00
Vendredi 06:00 23:00
Samedi 08:00 23:00
Dimanche 08:00 22:00

Bien sûr, je pourrais créer un automate avec sept conditions (une par jour) mais si on observe le tableau ci-dessus, il est clair que la couleur jaune de la colonne de gauche correspond aux jours de semaine alors que le vert correspond aux jours de weekend. Dans la colonne de droite, c'est un peu plus subtil: le jaune foncé correspond aux veilles de jour de semaine alors que le vert foncé correspond aux veilles de jours de weekend.

Sur base de cette info, on peut déjà établir une règle très simple:

  • En semaine, la fin de la nuit est à 6h00 alors qu'en weekend elle est à 8h00.
  • La veille des weekends, la nuit commence à 23h00 alors qu'elle commence à 22h00 les autres jours.

Simple et compact non ? Le seul problème est que la Lifedomus ne sait pas si on est en weekend ou en veille de weekend. Il va donc falloir lui apprendre cela. Heureusement la Lifedomus connaît le nom du jour de la semaine. On peut donc avoir une règle très simple comme celle-ci:

  • Si on est samedi ou dimanche, alors c'est le weekend, sinon c'est la semaine.
  • Si on est vendredi ou samedi, alors c'est une veille de weekend, sinon pas.

Comme expliqué plus haut, la solution présentée ici est une parmi d'autres. Si j'avais eu un horaire de travail plus disparate (genre un mi-temps), j'aurais peut-être trouvé une autre approche. Mais nous verrons qu'avec la notion de présence/absence/congé, les règles proposées ici sont souples et pratiquement universelles et demandent peu d'adaptations selon les horaires de travail. De plus, avoir à portée une information comme "Est-on en semaine ou en weekend ?" finira bien par servir dans un automate ou l'autre, donc autant l'utiliser.

Premier automate: Jour de Semaine et Veille Weekend

Nous pouvons donc déjà créer un premier automate. Nous l'appelerons "Jour de Semaine et Veille Weekend" car il va établir si le jour courant est un jour de semaine et/ou une veille de weekend.

Automate  : Jour de Semaine et Veille Weekend
Variables : bJourSemaine (booléen - public)
            bVeilleWeekend (booléen - public)
            nTriggerJourSemaineOK (numérique - public)
Démarrage auto : OUI
Déclencheur : A chaque changement de SYSTEM_DATE
Logique     : - START
              - Si SYSTEM_DAY_OF_WEEK = Samedi OU SI
                   SYSTEM_DAY_OF_WEEK = Dimanche
                  - TRUE  : bJourSemaine=FALSE
                  - FALSE : bJourSemaine=TRUE
              - Si SYSTEM_DAY_OF_WEEK = Vendredi OU SI
                   SYSTEM_DAY_OF_WEEK = Samedi
                  - TRUE  : bVeilleWeekend=TRUE
                  - FALSE : bVeilleWeekend=FALSE
              - nTriggerJourSemaineOK = nTriggerJourSemaineOK + 1
                         

L'automate se déclenche dès que la date système (SYSTEM_DATE) change, c'est-à-dire chaque jour à minuit et son seul objectif est de déterminer si nous sommes en semaine et/ou la veille d'un weekend, les deux variables (publiques) bJourSemaine et bVeilleWeekend étant mises à jour en conséquence.

La variable nTriggerJourSemaineOK sert de déclencheur pour tous les autres automates qui auraient besoin de l'information "Jour de semaine" et/ou "Veille de weekend". Il s'agit d'un simple compteur.

N'oubliez pas de valider votre automate et de l'exécuter au moins une fois sinon vous devrez attendre minuit avant que vos variables soient mises à jour :-)

NB: c'est de toute manière un très bon test que de lancer un automate au moins une fois en manuel (sans attendre la condition du déclencheur), pour voir si tout se passe correctement. Le débogage des automates n'est pas toujours aisé car il n'y a pas de message d'erreur explicite (NDA: pour l'instant avec la version 1.3.52 du système). Une "erreur" qui arrive fréquemment est qu'une variable soit utilisée dans un calcul ou une condition alors qu'elle n'a pas été initialisée. Si c'est le cas, mettez temporairement un bloc "VAR" en début de votre automate et initialisez votre variable, sauvez et lancez l'automate une fois avant de retirer le bloc "VAR" et de sauver et relancer votre automate une nouvelle fois.
NB n°2: prenez comme habitude de nommer vos variables en les précédant de quelques caractères qui indiquent clairement le type de la variable. Ainsi, on utilise "b" pour une variable booléenne (par ex: bJourSemaine), "n" pour une variable numérique (ex: nMonCompteur), "h" pour une variable heures/minutes (ex: hHeureDuBain), "d" pour une variable date (ex: dAnniversaire), etc. De cette manière vous connaissez toujours le type de données qu'une variable contient. Ainsi, si vous voyez une variable qui s'appelle bJourSemaine et une autre qui est jJourSemaine, laquelle est un flag qui indique si aujourd'hui est un jour de semaine et laquelle contient le nom du jour courant ?

Automate: Heures de Nuit

Maintenant que nous savons si la date du jour est en weekend ou en veille de weekend, nous pouvons déterminer l'heure de début et de fin de la nuit. Pour cela, nous créons un nouvel automate appelé "Heures de Nuit" qui lui aussi se déclenchera à chaque changement de date.

Automate  : Heures de Nuit
Variables : bJourSemaine (booléen - public)
            bVeilleWeekend (booléen - public)
            hStartNuit (heure - public)
            hEndNuit (heure - public)
            nTriggerJourSemaineOK (numérique - public)
Démarrage auto : NON
Déclencheur : A chaque changement de 
              nTriggerJourSemaineOK
Logique     : - START
              - Si bVeilleWeekend = TRUE
                  - TRUE  : hStartNuit = 23:00
                  - FALSE : hStartNuit = 22:00
              - Si bJourSemaine = TRUE
                  - TRUE  : hEndNuit = 06:00
                  - FALSE : hEndNuit = 08:00
                         

Vous remarquerez que j'ai utilisé le déclencheur nTriggerJourSemaineOK qui est incrémenté par l'automate "Jour de Semaine et Veille de Weekend". Donc, chaque jour à minuit, ces deux automates se déclencheront mais en succession: d'abord "Jour de Semaine et Veille Weekend" et ensuite "Heures de Nuit". L'utilisation de ce trigger garantit un déclenchement séquentiel. Si on avait utilisé le même déclencheur (SYSTEM_DATE), rien ne garantissait l'ordre de déclenchement de ces deux automates. Or cet ordre est primordial dans notre cas.

Pourquoi avoir fait deux automates plutôt qu'un seul? Tout simplement parce que chaque automate a une fonction bien déterminée. L'un d'eux détermine si on est en semaine alors que l'autre détermine des horaires potentiels de chauffage. Leur fonction étant vraiment différente, il vaut mieux les séparer. D'ailleurs lorsque nous nous occuperons de gérer les jours de congé (comme demandé par notre scénario originel), nous devrons modifier le déclencheur de l'automate "Heures de Nuit" (puisque la veille d'un congé, c'est comme la veille d'un weekend, la nuit commence à 23h plutôt que 22h et qu'un jour de congé est comme un jour de weekend, la nuit termine à 8h plutôt qu'à 6h). Cette modification (future) de déclencheur prouve que scinder les automates selon leur fonction est une bonne pratique.

Application de l'horaire

Il ne nous reste plus grand chose à faire pour appliquer nos "heures de nuit" à notre thermostat. En simplifiant, il suffit de créer un automate qui selon l'heure système va appliquer le régime Confort ou le régime Economique selon qu'on est en journée ou en nuit. Bien sûr à ce stade-ci on ne gère pas encore les facteurs de présence, congés et autres vacances, mais chaque chose en son temps :-)

Notre règle est simple:

  • Si l'heure courante est supérieure à hStartNuit OU inférieure à hEndNuit, alors on est en régime Eco
  • Sinon on est en régime Confort

Il reste à déterminer sur quel déclencheur activer cet automate ? Après tout, les variables hEndNuit et hStartNuit pourraient servir de déclencheur.
Par exemple, déclenche l'automate:

  • Dès que l'heure courante (SYSTEM_TIME) est supérieure à hStartNuit
  • OU
  • Dès que l'heure courante (SYSTEM_TIME) est supérieure à hEndNuit
Ca pourrait fonctionner (la condition dès que ne s'enclenche qu'une fois -- relisez le manuel utilisateur des modules logiques si vous avez un doute) mais vous devriez "sentir" que lorsque cet automate va se complexifier (notamment quand on y ajoutera les facteurs présence/absence, congés, vacances, etc.) cela ne suffira plus et que le déclencheur va être difficile à maintenir.

Si par contre on décide que cet automate se déclenche toutes les minutes, on obtient un déclencheur simple, qui ne nécessitera pas d'être révisé et qui aura une grande réactivité (dans la minute). Il suffit donc de créer un déclencheur sur tout changement de la donnée SYSTEM_TIME. A noter qu'en français cette donnée s'appelle "Heure" mais qu'il s'agit en réalité des heures+minutes (donc par ex: 17h23) et qu'il s'agit bien d'un changement toutes les minutes et pas toutes les heures.

"Mets-toi à ma place, Stephen !" (Les Inconnus)

A ce stade-ci, on va commencer à combiner les "effets" de plusieurs automates. Mettez-vous à la place du "process" et posez-vous la question: est-ce que mes différents automates fonctionneront correctement ensemble ? Créez des situations hypothétiques, à différents moments clés. Dans notre cas, prenez comme exemple un jour banal, comme "Vendredi à 15h20". A ce moment précis, si vous parcourez la logique de vos automates, quel devrait être le régime du thermostat ?

L'automate "Jour de semaine et veille de weekend" s'est déclenché la dernière fois ce vendredi à minuit. La logique de cet automate veut que (suivez avec votre doigt ou votre souris, ligne par ligne, condition par condition, point par point):

  • La première condition renvoie FALSE car le jour n'est ni Samedi ni Dimanche
  • Par conséquent bJourSemaine vaut TRUE, ce qui est correct: le vendredi EST un jour de semaine
  • La deuxième condition renvoie TRUE également car le jour EST un Vendredi (ou un Samedi)
  • Par conséquent bVeilleWeekend vaut TRUE, ce qui est correct: le vendredi EST une veille de week-end

L'automate "Jour de semaine et veille de weekend" incrémente un trigger qui déclenche automatiquement l'automate "Heures de Nuit":

  • La première condition est TRUE puisque bVeilleWeekend vaut TRUE (le vendredi EST une veille de weekend).
  • Par conséquent, le vendredi, la nuit commence à 23h
  • La deuxième condition est TRUE puisque bJourSemaine vaut TRUE (le vendredi EST un jour de semaine)
  • Par conséquent, le vendredi, la nuit se termine à 6h du matin

NB:Il est primordial de bien comprendre que la nuit, le vendredi, commence à 23h, mais que, QUAND ON EST UN VENDREDI, elle se termine à 6h du matin. Le "6h" correspond bien à l'heure de fin de nuit (ou de début de jour) du vendredi et PAS de la fin de nuit du vendredi au samedi !

Si on applique les règles de notre dernier automate (que nous n'avons pas encore écrit):

  • Si l'heure courante est supérieure à hStartNuit OU inférieure à hEndNuit, alors on est en régime Eco
  • Sinon on est en régime Confort
Or, l'heure courante est 15h20, ce qui n'est NI supérieur à 23H (hStartNuit) NI inférieur à 6h (hEndNuit), il faut donc appliquer le régime Confort.

A présent, refaites le même exercice de mise en situation avec des dates comme "Vendredi 22h", "Vendredi 23h", "Samedi minuit", "Dimanche 6h", "Lundi minuit", etc. Assurez-vous, point par point, que la logique est suivie et que le régime correspond à vos attentes.

Ce petit exercice parait fastidieux mais lorsque vous aurez dix automates qui s'entrecroisent et interagissent ensemble, il vous permettra en réalité de gagner du temps.

Automate: Sélection Auto du Régime

Créez un nouvel automate et nommez-le "Sélection Auto du Régime". La fonction de cet automate sera de SELECTIONNER un régime de thermostat sur base des horaires dans un premier temps, puis en prenant compte un certain nombre de dérogations dans un second temps. Il se déclenche sur SYSTEM_TIME, c'est-à-dire toutes les minutes.

Automate  : Sélection Auto du Régime
Variables : hStartNuit (heure - public)
            hEndNuit (heure - public)
            rRegimeAutoDemandé (mode chauffage - public)
Démarrage auto : NON
Déclencheur : A chaque changement de SYSTEM_TIME
Logique     : - START
              - Si SYSTEM_TIME >= hStartNuit OU
                   SYSTEM_TIME < hEndNuit
                  - TRUE  : rRegimeAutoDemandé = ECO
                  - FALSE : rRegimeAutoDemandé = CONFORT
              
                         

Le code est donc très simple à ce stade. Remarquez que les conditions sur SYSTEM_TIME sont "supérieur OU égal (à hStartNuit)" et "STRICTEMENT inférieur (à hEndNuit)". La fin de la nuit est donc en réalité à 5h59 (ou 7h59 en weekend). Le jour (et donc le chauffage) commencent bien à 6h (ou 8h en weekend).

Vous remarquerez également que cet automate n'active pas vraiment un régime de thermostat: il initialise une variable régime (ce qui explique le "r" au début du nom de la variable rRegimeAutoDemandé).

Encore une variable de plus ! Pourquoi ? Parce que de cette manière, cette variable peut servir de trigger pour un autre automate qui gérera non seulement notre thermostat prévu en début d'article mais aussi éventuellement d'autres choses qui suivraient les mêmes horaires (un autre thermostat par exemple) ou qui auraient un intérêt à connaître ce qui a été demandé comme régime (une chaudière par exemple pourrait se mettre en mode Réduit si tous les thermostats de la maison sont en mode Réduit).

Créons donc rapidement un automate pour remplir cette fonction

Automate: Activation du Régime

Créez un nouvel automate et nommez-le "Activation du Régime". La fonction de cet automate sera d'ACTIVER un régime de thermostat. Il se déclenche sur le changement de rRegimeAutoDemandé. Evidemment pour que cet automate fonctionne il vous faudra avoir un thermostat sur votre bus KNX, paramétré de manière à accepter des régimes de fonctionnement sous forme de Byte (octet). Notez qu'avec quelques modifications cela peut aussi fonctionner avec des régimes de fonctionnement sous forme de Bits.

Automate  : Activation du Régime
Variables : rRegimeAutoDemandé (mode chauffage - public)
Démarrage auto : NON
Déclencheur : A chaque changement de rRegimeAutoDemandé
Logique     : - START
              - Si rRegimeAutoDemande = CONFORT
                  - TRUE  : Thermostat Mode CONFORT
                  - FALSE : Si rRegimeAutoDemande = ECO
                      - TRUE  : Thermostat Mode ECO
                      - FALSE : Si rRegimeAutoDemande = REDUIT
                          - TRUE  : Thermostat Mode REDUIT
                          - FALSE : Si rRegimeAutoDemande = HORS_GEL
                              - TRUE  : Thermostat Mode HORS_GEL
                              - FALSE : rien
              
                         

Rien de bien particulier ici. Comme expliqué un peu plus haut, vous pouvez adapter et complexifier cet automate à votre guise. Cela peut être le point de départ d'une gestion beaucoup plus complexe du chauffage d'une maison.

Premiers tests

Si vous avez bien suivi, point par point, toutes les logiques dont nous avons parlé jusqu'à présent, alors vous avez un thermostat KNX qui est réglé sur un horaire. Évidemment ca ne s'arrête pas là car sinon on aurait pu faire beaucoup plus simple en utilisant les modules "Scénarios" et les "Plannings" de la Lifedomus. Nous avons choisi d'utiliser les modules logiques de Lifedomus parce que ce que nous voulons réaliser est en réalité beaucoup plus complexe que planifier des scénarios.

Une des premières choses que nous devrions régler à présent est le fait que si on active un régime directement sur le thermostat (ou avec un widget Lifedomus lié au même thermostat), dans la minute, l'ancien régime est à nouveau sélectionné. C'est normal puisque l'automate "Sélection Auto du Régime" s'active toutes les minutes et tenant compte de l'horaire, va activer l'automate "Activation du Régime".

On pourrait décider de désactiver le changement de régime par le thermostat mais dans ce cas on perd une fonctionnalité. Ne pourrait-on pas plutôt détecter que quelqu'un a changé le régime du thermostat et que donc (au moins pour un temps), l'horaire est désactivé ?

On pourrait donc imaginer que la Lifedomus surveille le régime du thermostat et que dès que celui-ci change, on met une variable, qu'on appelerait bModeManu, à TRUE. Et dans l'automate "Sélection Auto du Régime", si bModeManu vaut TRUE, alors on ne fait rien, on ne suit pas d'horaire et on ne sélectionne pas de régime de chauffage non plus.

Ca pourrait marcher, non ? Il y a cependant deux problèmes.

Désactivation du mode Manu

D'abord il faudra penser à un moment ou un autre à remettre bModeManu à FALSE sinon on ne suivra plus jamais les horaires prévus. Il y a à cela plusieurs solutions: on pourrait appuyer sur un bouton ou sur un widget Lifedomus ou bien cela pourrait être associé à une autre action domotique (pas de mouvement détecté dans la pièce du thermostat? quitter la maison? activer l'alarme?).

Une solution très élégante serait de réactiver l'horaire dès qu'il est hStartNuit ou hEndNuit (ou toute autre variable d'heure). On pourrait aussi envisager de réactiver l'horaire après un laps de temps. On se rapproche alors d'une dérogation. Vient alors la sempiternelle question: combien de temps de dérogation ? On pourrait aussi décider qu'on réactive l'horaire le lendemain à une heure bien déterminée. Oui mais quelle heure ? En pleine nuit quand a priori tout le monde dort ca semble pas mal. Oui, mais ... et si on ne dort pas ?

Comme vous le voyez, il n'y a pas de réponse universelle à ce premier problème. Chaque cas est différent et pour faire un choix correct il faut bien étudier la maison, les habitudes des habitants, la domotique à disposition et la raison pour laquelle on changerait le thermostat de régime alors qu'il est sous horaire.

Dans notre cas, vu que nous verrons comment mettre en place une forme de dérogation temporelle un peu plus loin dans le texte lorsque nous traiterons des congés et des vacances, nous allons simplement utiliser un bouton poussoir qui a déjà une utilité dans la maison (et qui fait partie du scénario): le bouton de présence/absence. A chaque fois qu'il sera activé, nous remettrons bModeManu à FALSE.

Qui a changé de régime sans prévenir ?

Le deuxième problème est que vouloir mettre bModeManu à TRUE dès que le régime du thermostat change c'est très bien, mais n'oublions pas que les automates de la Lifedomus changent aussi le régime du thermostat ! Cela signifie donc que dès cet instant les horaires seront désactivés. Donc notre automate "Sélection Auto du Régime" fonctionnera une fois et puis plus jamais.

Il faut donc trouver un moyen de différencier un changement de régime par un habitant, d'un changement de régime par automate/horaire pour éviter de mettre bModeManu à TRUE à tout bout de champ.

La solution consiste à utiliser un flag supplémentaire qui sera mis à TRUE lorsque que c'est un automate qui change le régime, juste le temps de changer le régime et puis il retombe à FALSE.

Intégrons tout cela dans des automates.

Automate: Gestion Mode Manu

Créez un automate que vous appelez "Gestion Mode Manu". Sa fonction sera d'ACTIVER le mode manu si un habitant change le régime ou la consigne du thermostat. Si par contre c'est un automate qui est responsable du changement, il ne se passe rien. Le mode manu n'est pas désactivé dans cet automate.

Automate  : Gestion Mode Manu
Variables : bModeManu (booléen - public)
            bParLD (booléen - public)
Démarrage auto : NON
Déclencheur : A chaque changement du régime du Thermostat OU
              A chaque changement de la consigne du Thermostat
Logique     : - START
              - Si bParLD = FALSE
                  - TRUE  : bModeManu = TRUE
                  - FALSE : bParLD = FALSE

Le trigger de cet automate est un peu différent puisqu'il comprend deux conditions sur des "états" du thermostat. Il est clair que si vous désirez gérer plusieurs thermostats il faudra multiplier les conditions du déclencheur.

La variable bParLD est le flag qui indique si l'action a été initiée par la LifeDomus ou pas. Si bParLD vaut TRUE, la seule chose qu'on fait c'est le mettre à FALSE. Si bParLD vaut FALSE quand on change le régime ou la consigne du thermostat, c'est que ce n'est pas un automate de la Lifedomus qui l'a changé.

Automate: Activation du régime (version 2)

Il faut à présent légèrement modifier l'automate "Activation du régime" pour y initialiser la variable bParLD à TRUE, indiquant ainsi que c'est bien la Lifedomus qui a modifié le régime du thermostat.

La nouvelle logique est la suivante (les modifications sont repérées par des flèches bleues):

Automate  : Activation du Régime
Variables : rRegimeAutoDemandé (mode chauffage - public)
Démarrage auto : NON
Déclencheur : A chaque changement de rRegimeAutoDemandé OU
              dès que bModeManu = FALSEnewline
Logique     : - START
              - bParLD = TRUEnewline
              - Si rRegimeAutoDemande = CONFORT
                  - TRUE  : Thermostat Mode CONFORT
                  - FALSE : Si rRegimeAutoDemandé = ECO
                      - TRUE  : Thermostat Mode ECO
                      - FALSE : Si rRegimeAutoDemandé = REDUIT
                          - TRUE  : Thermostat Mode REDUIT
                          - FALSE : Si rRegimeAutoDemandé = HORS_GEL
                              - TRUE  : Thermostat Mode HORS_GEL
                              - FALSE : rien
              
                         

Pour insérer le bloc bParLD = TRUE, il suffit de cliquer sur la flèche entre le bloc START et le premier IF.

Remarquez que la logique de déclenchement a changé également pour que l'automate soit déclenché soit à chaque changement de rRegimeAutoDemandé (c'était déjà le cas avant), soit dès qu'on quitte le mode manu, pour être sûr de ré-activer le bon régime de chauffage.

En effet, imaginons qu'à midi le thermostat et la variable rRegimeAutoDemandé soient en mode ECO et que les horaires sont actifs (bModeManu vaut donc FALSE). On actionne manuellement le thermostat pour mettre le mode CONFORT. A ce moment, on bascule en mode Manu (bModeManu vaut donc TRUE) et les horaires sont, du coup, désactivés.

Un peu plus tard, à 13h, on désactive le mode manu (en appuyant sur le bouton de présence/absence) et on se met en "Absence". Dans la minute, l'automate "Sélection Auto du Régime" va se lancer et déterminer qu'à cette heure-là on doit être en mode ECO. Or, la variable rRegimeAutoDemandé vaut déjà "ECO" et donc l'automate "Activation du régime" n'est pas déclenché, et le thermostat ne passe PAS en mode ECO. SAUF SI on demande que l'automate "Activation du régime" soit également déclenché si on quitte le mode manu. Ce que nous avons fait dans la modification reprise ci-dessus. Dans ce cas, juste après avoir appuyé sur le bouton absence/présence, l'automate "Activation du régime" est déclenché et le thermostat se met bien en mode ECO.

N'oubliez pas de sauver et de revalider votre automate après la sauvegarde.

Automate: Mode présence/absence

Le mode Manu est désactivé dans l'automate qui va gérer le mode présence/absence.

Créez un nouvel automate et appelez-le "Basculement absence/présence". La seule fonction de cet automate est de désactiver le mode Manu (et donc de rétablir la gestion automatique par horaires).

Le déclencheur est, dans mon cas, un objet KNX qui correspond à un appui sur un bouton de commutation mais vous pouvez bien sûr imaginer un autre mécanisme à partir d'un widget Lifedomus, par exemple, si vous le souhaitez.

Cet automate pourrait évoluer plus tard pour gérer toute une série d'actions liées au fait qu'on quitte la maison ou qu'on y revient. On pourrait intégrer l'activation de l'alarme, l'extinction des éclairages, l'abaissement des volets et vice-versa selon qu'on est "présent" ou "absent".

Automate  : Basculement absence/présence
Variables : bModeManu (booléen - public)
Démarrage auto : NON
Déclencheur : A chaque changement de 
              l'objet KNX "Commutation bouton présence/absence"
Logique     : - START
              - bModeManu = FALSE

Automate: Sélection Auto du régime (version 2)

La modification suivante consiste à vérifier que le mode manu est bien désactivé lorsqu'on exécute l'automate "Sélection Auto du Régime". Pour cela, on va rajouter une condition à l'entrée de l'automate.

Pour insérer cette condition, cliquer sur la flèche entre le bloc START et le premier IF. Créez un nouveau bloc IF. Les conditions TRUE et FALSE pointent toutes les deux sur le bloc IF qui existait déjà.

Or, notre nouvelle condition sera "IF bModeManu = TRUE" et dans le cas où elle serait vraie, on ne fait rien. Il faut donc supprimer la flèche qui va de TRUE au bloc IF pour ne laisser que la flèche qui part de FALSE.

Pour cela, il suffit de tirer une nouvelle flèche depuis le TRUE et de sélectionner un nouveau bloc à ajouter (peu importe lequel). Lorsque le nouveau bloc est créé, vous constaterez qu'il n'y a plus de flèche menant vers l'ancien bloc IF.

Il ne vous reste plus qu'à effacer le bloc nouvellement créé et vous aurez le résultat escompté. Editez la condition du bloc IF pour qu'elle corresponde à "IF bModeManu = TRUE", sauvez et validez votre automate.

Nous allons profiter du fait que nous sommes en train d'éditer cet automate pour modifier l'horaire selon le mode présence/absence. Rappelons rapidement le comportement désiré:
En journée,

  • si il y a quelqu'un à la maison, le chauffage doit passer en régime Confort
  • si il n'y a personne, le chauffage doit être en régime Economique SAUF SI on est en semaine (du lundi au vendredi donc) et qu'il est passé 16h (je reviens du boulot vers 17h et je voudrais que la maison soit chaude quand je rentre)

Il va donc falloir rajouter des comparaisons sur SYSTEM_TIME, par rapport à une autre heure, que nous appelerons "heure de préchauffage". Dans notre scénario, l'heure de préchauffage vaut 16h00.

Si nous décidons de mettre cette heure dès à présent dans une variable, nous pourrons donner à l'utilisateur la possibilité de la modifier au jour le jour s'il le désire. Cela pourrait être utile si pour une fois on rentre plus tôt du boulot et cela permettrait d'économiser de l'énergie si, au contraire, on rentre plus tard.

Si, par contre, nous laissons cette heure/valeur ("16h00"), figée, "hardcodée", dans un automate, le seul moyen qu'on aura de la changer, si on rentre plus tard ou plus tôt du boulot, sera d'éditer l'automate ce qui n'est pas très pratique.

Nous placerons donc cette heure dans une variable appelée hPrechauffage.

Il y a plusieurs manières de "traduire" cette règle en une succession de IFs. On pourrait la retranscrire telle quelle et ça donnerait quelque chose comme:

- Si SYSTEM_TIME >= hStartNuit OU
     SYSTEM_TIME < hEndNuit
    - TRUE (on est en nuit) : rRegimeAutoDemandé = ECO                        
    - FALSE (on est en jour) : Si objet_KNX_Présence = TRUE
        - TRUE : rRegimeAutoDemandé = CONFORT
        - FALSE : Si bJourSemaine = TRUE ET QUE
                     SYSTEM_TIME > hPrechauffage
            - TRUE : rRegimeAutoDemandé = CONFORT
            - FALSE : rRegimeAutoDemandé = ECO 

J'ai cependant choisi une autre transcription.

Comme nous sommes en train de sélectionner un régime de chauffe en fonction d'un horaire, j'ai décidé que mes IFs se concentreraient d'abord à déterminer dans quelle tranche horaire de la journée nous sommes. Au final cela donne un code légèrement plus long, mais plus flexible en cas de modification. En effet, imaginons qu'on étoffe le code pour tenir compte d'un horaire de déjeuner ou d'un horaire de bain ou d'un horaire "invités". Le code sera plus facile à maintenir si on détermine d'abord dans quelle tranche horaire on est plutôt que de faire des exceptions du genre "si la maison est vide on est en mode Economoique SAUF SI... ceci et SAUF SI... cela ... etc.".

Je le répète encore une fois: il y a plus d'une manière d'arriver au même résultat. Certaines techniques sont meilleures que d'autres mais tout dépend de ce que vous voulez faire après. Prévoyez maintenant, pour éviter de recommencer plus tard.

Bref, voici la logique révisée de l'automate, en essayant de travailler d'abord par tranches horaires:

Automate  : Sélection Auto du Régime
Variables : hStartNuit (heure - public)
            hEndNuit (heure - public)
            rRegimeAutoDemandé (mode chauffage - public)
            bModeManu (booléen - public)
Démarrage auto : NON
Déclencheur : A chaque changement de SYSTEM_TIME OU
              dès que bModeManu = FALSE
Logique     :
01 | - START                                                             
02 | - Si bModeManu = TRUE                                               
03 |     - TRUE  : rien                                                  
04 |     - FALSE : Si SYSTEM_TIME >= hStartNuit OU                       
05 |                    SYSTEM_TIME < hEndNuit                           
06 |         - TRUE  : rRegimeAutoDemandé = ECO                          
07 |         - FALSE : Si SYSTEM_TIME >= hEndNuit ET                     
08 |                    SYSTEM_TIME < hPrechauffage                      
09 |             - TRUE  : Si objet_KNX_Présence = TRUE                  
10 |                 - TRUE : rRegimeAutoDemandé = CONFORT               
11 |                 - FALSE : rRegimeAutoDemandé = ECO                  
12 |             - FALSE : Si SYSTEM_TIME >= hPrechauffage ET            
13 |                       SYSTEM_TIME < hStartNuit                      
14 |                 - TRUE  : Si objet_KNX_Présence = TRUE              
15 |                     - TRUE : rRegimeAutoDemandé = CONFORT           
16 |                     - FALSE : Si bJourSemaine = TRUE                
17 |                         - TRUE : rRegimeAutoDemandé = CONFORT       
18 |                         - FALSE : rRegimeAutoDemandé = ECO          
19 |                 - FALSE : rien (impossible)                         

Remarquez que j'ai changé également le déclencheur. Dorénavant l'automate s'enclenche toute les minutes ou si on désactive le mode manu. Le but, cette fois-ci, étant d'éviter d'attendre une minute (maximum) après qu'on a désactivé le mode manu.

Mets toi à ma place, Stephen (2e clap)

Nous avons présent plusieurs automates qui interagissent entre eux de manière relativement complexe. Est-on vraiment sûr que tout va se dérouler comme prévu ? Par exemple, que se passe-t-il le Samedi à 18h23 ?

L'automate "Sélection Auto du Régime" se déclenche toutes les minutes, donc il se déclenche aussi à 18h23. La première condition (ligne 2) demande si on est en mode Manu. Si on a activé un thermostat manuellement auparavant, ce sera le cas; on sort directement de l'automate. L'automate se ré-enclenchera à 18h24 et testera encore la condition en ligne 2. Et ainsi de suite.

Si la condition en ligne 2 est FALSE, à savoir que bModeManu n'EST PAS égal à TRUE, alors on passe à la condition de la ligne 4 et 5: est-on en nuit ? Non, donc on arrive à la ligne 7 et 8: est-on entre la fin de la nuit et l'heure du préchauffage (16h) ? Non, donc on arrive à la ligne 12 et 13: est-on entre l'heure de préchauffage et l'heure de début de nuit ? Oui. On passe à la ligne 14.

La ligne 14 vérifie l'objet KNX de présence. Si on est présent, alors on arrive en ligne 15 et on va demander le régime CONFORT. Si on est absent, on arrive en ligne 16, est-on un jour de semaine ? Non, puisqu'on est Samedi, on arrive donc en ligne 18 et on va demander le régime ECO.

L'automate "Activation Auto du Régime" ne se déclenche que si on demande un régime différent par rapport à la dernière fois, donc uniquement si on a changé le contenu de la variable rRegimeAutoDemandé par rapport à la minute précédente (puisque l'automate "Sélection Auto du Régime" se déclenche toutes les minutes). Or il est certain qu'à 18h22 (soit une minute avant), on avait déjà demandé le même régime. L'automate "Activation Auto du Régime" ne se déclenchera donc pas. Mais ce n'est pas grave, puisqu'a priori, nous sommes déjà dans le bon régime.

Refaites l'exercice de suivi point par point avec des situations du genre "Nous sommes tel jour, telle heure, je quitte la maison" ou "Un jour de semaine, que se passe-t-il du lever au coucher, sachant que je vais au boulot et que j'active (ou non) les modes présence/absence", "Je suis à la maison, j'ai trop chaud, j'actionne manuellement le thermostat en mode réduit, que va t-il se passer quand je vais désactiver le mode manu", etc.

Est-ce que tout fonctionne comme vous l'espérez ?

Préchauffage de la maison

A ce stade-ci, il ne manque qu'une seule chose pour que nos différents automates fonctionnent correctement. Il faut pouvoir donner librement une valeur à la variable hPrechauffage.

Le premier réflexe serait de créer un widget dans le Design Studio et sur un clic, de modifier la valeur de la variable. Malheureusement, la version actuelle (v1.3.52 au moment de rédiger ce tutoriel) ne permet pas d'éditer des variables de type "Heure" dans le Design Studio. Cette possibilité existera peut-être dans une future version, du moins espérons-le.

Nous allons donc faire à notre sauce, avec les outils à notre disposition. On va malgré tout utiliser le Design Studio car ses aspects "What I See" et "What I Do" sont plutôt sympas.

On pourrait imaginer un widget composé de 3 parties:

  1. Une visualisation de la valeur de la variable hPrechauffage
  2. Un bouton "-" qui permettrait de soustraire x minutes à la variable hPrechauffage
  3. Un bouton "+" pour ajouter x minutes à la variable hPrechauffage

La visualisation de la variable (point 1) est un classique "What I See". Par contre, il y a plusieurs manières d'appréhender le bouton "-" et "+".

Une première solution, peut-être la première qui vient à l'esprit, serait de créer deux automates, un qui incrémente hPrechauffage quand on clique sur le widget "+", et un autre qui décrémente cette variable quand on clique sur le "-".

Vous imaginez sans peine que si nous utilisons cette solution et si un jour vous souhaitez mettre en variable l'heure de fin de nuit pour un jour de semaine et celle pour un jour de week-end (heures que nous avons hardcodées dans nos automates à 6h et 8h respectivement) et que vous souhaitez faire la même chose pour l'heure de début de nuit en semaine et en veille de week-end (22h et 23h respectivement), nous aurons 5 variables x 2 automates, soit 10 automates rien que pour changer cinq consignes d'heure.

Bien que tout à fait viable, ne pourrait-on envisager d'avoir un automate par variable plutôt que deux ?

L'appui sur "+" ou "-" pourrait mettre à jour une variable, avec deux valeurs différentes. Le changement de valeur de cette variable servirait de déclencheur pour un automate qui relirait le contenu de la variable trigger pour déterminer s'il faut incrémenter ou décrémenter la consigne horaire.

Appelons cette variable trigger nIncrPrechauffage. Si on appuie sur "+" on la met à 1. Si on appuie sur "-" on la met à -1.

Créons un automate que nous appelons "Modifier Heure Préchauffage". Il se déclenchera à chaque fois que nIncrPrechauffage vaut 1 ou -1. Sa fonction est d'incrémenter ou décrémenter la variable hPrechauffage d'une heure.

Automate  : Modifier heure préchauffage
Variables : hPrechauffage (Heure - public)
            nIncrPrechauffage (numérique - public)
Démarrage auto : NON
Déclencheur : Dès que nIncrPrechauffage = -1 OU
              Dès que nIncrPrechauffage = 1
Logique     : - START
              - Si nIncrPrechauffage = 1
                  - TRUE  : Si hPrechauffage < 23h00
                      - TRUE  : hPrechauffage = hPrechauffage + 01h00
                      - FALSE : rien
                  - FALSE : Si hPrechauffage >= 01h00
                      - TRUE  : hPrechauffage = hPrechauffage - 01h00
                      - FALSE : rien
              - nIncrPrechauffage = 0

Remarquez les tests qui sont faits sur la variable hPrechauffage avant de l'incrémenter ou de la décrémenter. En effet, nous ne pouvons sortir de la gamme [00h00-23h59], il est donc impératif avant de faire l'opération arithmétique, de vérifier que, si nous la faisons, nous respectons cette gamme, sinon la variable contiendra une valeur invalide sur laquelle nous ne pourrons plus faire de calculs (et donc nos boutons "+" et "-" ne fonctionneront plus).

Remarquez également que nous remettons la variable nIncrPrechauffage à zéro avant de quitter l'automate, après avoir incrémenté ou décrémenté notre variable horaire, ceci afin qu'on puisse re-déclencher l'automate si on appuie plusieurs fois de suite sur "+" ou "-".

Question subsidiaire: ne devrait-on pas aussi remettre nIncrPrechauffage à zéro même si on n'a pas incrémenté/décrémenté la variable horaire ? Si vous pensez que oui, remettez-vous en situation et passez point par point, ligne par ligne, condition par condition, à la fois celles de l'automate et celles de la réalité, et vous verrez que ce n'est pas nécessaire.

Je ne vais pas m'attarder sur la manière dont il faut configurer les widgets "+" et "-" en "What I See"/"What I Do" dans le Design Studio, mais avec la capture d'écran à votre gauche vous avez déjà une idée du "What I Do" pour le bouton "-". La case à cocher ronde en haut à droite, si elle est cochée, indique que l'utilisateur a le droit d'écrire la valeur qu'il veut dans la variable. Ne la cochez donc pas.

Une dernière chose: rappelez-vous que vous devez donner à vos utilisateurs le droit de modifier la variable nIncrPrechauffage sinon vos widgets "+" et "-" ne fonctionneront pas !

On a gardé le meilleur pour la fin: les congés et les vacances !

Nous avons à présent un système qui fonctionne bien: nous avons un horaire en fonction des jours de la semaine et selon que nous sommes absents ou présents, l'horaire réagit différemment. Il ne nous reste plus qu'à traiter de deux types de dérogation: les congés et les vacances.

Quelle différence entre des congés et des vacances ? Il ne s'agit que d'un terme, mais dans cet article, on considère qu'on part en vacances et donc on n'habite plus dans la maison pendant quelques jours, quelques semaines ou quelques mois pour les plus chanceux; tandis qu'en congé, on reste à la maison alors que normalement on serait parti au boulot.

Gestion des congés

Puisqu'en "congé" on reste à la maison, pourquoi le mode "Présence" ne suffit-il pas ? Tout simplement parce que le mode "Présence" sert à dire qu'on est à la maison, mais pas qu'on est en "congé" et qu'on voudrait que la nuit démarre un peu plus tard (comme une veille de weekend) et se termine également un peu plus tard (comme un weekend).

Donc, quand on est en congé, on voudrait que

  • la veille du congé, le mode ECO se déclenche à 23h, comme la veille d'un weekend,
  • et que le jour du congé, on repasse en mode CONFORT à 8h, comme un jour de week-end.

Donc en gros, le comportement désiré est le même que la veille d'un week-end pour hStartNuit et le même qu'un jour de week-end pour hEndNuit.

En admettant qu'on mette dans une variable bCongé le fait qu'on est en congé (TRUE) ou pas (FALSE), on pourrait donc légèrement éditer l'automate "Heures de nuit" pour qu'il se comporte comme un jour de week-end et comme un jour de veille de week-end.

Automate  : Heures de Nuit
Variables : bJourSemaine (booléen - public)
            bVeilleWeekend (booléen - public)
            hStartNuit (heure - public)
            hEndNuit (heure - public)
            nTriggerJourSemaineOK (numérique - public)
            bCongé (booléen - public) newline
Démarrage auto : NON
Déclencheur : A chaque changement de nTriggerJourSemaineOK
              OU A chaque changement de bCongé newline
Logique     : - START
              - Si bVeilleWeekend = TRUE 
             OU Si bCongé = TRUE newline
                  - TRUE  : hStartNuit = 23:00
                  - FALSE : hStartNuit = 22:00
              - Si bJourSemaine = TRUE
             ET Si bCongé = FALSE newline
                  - TRUE  : hEndNuit = 06:00
                  - FALSE : hEndNuit = 08:00

Voila notre mode "congé" implémenté en quelques clics, à condition de mettre bCongé à TRUE la veille du congé ! Ça marche même si la période de congé couvre plusieurs jours: tant que bCongé reste à TRUE, le système considérera qu'on est en weekend et la veille d'un autre jour de weekend (en gros, en congé, tous les jours sont des Samedi).

Évidemment il faut encore penser à mettre bCongé à FALSE quand le congé est terminé. Pour s'éviter cela, on pourrait créer un automate qui mettrait bCongé à TRUE et un autre qui mettrait bCongé à FALSE et il suffirait de les planifier. Le seul problème c'est que pour cela il faut avoir accès au Config Studio, ce qui n'est pas le cas de l'utilisateur lambda.

Cependant, si au lieu d'une variable automate comme bCongé on avait un objet KNX (on bien un objet KNX dont l'état se refléterait dans la variable bCongé), on pourrait également utiliser des scénarios, qui ont, eux, l'avantage d'être planifiables depuis le Design Studio, c'est-à-dire depuis l'interface utilisateur.

On pourrait encore utiliser une autre solution en créant des widgets similaires à celui qu'on a implémenté pour gérer l'heure de préchauffage mais qui cette fois géreraient deux dates: les dates de début et de fin d'une période de congé. On aurait ensuite un automate qui se déclencherait dès qu'on dépasse la date de début et qui met bCongé à TRUE mais qui se déclencherait également dès qu'on dépasse la date de fin et qui dans ce cas met bCongé à FALSE.

La dernière solution dont nous parlerons ici (il y en a sûrement des dizaines d'autres), serait d'utiliser non pas un booléen mais un décompteur de jours de congé (qui activerait également l'automate "Heures de Nuit" à chaque changement de valeur).

On aurait une variable nJoursCongéRestant (qui contiendrait le nombre de jours de congé restant), qu'on initialiserait la veille d'un jour de congé (manuellement ou par un scénario ou un automate ou ...) en indiquant de combien de jours de congé on dispose. Chaque matin, à l'heure hEndNuit (8h puisqu'on est en congé), on décrémente nJoursCongéRestant. Si cette variable est encore supérieure à zéro c'est qu'il reste des jours de congé et donc hStartNuit commencera à 23h. Si par contre cette variable vaut zéro, c'est que c'est notre dernier jour de congé, et dans ce cas, hStartNuit commencera à 22h.

Dans ce cas, l'automate "Heures de Nuit" serait le suivant:

Automate  : Heures de Nuit
Variables : bJourSemaine (booléen - public)
            bVeilleWeekend (booléen - public)
            hStartNuit (heure - public)
            hEndNuit (heure - public)
            nTriggerJourSemaineOK (numérique - public)
            nJoursCongéRestant (numérique - public) newline
Démarrage auto : NON
Déclencheur : A chaque changement de nTriggerJourSemaineOK
              OU A chaque changement de nJoursCongéRestant newline
Logique     : - START
              - Si bVeilleWeekend = TRUE 
             OU Si nJoursCongéRestant > 0 newline
                  - TRUE  : hStartNuit = 23:00
                  - FALSE : hStartNuit = 22:00
              - Si bJourSemaine = TRUE
             ET Si nJoursCongéRestant = 0 newline
                  - TRUE  : hEndNuit = 06:00
                  - FALSE : hEndNuit = 08:00

Il suffit de joindre à cet automate un autre automate qui décompte les jours de congé:

Automate  : Décompte des congés
Variables : nJoursCongéRestant (numérique - public)
            hEndNuit (heure - public)
Démarrage auto : NON
Déclencheur : Dès que SYSTEM_TIME > hEndNuit
Logique     : - START
              - nJoursCongéRestant = nJoursCongéRestant - 1
              - Si nJoursCongéRestant < 0
                  - TRUE  : nJoursCongéRestant = 0
                  - FALSE : rien

L'automate "Décompte des congés" se déclenche dès que l'heure courante dépasse la fin de la nuit (8h puisqu'on est en congé). Comme il décrémente la variable nJoursCongéRestant, il enclenche automatiquement à sa suite l'automate "Heures de Nuit" qui ajustera les heures de nuit s'il ne reste plus de jours de congé.

Gestion des vacances

En vacances, on demande de mettre le thermostat en régime Réduit. Pour cela, il suffirait d'une variable booléenne, bVacances par exemple. Tout comme pour les congés, cette variable pourrait être commutée sur de nombreux événements: boutons poussoir, scénario planifié, etc.

Dans l'automate "Sélection Auto du Régime", il resterait à mettre une condition supplémentaire préalable pour passer en mode Réduit:

- START
- Si bVacances = TRUEnewline
    - TRUE  : rRegimeAutoDemandé = REDUIT newline
    - FALSE: Si bModeManu = TRUE newline
        - TRUE  : rien
        - FALSE : Si SYSTEM_TIME >= hStartNuit OU
                     SYSTEM_TIME < hEndNuit
            - TRUE  : rRegimeAutoDemandé = ECO
            - FALSE etc...

De cette manière, le mode "Vacances" outrepasse toute question d'absence/présence et d'horaires.

Bien sûr on peut également utiliser un décompteur de jours de vacances. Au moment de partir en vacances, on indique qu'on part pour X jours de vacances et on utilise le mécanisme d'heure de préchauffage pour indiquer que le jour où on rentre (donc le jour où il reste zéro jours de vacances), le chauffage doit se relancer à l'heure hPréchauffage.

On modifie donc légèrement l'automate "Sélection Auto du Régime" pour tenir compte d'un décompte de jour mais aussi pour simuler, le cas échéant, qu'on désire utiliser le mode de préchauffage comme si on était en semaine.

Automate  : Sélection Auto du Régime
Variables : hStartNuit (heure - public)
            hEndNuit (heure - public)
            rRegimeAutoDemandé (mode chauffage - public)
            bModeManu (booléen - public)
            nJoursVacancesRestant (numérique - public)
            bJourRetourVacances (booléen - public) newline
Démarrage auto : NON
Déclencheur : A chaque changement de SYSTEM_TIME OU
              dès que bModeManu = FALSE
Logique : 
01 | - START                                                               
02 | - Si nJoursVacancesRestant > 0newline                                      
03 |     - TRUE  : rRegimeAutoDemandé = REDUIT                             
04 |     - FALSE : Si bModeManu = TRUE                                     
05 |         - TRUE  : rien                                                
06 |         - FALSE : Si SYSTEM_TIME >= hStartNuit OU                     
07 |                      SYSTEM_TIME < hEndNuit                           
08 |             - TRUE  : rRegimeAutoDemandé = ECO                        
09 |             - FALSE : Si SYSTEM_TIME >= hEndNuit ET                   
10 |                          SYSTEM_TIME < hPrechauffage                  
11 |                 - TRUE  : Si objet_KNX_Présence = TRUE                
12 |                     - TRUE : rRegimeAutoDemandé = CONFORT             
13 |                     - FALSE : rRegimeAutoDemandé = ECO                
14 |                 - FALSE : Si SYSTEM_TIME >= hPrechauffage ET          
15 |                              SYSTEM_TIME < hStartNuit                 
16 |                     - TRUE  : Si objet_KNX_Présence = TRUE            
17 |                         - TRUE : rRegimeAutoDemandé = CONFORT         
18 |                         - FALSE : Si bJourSemaine = TRUE OU           
19 |                                   Si bJourRetourVacances = TRUEnewline     
20 |                             - TRUE : rRegimeAutoDemandé = CONFORT     
21 |                             - FALSE : rRegimeAutoDemandé = ECO        
22 |                     - FALSE : rien (impossible)                       

On modifie également l'automate de décomptes de jours de congé, pour qu'il décompte également les jours de vacances mais qu'il indique également si aujourd'hui est justement le jour de retour de vacances (dans la variable bJourRetourVacances), auquel cas il faut tenir compte de l'horaire de préchauffage.

Automate  : Décompte des congés et des vacances newline
Variables : nJoursCongéRestant (numérique - public)
            nJoursVacancesRestant (numérique - public) newline
            hEndNuit (heure - public)
            bJourRetourVacances (booléen - public) newline
Démarrage auto : NON
Déclencheur : Dès que SYSTEM_TIME > hEndNuit
Logique     : - START
              - nJoursCongéRestant = nJoursCongéRestant - 1
              - Si nJoursCongéRestant < 0
                  - TRUE  : nJoursCongéRestant = 0
                  - FALSE : rien
              - nJoursVacancesRestant = nJoursVacancesRestant - 1newline
              - Si nJoursVacancesRestant < 0newline
                  - TRUE  : newline
                      - nJoursVacancesRestant = 0newline
                      - bJourRetourVacances = TRUEnewline
                  - FALSE : bJourRetourVacances = FALSEnewline

Le déclencheur n'a pas changé. On aurait du plutôt créer un deuxième automate pour décompter les jours de vacances et on l'aurait déclenché sur changement de date à minuit. Cependant comme le décompte des jours de vacances n'a d'incidence que sur la gestion du préchauffage et que normalement ce préchauffage a lieu après l'heure de fin de nuit, cela ne pose pas de problème. A noter que pour que la gestion du préchauffage fonctionne comme espéré le jour de retour de vacances, il faut activer le mode "absence". Il serait sans doute bon d'activer le mode "absence" en même temps qu'on active le mode vacances. Je vous laisse gérer cela à titre d'exercice.

Vous remarquerez que le mode préchauffage, au retour de vacances s'active même le week-end puisque notre condition (en lignes 18 et 19 de l'automate "Sélection Auto du Régime") est qu'il faut être soit en semaine, soit le jour de retour des vacances.

Conclusion

Ici s'achève ce premier (très) long article/tutoriel sur les automates de la Lifedomus. Il y en aura certainement d'autres dans les prochaines semaines.

J'espère que cet article vous a plu et que vous avez appris de nombreuses choses, autant sur les fonctionnalités de la Lifedomus que sur la manière dont on programme un module logique, ainsi qu'une multitude de petites astuces qui vous serviront certainement un jour ou l'autre.

J'espère que ce tutoriel vous aura convaincu de la puissance de la Lifedomus mais aussi de l'expertise ou du moins de l'expérience d'OSMOTIQ en la matière.

Enfin, OSMOTIQ est votre partenaire pour toute installation domotique KNX avec ou sans serveur Lifedomus. Nous sommes à votre disposition.

N'hésitez pas à nous contacter. Vous trouverez nos coordonnées sur la page contact du site.