Bonjour, j’ai des scheduler définis avec l’UI normale en plages horaires, pour mes vannes Sonoof pilotées par Vtherm, et j’aimerai bien tester cette visualistaion offerte par cette intégration.
Mais je vois qu’il faut les deux intégrations schedule_state et schedule_state_card, mais pour la schedule_state doit on définir des états ou est-ce dynamique via la schedule_state_card ?
Ou suffit il de les installer tels que défini dans la doc pour commencer à voir appraître mes plannings ?
Et pour les chedule actuels, peut on les laisser tels que définis via les UI de la carte scheduler ou faut il les réécrire en YAML ?
Désolé si je pose certainemnt des questions de béotien…
Les schedulers HA (ceux de l’UI) ne sont pas compatibles. Tu peux donc continuer à les utiliser et les modifier comme avant, cela ne change rien. Je les trouve personnellement trop basiques.
Le cas d’usage est le suivant : avec l’utilisation de schedule_state (une fois mis en place, et forcément en YAML), la carte ajoute une fonction de visualisation qui me semblait manquer (200 lignes de YAML, à un moment donné, c’est difficile à se représenter). La carte génère automatiquement un sensor spécifique qu’elle exploite pour l’affichage.
Cependant, la carte ne permet pas de modifier les schedule_state en retour. C’est un gros travail de réécriture, et je n’ai sans aucun doute pas le temps.
Personnellement, j’ai constaté (de manière générale) que la planification varie beaucoup pendant la phase de conception (d’où l’idée de la carte : voir ce que ça donne graphiquement), mais une fois terminée, elle évolue très peu.
Ok, mais si je comprends bien, vu mon usage des scheduler, plannings assez basiques pour chaque pièce, du moins tranches horaires avec consigne cible pour chaque tranche, ça risque de me compliquer la vie plus que la simplifier…
C’est surtout le côté visuel qui m’avait attiré, voir un petit schéma avec les barres horizontales qui montrent les tranches et les consignes par tranche et ou on en est, ça me semble sympa.
Mais peut etre est ce faisable simplement sur le scheduler standard ?
Non, malheureusement le scheduler standard c’est pas possible : les programmations ne sont pas lisibles dans les attributs, et pas non plus en yaml, donc pas moyen de retrouver le planning après sa création.
Dans l’absolu, tu peux refaire la même planification simple avec schedule_state , mais à toi de voir si ça vaut le coup
ok, mais meme en relisant la doc du schedule_state je ne vois pas trop comment il faudrait écrire ça pour définir ces plages et les cibles pour chaque Sonoff…
Je commence à comprendre, mais reste le lienavec le Vtherm, actuellement l’automatisation qui le pilote c’est le scheduler, je donne juste un préréglage par plage horaire.
Dois je imaginer que le schedule_state puisse posititionner une valeur de préréglage définie dans la config centrale Vtherm, je crois, dans une entrée (eco, confort, boost etc) ?
Sinon ça peut être une valeur numérique aussi… mais ce sont les préréglages que j’utilise actuellement.
Mais ensuite comment la passer au Vtherm …
Bon, je ne veux pas te prendre trop la tête car je suis un peu loin en terme de compréhension de tout ça … mais ça progresse
Oui enfin dans l’absolu, le scheduler c’est pas une automatisation même si ça fait un truc automatique
Exact, tu peux faire un schedule_state qui vaut n’importe quelle valeur
sensor:
- platform: schedule_state
name: "Chauffage de ma salle de bain"
default_state: "eco"
events:
- start: "08:00"
end: "10:00"
state: "confort"
condition:
- condition: time
weekday: [mon, tue, wed, thu, fri]
- start: "18:00"
end: "23:00"
state: "boost"
Avec une automatisation de ce genre
alias: Envoyer preset VTherm selon schedule SDB
description: >
Met à jour le mode 'preset' du thermostat de la salle de bain
(climate.sdb_vtherm) en reprenant l'état publié par le schedule
(sensor.chauffage_de_ma_salle_de_bain). Les états indisponibles ou non valides
(unavailable, null, unknown) sont ignorés.
triggers:
- alias: Changement d'état du schedule SDB
entity_id: sensor.chauffage_de_ma_salle_de_bain
trigger: state
conditions:
- alias: État compatible (non indisponible / non invalide)
condition: not
conditions:
- alias: Trigger est incompatible (unavailable/null/unknown)
condition: template
value_template: "{{ trigger.to_state.state in ['unavailable','null','unknown'] }}"
actions:
- alias: Appliquer le preset au thermostat SDB
target:
entity_id: climate.sdb_vtherm
data:
preset_mode: "{{ trigger.to_state.state }}"
action: climate.set_preset_mode
mode: single
C’est basique, mais l’idée est là. "{{ trigger.to_state.state }}" c’est la nouvelle valeur du preset qui vient de changer
Et donc la carte pourrait donner un truc comme ça (c’est un vrai truc à moi, donc il y a des conditions en plus)
whao, merci beaucoup, donc je ferai un schedule_state avec autant de « name » que de Vtherm à piloter, puis autant de blocs automatisation que de Vtherm aussi…
C’est donc le changement de valeur du state qui déclenchera l’automatisation et appliquera la nouvelle valeur au Vtherm.
Ai-je bien reformulé ?
Mais je vois que tu as plusieurs planification pour une même pièce ou Vtherm dans mon cas, moi je n’en aurai qu’un actuellement , un peu à l’image de la ligne 2 avec 3 plages…
Quioque, j’ai des planifications différentes sur 4 pièces si présences d’invités… donc ça ferai 2 lignes de visu, voire 3 si j’ajoute la conditions absence… etc…
Chaque ligne correspond à une condition (une variante de la planification) donc c’est exactement comme toi :
quand je suis dans le bureau pour bosser, ça chauffe (ligne #1)
quand les invités sont là (clic/clac dans le bureau) : on chauffe (ligne #2)
quand c’est l’été : on ne chauffe pas (ligne #3)
Et comme là il n’y a ni invité, que nous sommes en hiver que, je ne suis pas dans le bureau, ça applique/génère la combinaison qui ne contient que eco (issue de la ligne #0, en orange/active, par défaut)
Par défaut, on chauffe la maison à 17°C (#0)
Il y a 3 plages (fonctionnement en gros, dans les faits, il y beaucoup de conditions (pas les vacances etc)):
#1 et #3 qui s’appliquent tous les jours de la semaine (pas le WE)
la plage #2 ne s’active que quand il y a du TT
Parmis les inactives
la maison est vide (#4)
l’été (#5 je laisse ouvert les vannes pour éviter le colmatage => température maxi)
Donc au final, la composition reprends les plages actives et fusionne avec la valeurs par défaut
Alors hier soir j’ai tenté l’installation. Mais j’ai pas réussi pour appdaemon, il est installé mais comme il se met dans son propre jeu de répertoires et que je suis sous HAOS je n’ai pas accès à ces répertoires. Alors j’ai activé du Samba et je peux voir les répertoires HAOS via mon file explorer windows, je peux donc modifier les fichiers yaml.
Par contre dans le fichier apps.yaml on lui donne le chemin pour un /config/configuration.yaml qui semble être celui de HA ? et il dit toujours qu’il ne trouve pas ce chemin.
Voilà l’état de mes répertoires.
alors on dirait qu’il l’a lu, mais j’ai juste mis un yaml appelé schedule_config.yaml et qui ne contient qu’une ligne : « schedules: »
donc il fait des erreurs ensuite disant que ce yaml n’est pas ok et il est toujours idle.
je lui mets un contenu et je te dis !
Si tu as un fichier specifique, tu peux le mettre directement /homeassistant/schedule_config.yaml
Tu gagnes du temps à ne pas faire analyser le reste qui ne sert pas pour créer les cartes
En fait ça dépendant de comment est articulé ta config, avec les includes les blocs ‹ sensor › sont dans le fichier qui fait l’inclusion et pas de celui qui est inclus
Au départ tu proposes que le apps.yaml accède au configuration.yaml dans lequel on ajoute les sensors du schedule_state.
Là j’ai mis un sensor schedule_state dans un fichier à part que j’ai donné dans le apps.yaml
mais je ne l’ai pas inclus dans mon configuration yaml
donc inconnu de HA…
ca doit pas être bon non ?
et j’ai déjà un sensor.yaml qui est inclus, donc je peux utiliser ce sensor.yaml et mettre le lien configuration.yaml dans le apps.yaml ?
Tu dois faire en sorte que HA créer des schedule_state d’une part. C’est le fonctionnement de base. Sans cette partie là tu n’aura jamais les sensors de schedule_state et donc pas moyen de faire des automatisations par ex.
Pour avoir ma carte, il faut donner en plus à appdaemon ce même fichier yaml pour que le parsing soit fait. ça créer des entités spécifiques sensor.schedule_* que la carte affiche. Ces entité ne servent à rien d’autre.
… mais ça progresse 
