[AIDE] Tableau 24×7 avec cellules cliquables sans créer 168 entités

[djtef]

Mon problème

Bonjour à tous,

Je travaille sur un projet autour d’une pompe à chaleur que je pilote via ESPHome.
Je lis/modifie de nombreux registres Modbus, dont les registres de programmation horaire (2 programmations pour le chauffage + 2 autres pour la clim).
La pompe à chaleur est aussi commandable via son écran, voici comment est représentée la programmation horaire:

En gros ce sont 4 tableaux de 24 colonnes pour chaque heure et 7 lignes pour chaque jour de la semaine, chaque cellule signifie eco ou confort.

Je récupère via le Modbus tous les registres associés : chaque cellule du tableau représente un bit dans un registre, j’ai 56 registres en tout.

Objectif

Créer dans Home Assistant une interface semblable pour programmer les 7 jours × 24 h des 4 programmations.

• Chaque cellule = un élément cliquable qui change de couleur
• Un titre pour chaque colonne (heures) et chaque ligne (jours)
• Pas de 168 entités : je ne veux pas créer 4 x 168 input_boolean pour des raisons de performance, stockage, clarté…
• Si possible pas de custom card (à mon avis ça va être compliqué )
• Mon idée :
  – À chaque clic : mise à jour locale d’un buffer hexa stocké dans un input_text
  – En bas : un bouton “Envoyer” qui envoie les registres bruts à ESPHome
  → donc pas d’appel de service à chaque clic

En résumé : je veux recréer un tableau interactif entièrement basé sur du rendu Lovelace, pas sur des entités.

Je sais qu’il existe des outils tout fait de planification de type scheduler-card, c’est très bien mais pour remplacer le système de programmation intégré d’origine et commander directement les thermostats. Moi je veux pouvoir paraméter les 4 programmations soit via l’écran de la PAC, soit via Home Assistant et que ça reste synchro.
Je pourrai par la suite envisager des systèmes plus ergonomiques en plus.

Mes essais

J’ai essayé un tas d’options:

• Faire une grille de boutons, avec des cartes dédiées pour les titres et les colonnes, en trichant pour que ce soit aligné… mais je ne sais pas faire changer la couleur des boutons de la carte d’origine, donc je suis bloqué.
  Voici ce que ça donne:
  
  
• J’ai essayé de jouer sur la visibilité des éléments, ça marcherait sauf que ça décale la grille, et en plus on ne peut pas gérer la visibilité par template.
• J’ai essayé de faire avec du picture element, mais il faut que ce soit basé sur des entités, je n’arrive pas à faire afficher un élément en fonction d’une condition via template.
• Je me suis dit je vais regarder s’il n’y a pas un système de tableau tout fait dans les custom cards, j’ai trouvé flex-cless-card, mais il faut que chaque cellule soit attachée à une entité

A première vue ça parait tout simple, mais ça fait plusieurs jours que je galère, j’avoue je ne suis pas un pro de l’interface, peut-être quelqu’un aura une idée lumineuse ?

[BBE]

Scheduler card c’est une chose. mais un scheduler tout court c’est une entité unique qui représente ce que tu veux faire…

Lovelace ce n’est que de l’interface, a un moment il te faudra bien des entités à synchroniser… Input text ou scheduler… a toi de voir.

Perso je jouerai avec 4 scheduler et je réfléchirait à une façon de faire la synchro dans un sens puis dans l’autre. (Pour ça je n’ai pas d’idée).

Dans mon cas j’ai fait un choix simple: c’est HA qui pilote, la commande locale est surpassée par HA à chaque execution de la synchronisation (toutes les 10 min). Donc si HA tombe en rade, je peux piloter en local, mais si HA tourne, c’est HA qui reprend toujours la main.
Ca me simplifie le pilotage, et je garde l’interface d’origine en backup, mais ne m’en sers pas.

[djtef]

Merci pour ta réponse, effectivement j’ai oublié de mentionner le scheduler.
J’ai tenté de créer une entrée scheduler, lors de la création on peut créer les plages horaires, ça parait répondre au besoin en terme d’interface.
Sauf de ce que j’ai compris il n’y a aucun moyen d’avoir une carte qui affiche le scheduler pour pouvoir le modifier dans lovelace, et je vois pas comment mettre à jour mes registres en fonction des plages du scheduler, il faudrait arriver à le parser à chaque modification.

[djtef]

@BBE

Dans mon cas j’ai fait un choix simple: c’est HA qui pilote, la commande locale est surpassée par HA à chaque execution de la synchronisation (toutes les 10 min). Donc si HA tombe en rade, je peux piloter en local, mais si HA tourne, c’est HA qui reprend toujours la main.
Ca me simplifie le pilotage, et je garde l’interface d’origine en backup, mais ne m’en sers pas.

Et pour ta façon de faire c’est une solution effectivement, ne pas du tout tenir compte de la programmation prévue d’origine, et se créer la sienne dans HA.
Je trouve quand même dommage quand t’as tout paramétré de devoir tout refaire dans Home Assistant.
Pour moi qui suis le premier à implémenter le système, effectivement ça serait rentable en terme de temps passé, mais pour tous les autres qui copie-colleraient, ils n’auraient rien à faire dans Home Assistant, ça serait transparent.

[Tochy]

Salut

Ton registre modbus, quand tu lis la prog par exemple, comprend une seule case ou toute les case ?

[djtef]

Il y a 2 registres pour un jour d’une prog.
un registre de 16 bits qui va de 00h à 16h, et un registre de 8 bits qui va de 17h à 00h.
2 registres x 7 jours x 4 prog = 56 registres.

[Tochy]

Oups ça fait du monde.

J’ai bien une idée mais toutes ces cases et registres ça va être un joyeux bordel.

Le principe en soit est pas si compliqué mais la mise en œuvre…

Peux tu poster un registre d’un jour de prog tel qu’il apparaît dans ha et le même registre avec par exemple la toute première case (lundi 00h-01h) modifiée avec photo de l’écran que vous les cases.

[djtef]

Si tu veux savoir comment c’est codé le principe est celui-ci:

• Registre 31200 : ProgA Lundi#1 (1:16h-17h,2:17h-18h,4:18h-19h,8:19h-20h,16:20h-21h,32:21h-22h,64:22h-23h,128:23h-00h)
• 31201 : ProgA Lundi#2 (1:00h-01h,2:01h-02h,4:02h-03h,8:03h-04h,16:04h-05h,32:05h-06h,64:06h-07h,128:07h-08h,256:8h-9h,512:9h-10h,1024:10h-11h,2048:11h-12h,4096:12h-13h,8192:13h-14h,16384:14h-15h,32768:15h-16h)

Donc par exemple si le registre 31200 a les valeurs
1: 16h-17h
3: 16h-17h + 17h-18h = 16h-18h
7: 16h-17h + 17h-18h + 18h-19h = 16h-19h
…
129: 16h-17h + 23h-00h

Ainsi de suite, 1 bit par heure

[Pulpy-Luke]

Salut,

Je vais suivre le sujet, je viens de faire un truc proche : la conversion d’une entité schedule_state en carte qui visualise tous les planings. J’ai pas écrit une seule ligne de code manuellement, mais ça ma couté quelques heures d’essais et de prompts successifs.
Donc autant je vois bien l’idée de convertir les registres hexa en tableau d’affichage, autant la partie éditable puis reconversion en hexa dans HA me semble être plus compliquée.

Courage

[djtef]

Je veux bien te croire, j’ai passé pas mal de temps à trouver comment lire les valeurs et les afficher clairement dans esphome, je m’en suis pas trop mal sorti au final, voici ce que ça donne :

Maintenant c’est l’écriture de manière ergonomique qui est galère, alors qu’à première vue ça parait plus simple que la lecture et l’affichage en texte…

[Tochy]

129 ou 127 pour 16h-00h ?

[djtef]

Si tu sélectionnes toutes les cellules de 16h à 00h, ça va faire 255 car les 8 bits seront à 1.

[Tochy]

Oups oui j’ai oublié une ligne dans mes écrits. C’est bien 255

Je regarde en détail demain ou après demain voir ce qui est jouable.

Le principe c’est quand j’appuie sur une case, ça appelle une script qui doit ajouter ou retrancher 1, 2, 4, 8, 16, 32, 64, 128 à la valeur du registre selon la case choisie et son état et envoi le résultat au registre

[djtef]

Comme j’explique dans mon premier message, j’aimerais éviter de mettre à jour le registre à chaque fois qu’une cellule est cliquée car ça va envoyer plein de mises à jour au modbus. Mon idée c’était plutôt de mettre à jour la représentation du tableau entier, soit des 168 bits, les convertir en hexa puis en string dans une input_text avec 42 caractères. Puis quand on clique sur un bouton envoyer ça convertit l’input_text en valeurs de registres vers esphome.

[Tochy]

Ok mais ça change pas grand chose à la logique. Dans ce cas le script met à jour un input text ou number et après un bouton pour envoyer.

[djtef]

J’ai testé mon idée initiale en passant à du custom:button-card au lieu du button standard.
J’arrive à lire l’input_text (saisie manuellement pour l’instant) et la transformer en matrice de boutton.
Exemple, avec une input_text qui vaut « 0123456789ABCDEF0123456789ABCDEF0123456789 »
ça donne :

Par contre j’ai 3 sections, donc c’est pas du tout « responsive », sur le téléphone ça fait n’importe quoi, les titres se barrent, les cellules se chevauchent…
Il faudrait créer titres + cellules en une seule section mais je vois pas trop comment faire encore.
Pour info le code d’une cellule de la grille :

      - type: custom:button-card
        name: "Lundi 0h"
        show_name: false
        show_icon: false
#        tap_action:
#          action: call-service
#          service: script.toggle_prog_bit
#          data:
#            prog: "A"
#            index: "0"
        styles:
              card:
                - padding: 0px
                - margin: 0px
                - width: 32px        # à ajuster
                - height: 32px       # à ajuster
                - background-color: >
                    [[[
                      // Récupérer le buffer (string hexa)
                      const buffer = states['input_text.proga_buffer'].state;
                      if (!buffer || buffer.length < 2) return "white";
                      const index = 0; 
                      // Calcul byte/bit
                      const byte_index = Math.floor(index / 8);
                      const bit_index  = index % 8;
                      const hex = buffer.substr(byte_index * 2, 2);
                      const byte = parseInt(hex, 16);
                      const bit = (byte >> bit_index) & 1;
                      return bit === 1 ? "green" : "white";
                    ]]]

[Pulpy-Luke]

Salut,

Tu as bien mis des groupes de sections H/V ou grilles : il faut arriver à faire des sections : lignes par jour, colonnes par heures pour essayer d’avoir du responsive. En plus si tu fixes les tailles en pixels, c’est mort, il faut passer par des viewports pour avoir un chance de faire un truc proportionnel à l’écran

A titre perso, j’ai pas l’impression que le fait d’avoir la liste des heures/jours complète ce soit nécessaire coté ESP mais uniquement pour la représentation visuelle. Entre l’ESP et HA le seul truc important c’est le registre/inout_text (charge à la carte de le coder décoder)

[djtef]

Non j’ai pas créé de groupe de sections horizontale et verticale. Mais c’est quoi que t’appelles groupe de section exactement ? Vertical et horizontal-stack ou une section du dashboard composé de plusieurs sections ?
Je vois pas trop comment faire des sections horizontale + verticale, ça ferait définir mes cellules en double non ?

Effectivement je me suis dit que les cellules en pixels c’était pas terrible, mais on passe au niveau supérieur avec les view port, ça fait un moment que j’ai pas fait du html, va falloir que je m’y remette…

Je suis d’accord avec toi, les text_sensor qu’expose esphome ne servent que pour valider que ça fonctionne avant d’avoir implémenté le dashboard dans Home Assistant, car la valeur des 56 registres bruts c’est pas très parlant.

[Pulpy-Luke]

@djtef

Non j’ai pas créé de groupe de sections horizontale et verticale. Mais c’est quoi que t’appelles groupe de section exactement ? Vertical et horizontal-stack ou une section du dashboard composé de plusieurs sections ?

Dans les cartes de base HA ou dans les custom

[djtef]

Oui OK, c’est plutôt une carte avec des sous cartes.
J’ai fait 3 sections :

• une grille de boutons
• un pile horizontale et de markdown pour les titres des heures
• une pile verticale pour les titres des jours

Mais c’est pas bon car ça crée pas un monobloc et ça peut se réarranger.
De plus la grille se comprime trop horizontalement, j’aurais préféré que ça reste fixe et qu’il y ait une barre de défilement.