Schedule State Card – Visualisation avancée des plannings (nécessite schedule_state)

Dev
1

Bonjour à tous,

Après avoir joué une session de lowcode, je vous présente Schedule State Card, une carte personnalisée pour Home Assistant qui permet de visualiser vos plannings avec des états dynamiques et des conditions avancées. C’est un complément idéal à l’intégration schedule_state pour afficher des consignes de chauffage, des horaires d’éclairage ou tout autre automatisation basée sur le temps.

:warning: Important : cette carte ne fonctionne pas seule. Elle nécessite l’intégration schedule_state pour générer les entités sensor.schedule_* à partir de votre configuration YAML.

card

:white_check_mark: Fonctionnalités principales :

  • :spiral_calendar: Visualisation hebdomadaire : affiche le planning complet pour chaque jour.
  • :artist_palette: Couleurs dynamiques : basées sur les valeurs d’état (température, mode, etc.).
  • :chart_increasing: Mise à jour en temps réel avec indicateur de l’heure actuelle.
  • :counterclockwise_arrows_button: Valeurs dynamiques : support des templates Home Assistant et des références de capteurs.
  • :globe_showing_europe_africa: Multi-langue : anglais, français, allemand, espagnol.
  • :pencil: Éditeur visuel pris en charge : configuration facile sans YAML.
  • Σ Vue combinée : superposition des couches pour voir le résultat global.
  • :stopwatch: Format 12/24h automatique selon la configuration locale.

:page_facing_up: Documentation complète et exemples dans le README.

:link: Liens utiles :

16 « J'aime »
2

Hello @Pulpy-Luke ,

Belle réalisation ! Merci pour le partage

3

Salut Jean Marc.

Je ne pense pas que ce soit une trouvaille mais plutot @Pulpy-Luke qui l’a codée (la carte) :wink:

3 « J'aime »
4

Ah oui j’avais pas fait gaffe :sweat_smile:. Encore mieux alors !

1 « J'aime »
5

@Pulpy-Luke Bravo et merci pour le travail…et le partage

1 « J'aime »
6

Je vais m’empresser de l’installer !

Une question naïve (je n’ai jamais développé d’intégration). Si l’intégration a besoin de la carte car sinon on ne peut rien créer, et que la carte a besoin de l’intégration… Est-ce qu’il ne serait pas plus pratique de tout fournir ensemble ? Après ce n’est peut-être pas possible techniquement, je n’y connais rien…

7

L’intégration n’a pas besoin de la carte. Elle fournit des sensors et la carte de pulpy permet de les présenter d’une certaine manière. Tu pourrais très bien afficher les sensors de l’intégration dans des cartes tuiles ou autre.

8

Voilà un sujet qui tombe à point !
J’ai une question qui s’y rattache, car ça fait un certain temps que j’envisage de faire des automatisations basées sur des événements de planning. Mais ce qui m’a retenu jusqu’ici, c’était que dans la vie, il y a toujours des exceptions. Par exemple, admettons que le mercredi soir je veux prendre un bain, un jacuzzi, et que je veux le mettre en chauffe à l’avance.
Par contre, il peut arriver d’avoir un imprévu le mercredi, et de vouloir décaler mon bain au jeudi.

Est-ce qu’il y a une solution assez facile à mettre en œuvre pour décaler exceptionnellement une condition via un calendrier plutôt que via une bidouille ?

Sinon, toutes mes félicitations @Pulpy-Luke, j’ai hâte de tester ça !

Ps: ça reste un exemple, j’ai pas de jacuzzi. :laughing:

1 « J'aime »
9

L’intégration est autonome, elle offre de quoi faire un planning qui calcule l’état d’un sensor.
L’interêt que j’y trouve (en plus de la richesse des possibilités du yaml) c’est de justement de séparer la partie « planning » de la partie « action », et du coup d’utiliser des automatisations normales.

Par contre, au point de vue « informations » les sensors de shedule_state sont assez pauvres, et la carte est justement là pour combler ce manque.

Voilà en première ligne l’entité shedule_state qui sert de point de départ à la carte (en 2ème ligne)

image
image1637×772 30.1 KB

L’idée c’est de visualiser la logique shedule_state plus simplement.

10

Bah un planning c’est fait pour les trucs qu’on veut prévoir à l’avance.

Mais un exemple concret.

Mes chauffages sont gérés par un planning et bascule d’un mode nuit a eco, confort etc justement avec un planning différent en fonction des jours de la semaine.

Ça ne m’empêche pas en cas ou je suis à la maison de manière imprévu que le chauffage est en éco grâce au planning de monter son thermostat si j’ai trop froid ou de le changer de mode.

Le planning le rebasculera automatiquement au prochain changement prévu.

11

Pour donner un idée, le planning du chauffage se base sur :

  • l’état du chauffage
  • les valeurs de consignes modifiables
  • les présences/absences
  • les heures/jours théoriques semaine/samedi/dimanche
  • les spécificités jour férié et télétravail (plus chaud de 8H30 à 9H30)
  • la présence d’invités
  • boost de température sur une durée
  • le fait qu’on soit couchés ou pas pour éviter de chauffer dans le vide
  • la présence de la femme de ménage.

Très honnêtement j’ai essayé de faire ça avec le composant habituel du sheduler et c’était ingérable (graphiquement pas mal) mais bien trop complexe à maintenir
Là à partir du moment où tu sais estimer un peu l’imprévisible, il n’y a pas de limite

12

Merci à vous deux.
Je vais regarder ça.

Effectivement, la clé c’est de pouvoir forcer

13

Et même plus, de pouvoir forcer sans désactiver l’automatisme.

Tu as froid, tu force la chauffe (quelle que soit la façon de le faire) et l’automatisme se remet en marche à la prochaine bascule de la planification.

Sinon, c’est la porte ouverte à laisser le truc en full manuel (trop chaud ou trop froid…)

2 « J'aime »
14

Cette carte semble très intéressante et mérite d’être testée… je rajoute ça à ma liste des trucs à checker le week-end prochain !

Par contre je viens de passer 1 dimanche après-midi à réaliser une automatisation pour ma pompe de piscine : respect de 2 entrées “schedule” (1 schedule “été” et 1 “hiver”) avec une entrée booléenne manuelle pour la bascule entre l’un ou l’autre.
Je conserve la marche forcée sur ma pompe possible à l’aide d’une entité bouton classique.

vu que j’ai conditionné mes 2 automatismes sur le changement d’état de chaque schedule, si usage de la marche forcée, la reprise selon l’automatisme se fait dès qu’un event survient côté schedule ; c’est la seule “limitation” que je vois actuellement à mon automatisation.

Donc il me semble que c’est déjà possible de faire exactement ça… mais pas avec la belle forme que présentée dans la carte de @Pulpy-Luke ; j’ai tord ?

1 « J'aime »
15

Salut

Bonne idée de tester, j’ai effectivement besoin de retours
Donc à tester mais je pense que c’est parfaitement possible.

  • Un état calculé pour l’été (on/off ou même une durée) et un état pour l’hiver, possiblement à bascule automatique
  • La marche forcée qui bypass les 2 programmations précédentes

Et effectivement profiter de la visualisation

16

Hello, Merci pour le travail. Il faut bien “coder” les schedules dans le yaml ? Je cherche personnellement un moyen de pouvoir enlever/ajouter rapidement des jours dans un calendrier pour contrôler les modes de mon “versatile thermostat”.

Je ne suis pas souvent chez moi et je prête mon appartement à la famille et je voudrais pouvoir saisir rapidement les jours où le chauffage devra être allumé ou “hors gel”, voire de pouvoir faire ça depuis mon calendrier Mac ou Google et que ça synchronise !

J’ai installé Scheduler Card mais je trouve que l’ergonomie et la visualisation sont vraiment pas possibles. Vous avez des idées ?

17

Salut

Oui, le principe ici est simplement d’ajouter une surcouche visuelle à schedule_state qui fonctionne très bien et est extrêmement puissant. Donc oui sans codage yaml de planification, ça n’offre que peu d’intérêt.

Plusieurs planning qui se basent sur des conditions de calendrier pour être actif ou non.
Par exemple pas tester mais ça donne idée

sensor:
  - platform: schedule_state
    name: "chauffage_schedule"
    default_state: "15.0"
    extra_attributes:
      unit_of_measurement: "°C"
      state_class: measurement
    events:
      # Lundi à Vendredi
      - start: "06:30"
        end: "09:00"
        state: "19.5"
        condition:
          condition: time
          weekday:
            - mon
            - tue
            - wed
            - thu
            - fri

      - start: "09:00"
        end: "17:00"
        state: "19.5"
        condition:
          condition: or
          conditions:
            - condition: state
              entity_id: calendar.invite
              state: "on"
            - condition: state
              entity_id: input_boolean.force
              state: "on"
          # jours semaine
            - condition: time
              weekday:
                - mon
                - tue
                - wed
                - thu
                - fri

      - start: "17:00"
        end: "22:00"
        state: "19.5"
        condition:
          condition: time
          weekday:
            - mon
            - tue
            - wed
            - thu
            - fri

      # Samedi
      - start: "07:00"
        end: "23:00"
        state: "19.5"
        condition:
          condition: and
          conditions:
            - condition: time
              weekday: [sat]
            - condition: state
              entity_id: calendar.maison_vide
              state: "off"

      # Dimanche
      - start: "08:00"
        end: "23:30"
        state: "19.5"
        condition:
          condition: and
          conditions:
            - condition: time
              weekday: [sun]
            - condition: state
              entity_id: calendar.maison_vide
              state: "off"

Evidement tu peux combiner les conditions avec AND/OR/NOT (il y a la gestion des mois aussi), et aussi utiliser les templates.

J’ai pas accès à ma config directement mais c’est ce genre de chose que je fais

Donc la planif demande un peu de réflexion mais c’est jouable, en plus la carte se rafraichis directement quand tu modifie le yaml : pas besoin de redémarrer à chaque fois, donc tu peux peux préparer le schedule_state tranquillement, et l’appliquer dans il te plait

18

Hello

Bravo pour l’investissement au profil du collectif
Je suis dans une demarche de reflexion du chauffage pour chez ma fille et j’avais apercu scheduler

Quelles differences majeures entre sheduler et schedule_state, même si c’est legerement hors propos.

MAis j’aime bien l’idee d’utiliser l’interface de pulpy

Merci

19

Salut

La différence majeure c’est que schedule_state ne génére qu’un état, et c’est tout.
Scheduler propose de déclencher une action/script dans la foulée (+ la carte)

Personnellement je préfère garder les automatisations globalement dans l’UI commune et pas avoir des trucs disséminés partout/fonctionnement différent. Ma carte remets un peu les 2 au même niveau car lire le yaml couramment, c’est pas toujours un acquis

20

En intégration officiel, il y a aussi « Calendrier local » et « Calendrier distant ».
Dans le premier, tu peux planifier des jours et des créneaux horaire au calendrier local depuis Home Assistant, alors qu’avec le second, on peut ajouter des calendriers provenant d’autres sources comme Google, ou Apple. Cependant, les calendriers distants ne doivent pas être privés. Ils doivent être publics, ce qui peut être problématique vu que ce sont tes données personnelles.
Si tu as un accès distant à ton Home Assistant, le calendrier local est la meilleure solution.
On peut ensuite faire une automatisation en fonction de ce calendrier.

Si tu veux pousser le truc plus loin, il y a aussi l’intégration officielle, journée de travail, qui permet d’avoir automatiquement les jours fériés intégrés. Ce qui peut être pratique en fonction de ce que tu veux faire. C’est ce que j’ai fait chez moi

image
image1221×766 32.7 KB

1 « J'aime »