Schedule State (+ card) et VTherm - part. 2

Phagocytor · Avril 1, 2026, 8:30

Bonjour à tous,

J’ai suivi les fils parlant des sujets évoqués :

Très bien documentés, ça m’a permis de mettre en place tout le bazar, et en plus ça fonctionne bien royal

Pour aller un peu plus loin, j’ai 2 sujets que j’aimerais solutionner :

1 : J’ai essayé de mettre une condition liée à mon emplacement, mais ça ne fonctionne pas. Quand je dis « emplacement », c’est le tracker de mon téléphone (device_tracker.sm_s928u1) qui détermine si je suis à la maison / au taff / ailleurs grâce aux zones.
Je ne passe pas par un détecteur de présence, parce que avec 3 chats et 2 enfants, ça fausse les valeurs…
Ce que je voudrais, en gros, c’est mettre la condition « à la maison » les jours où je suis sensé être en TT (donc chauffage du bureau programmé), comme ça si je suis ailleurs, ça chauffe pas.
J’ai testé ça mais ça va pas, le schedule disparait de la carte :

conditions:
  - condition: zone
    entity_id:
      - device_tracker.sm_s928u1
    zone: zone.home

2 : Y aurait-il moyen d’avoir un switch pour basculer facilement sur une programmation « vacances hors de la maison », par exemple, sans avoir à se repalucher le sensors.yaml à chaque fois ?
Je sais que la carte ne pilote pas la config’ directement, elle n’est là que pour l’illustrer (et c’est bien dommage d’ailleurs), mais je ne vois pas comment faire simplement une bascule.
Au pire je me vois faire un fichier « sensors.yaml.back » avec la programmation « vacances » (personne à la maison) et j’alterne entre les 2 en les renommant, mais c’est pas super ergonomique.
Je précise que j’utilise déjà les conditions « workday » et « calendar.vacances_fr_zone_c » mais je voudrais une programmation pour une absence du domicile de plusieurs jours.
Pour illustrer le truc, en gros, le chauffage de la chambre de ma fille :

chauffe seulement de 16 à 22h les jours de lycée
chauffe de 12 à 22h les week-ends, les vacances scolaires et les jours fériés
et je voudrais qu’il chauffe pas si on est en vacances à Tombouctou (ou ailleurs)

Voilà voilà, toute aide est la bienvenue !
Si vous avez besoin de copies d’écran ou d’extraits de code, hésitez pas.
Et merci d’avance !

Ma configuration

System Information

version	core-2026.3.4
installation_type	Home Assistant OS
dev	false
hassio	true
docker	true
container_arch	aarch64
user	root
virtualenv	false
python_version	3.14.2
os_name	Linux
os_version	6.12.67-haos
arch	aarch64
timezone	Europe/Paris
config_dir	/config

Home Assistant Community Store

GitHub API	ok
GitHub Content	ok
GitHub Web	ok
HACS Data	ok
GitHub API Calls Remaining	5000
Installed Version	2.0.5
Stage	running
Available Repositories	2934
Downloaded Repositories	29

Home Assistant Cloud

logged_in	true
subscription_expiration	15 octobre 2026 à 02:00
relayer_connected	true
relayer_region	eu-central-1
remote_enabled	true
remote_connected	true
alexa_enabled	false
google_enabled	true
cloud_ice_servers_enabled	false
remote_server	eu-central-1-32.ui.nabu.casa
certificate_status	ready
instance_id	c86943899a184534936bd53fb4588230
can_reach_cert_server	ok
can_reach_cloud_auth	ok
can_reach_cloud	ok

Home Assistant Supervisor

host_os	Home Assistant OS 17.1
update_channel	stable
supervisor_version	supervisor-2026.03.2
agent_version	1.8.1
docker_version	29.1.3
disk_total	28.0 GB
disk_used	12.0 GB
nameservers	1.1.1.1, 2606:4700:4700::1111, 8.8.8.8, 192.168.1.254, 2001:4860:4860::8888
healthy	true
supported	true
host_connectivity	true
supervisor_connectivity	true
ntp_synchronized	true
virtualization
board	green
supervisor_api	ok
version_api	ok
installed_addons	Matter Server (8.3.0), Get HACS (1.3.1), Mosquitto broker (6.5.2), Zigbee2MQTT (2.9.1-1), Studio Code Server (6.0.1), Home Assistant Google Drive Backup (0.112.1), CEC Scanner (3.0), OpenThread Border Router (2.16.5), Music Assistant (2.8.1), AppDaemon (0.18.1)

Dashboards

dashboards	5
resources	14
views	14
mode	storage

Network Configuration

adapters	lo (disabled), end0 (enabled, default, auto), hassio (disabled), docker0 (disabled), vethd64a68f (disabled), veth980c88e (disabled), veth87dff2f (disabled), vethdd3af59 (disabled), veth04cd5eb (disabled), vethae89f0b (disabled), wpan0 (disabled), veth2180c47 (disabled), veth757c4da (disabled), vethada571d (disabled), vethcd2530b (disabled)
ipv4_addresses	lo (127.0.0.1/8), end0 (192.168.1.46/24), hassio (172.30.32.1/23), docker0 (172.30.232.1/23), vethd64a68f (), veth980c88e (), veth87dff2f (), vethdd3af59 (), veth04cd5eb (), vethae89f0b (), wpan0 (), veth2180c47 (), veth757c4da (), vethada571d (), vethcd2530b ()
ipv6_addresses	lo (::1/128), end0 (2a01:e0a:a3d:b240:459f:9e0c:d26a:953d/64, fe80::9ea6:6f03:3b9c:646c/64), hassio (fe80::e4c0:96ff:fe65:5aef/64), docker0 (fe80::98db:b4ff:fe22:5abb/64), vethd64a68f (fe80::64dd:20ff:fed7:82dc/64), veth980c88e (fe80::5c98:baff:fec2:8c39/64), veth87dff2f (fe80::9487:50ff:fe7f:614a/64), vethdd3af59 (fe80::3481:32ff:fe63:166d/64), veth04cd5eb (fe80::c48c:33ff:fe5e:b72c/64), vethae89f0b (fe80::cd6:76ff:fe1c:1892/64), wpan0 (fd53:77df:3ebb:ae91:0:ff:fe00:fc11/64, fdc7:82a7:bdad:1:e2cf:529b:cd6a:ffdb/64, fd53:77df:3ebb:ae91:0:ff:fe00:fc10/64, fd53:77df:3ebb:ae91:0:ff:fe00:fc38/64, fd53:77df:3ebb:ae91:0:ff:fe00:fc00/64, fd53:77df:3ebb:ae91:0:ff:fe00:6800/64, fd53:77df:3ebb:ae91:a09b:b93d:5cf3:ec8a/64, fe80::788f:85b:3ae4:7c10/64), veth2180c47 (fe80::acce:50ff:fee3:7b56/64), veth757c4da (fe80::c4b9:e6ff:fef4:e404/64), vethada571d (fe80::80ea:3aff:fe01:6b65/64), vethcd2530b (fe80::e0a8:2bff:feb4:2131/64)
announce_addresses	192.168.1.46, 2a01:e0a:a3d:b240:459f:9e0c:d26a:953d, fe80::9ea6:6f03:3b9c:646c

Recorder

oldest_recorder_run	21 mars 2026 à 04:04
current_recorder_run	1 avril 2026 à 09:38
estimated_db_size	775.27 MiB
database_engine	sqlite
database_version	3.49.2

Spotify

api_endpoint_reachable	ok

Pulpy-Luke · Avril 1, 2026, 9:01

Salut,

Merci pour ton retour, et super si tout fonctionne déjà bien !

Voici quelques éléments pour répondre à tes deux questions :

1. Conditions basées sur un device_tracker

Actuellement, la carte ne gère pas les conditions utilisant directement un device_tracker. Je n’ai pas non plus testé ce cas côté entité schedule_state, mais même si ça marchait techniquement, ce n’est peut‑être pas le comportement le plus adapté.

Dans ton scénario :

si tu quittes la maison en urgence même quelques minutes,
le smartphone sort de la zone « home »,
alors ton planning « télétravail » basculerait en mode absent… même si tu es censé travailler chez toi ce jour‑là.

Ce n’est pas forcément un problème, mais selon ton système de chauffage (une pac ou une vieille chaudière), ça peut créer des bascules fréquentes ou des comportements non souhaités.

De mon côté, je gère les jours de télétravail via des calendriers. Ça demande de maintenir le planning, mais c’est fiable et évite les changements d’état non voulus.

2. Mode vacances / absence prolongée

Pour la partie « switch vacances », c’est peu probable que la carte permette un jour de modifier directement la configuration YAML.
Il y a deux raisons principales :

Techniquement, cela nécessiterait une refonte complète du code de schedule_state et celui de la carte, notamment toute la gestion des flux. C’est un énorme chantier.
Pratiquement, le YAML apporte des avantages majeurs comme les ancres (&, *) pour factoriser les conditions (par exemple les règles de présence). Sans YAML, tu serais obligé de répéter les mêmes blocs dans plusieurs plannings — et de tout modifier à la main en cas d’évolution. C’est un confort que je n’ai pas envie de perdre non plus.

Pour gérer un mode vacances, le plus simple et le plus propre est d’utiliser un input_boolean (par exemple : input_boolean.vacances).
Tu peux ensuite l’intégrer dans tes conditions YAML pour activer un planning alternatif qui se déclenche uniquement quand ce mode est actif.

L’intérêt est double :

le planning “vacances” s’applique uniquement dans les bonnes conditions,
il surchage automatiquement les autres créneaux lorsqu’il apparaît en fin de liste, ce qui correspond exactement au fonctionnement prévu de l’intégration d’origine.

La carte, elle, est là pour t’aider à visualiser ces différents états.

vacances_15c: &vacances_15c
  name: "Mode Vacances (15°C)"
  start: "00:00"
  end: "23:59"
  state: 15
  conditions:
    - condition: state
      entity_id: input_boolean.vacances
      state: "on"

Avec les ancres, c’est facile de l’ajouter partout sur les planning suivants

       conditions:
          - <<: *vacances_15c

Phagocytor · Avril 1, 2026, 9:50

Ah super, merci de ta réponse rapide Pulpy !

Pour le 1 OK je m’en doutais, je vais voir éventuellement avec un calendrier.
Le soucis que tu évoques ne me concerne pas, je suis en électrique avec inertie, donc une coupure momentanée n’est pas gênante et la maison assez bien isolée, mais c’est pas grave, tant pis.

Pour le 2 très bien comme idée, je pense que ça irait bien, c’est facilement configurable, je place un bouton à cliquer sur le dashboard c’est nickel !.
Par contre je vais avoir besoin d’un peu d’aide pour le mettre en place :

1 : j’ai créé un input_boolean via l’UI mais du coup y’a juste un nom : input_boolean.vacances, pas de configuration.
2 : je ne vois pas où mettre le code que tu m’as donné. C’est au niveau de sensors.yaml ou de configuration.yaml ?

Voici un exemple d’un de mes schedules dans « sensors.yaml » :

- platform: schedule_state
  name: "Chauffage Bureau"
  default_state: "eco"
  events:
      - start: "07:15"
        end: "16:00"
        state: "comfort"
        condition:
          - condition: time
            weekday: [wed, thu]
          - condition: state
            entity_id: binary_sensor.workday_sensor
            state: "on"

Je le glisse là-dedans ?

Pulpy-Luke · Avril 1, 2026, 2:30

A voir quelle valeur tu veux mettre quand en vacances mais sur le principe c’'est pas plus compliqué que ça un fois que tu as ton créé l’entité via l’ui. Il ne fait rien donc par de config. Par contre adapte ensuite le yaml

- platform: schedule_state
  name: "Chauffage Bureau"
  default_state: "eco"
  events:
      - start: "07:15"
        end: "16:00"
        state: "comfort"
        condition:
          - condition: time
            weekday: [wed, thu]
          - condition: state
            entity_id: binary_sensor.workday_sensor
            state: "on"
      - start: "00:00"
        end: "23:59"
        state: "off"
        condition:
          - condition: state
            entity_id: input_boolean.vacances
            state: "on"

Adapte les heures si besoin

Phagocytor · Avril 2, 2026, 6:09

Génial !

Ça tourne comme une horloge, et du coup avec un simple bouton « on/off » comme je le voulais à la base !
Grand merci à toi, pour ton travail sur la carte et pour ta disponibilité ici auprès des utilisateurs, c’est super !

Juste un petit truc, qui pourrait m’aider aussi dans d’autres automatisations :
J’ai pas bien compris le truc des ancres, du coup dans le doute j’ai remis le même bout de code sur chaque schedule. Ça alourdit un peu le fichier mais c’est pas la mort.

Vu que ton ancre commence à la ligne conditions: en fait ça remplace juste les 3 dernières lignes

- condition: state
      entity_id: input_boolean.vacances
      state: "on"

de ton code ?
Remplacer 3 lignes par 1 seule, le gain est limité non ? Ou alors j’ai pas bien compris…

Pulpy-Luke · Avril 2, 2026, 7:47

Merci, à partir du moment ou je peux donner un coup de main, je le fais

Concernant les ancres, voici un petit exemple, tu commences par la créer &condition_vacances

- platform: schedule_state
  name: "Chauffage Bureau"
  default_state: "eco"
  events:
    - start: "07:15"
      end: "16:00"
      state: "comfort"
      condition:
        - condition: time
          weekday: [wed, thu]
        - condition: state
          entity_id: binary_sensor.workday_sensor
          state: "on"

    - start: "00:00"
      end: "23:59"
      state: "off"
      condition:
        - &condition_vacances
          condition: state
          entity_id: input_boolean.vacances
          state: "on"

Et tu réutilise ce petit nom pour une autre déclaration

- platform: schedule_state
  name: "Chauffage Chambre"
  default_state: "eco"
  events:
    - start: "06:45"
      end: "08:30"
      state: "comfort"

    - start: "00:00"
      end: "23:59"
      state: "off"
      condition:
        - *condition_vacances

C’est assez puissant, ça fait gagner beaucoup de temps quand il s’agit d’ajuster, mais ça devient vite compliqué quand il y en a partout et que le yaml n’est pas un truc qu’on manipule facilement.
Dans il faut y aller progressivement. Et les IA là dessus, il faut se méfier, c’est pas hyper efficace/lisible

Phagocytor · Avril 2, 2026, 8:06

OK avec l’exemple je comprends mieux
Là pour le coup ça fait pas gagner grand chose (2 lignes) car la commande est ridicule, mais sur un gros bloc le gain est sympa, en écriture et en cas de modification.

Encore merci Pulpy !

Pulpy-Luke · Avril 2, 2026, 8:43

Ici le gain est faible mais quand il y a beaucoup de blocs aussi ça aide. Et quand la condition est compliquée (template) ça facilité grandement la lecture