Traitements les automatisations et commentaires de HA

Bah cela m’incite encore plus à faire évoluer mon programme :stuck_out_tongue_winking_eye:. Mais…

J’utilise HA depuis 4 ans maintenant, et tente de suivre les mises à jour sans trop avoir eu de dégâts jusqu’à présent (quoi que :face_with_peeking_eye:). J’admets que c’est pénible pour quelqu’un comme moi qui ne souhaite utiliser la domotique que comme quelque chose d’aidant, sans devenir un Geek qui suit chaque nouvelle release. J’espère une certaine stabilité dans ce que j’ai conçu pour pouvoir passer mon temps à de nouvelles choses.

Mais là, les dernières mises à jour m’inquiètent au point de reporter celles-ci à plus tard. (Je suis encore en Core 2024.6.3 / Supervisor 2024.09.1 / OS 12.3).

J’avais remarqué il y a quelque mois ou années maintenant qu’il m’était impossible de passer par l’interface d’automations intégrée, sous peine d’écraser tous les commentaires que j’avais précédemment écrit pour m’y retrouver au fil des écritures en Yaml.

Mes nouvelles automations sont donc toujours faites en Yaml. Même si j’en chie. :sweat:

A ce jour, le nombre de lignes écrites en 4 ans dépasse les 1400 pour chacun des fichiers automation et lovelace. Et je crois que je vais devoir encore y passer quelques heures, juste pour suivre l’évolution.

J’ai installé Studio Code server il y a peu et j’ai découverts un certain nombre d’anomalies que j’ai tenté de corriger. Ce qui a tout craché.
Toutes mes automations et scripts étaient plantés. Il m’a fallu revenir à ma dernière sauvegarde complète. Ce qui m’a fait perdre toutes les données enregistrées durant la période (quelques jours seulement, mais c’est chiant).

Bref, va falloir retrousser les manches à une période où le jardin me réclame…

Hélas, impossible de stocker les commentaires lors des passages par l’UI. il y a des contournements, que tu peux utiliser au cas par cas:

  • Pour les automatisations et les scripts, via l’UI, tu peux utiliser « renommer » pour mettre un champ « alias » dans tes automatisations sur beaucoup d’éléments (triggers, conditions, actions, if, etc…)
    Ce n’est pas tout à fait du commentaire, mais au moins c’est stocké dans le YAML. J’essaie de le faire de temps en temps pour les automatisations complexes. De plus, je mets toujours une description en entête pour me rappeler ce que ça fait…
un exemple

dans l’interface:


et le YAML associé (avec les champs « alias »)

alias: PAC - gestion auto chauffage
description: |-
  Toutes les 10 minutes.
  En saison de chauffage. En mode auto et sans override temporaire. 
  Réglage automatique du chauffage en fonction du planning et du tarif:
  -  Chauffe à la temperature de consigne si planifié, sinon PAC off. 
  -  Si tarif rouge => PAC off.
trigger:
  - platform: time_pattern
    minutes: /10
  - platform: state
    entity_id:
      - input_boolean.chauffage_mode_auto
    to: "on"
condition:
  - condition: state
    entity_id: input_boolean.chauffage_mode_auto
    state: "on"
    alias: Le chauffage est en mode AUTO
  - condition: state
    entity_id: input_boolean.saison_chauffage
    state: "on"
    alias: La saison est en mode Chauffage (mode hiver)
  - condition: state
    entity_id: input_boolean.pac_override_temporaire
    state: "off"
    alias: L'override temporaire n'est pas activé
action:
  - alias: Réglage auto du chauffage en fonction du tarif
    choose:
      - conditions:
          - condition: state
            entity_id: input_boolean.tarif_rouge
            state: "off"
        sequence:
          - choose:
              - conditions:
                  - condition: state
                    entity_id: schedule.planning_chauffage
                    state: "on"
                sequence:
                  - device_id: 5b89093e82e42fe555148e26a107faba
                    domain: climate
                    entity_id: fe8907573739d862acee9459abe1c731
                    type: set_hvac_mode
                    hvac_mode: heat
                  - data:
                      temperature: >-
                        {{states('input_number.temperature_confort_hiver')|int
                        }}
                    target:
                      entity_id: climate.pac
                    action: climate.set_temperature
                alias: >-
                  planning Chauffage => allumer PAC en chauffage et régler la
                  temperature
              - conditions:
                  - condition: state
                    entity_id: schedule.planning_chauffage
                    state: "off"
                sequence:
                  - device_id: 5b89093e82e42fe555148e26a107faba
                    domain: climate
                    entity_id: fe8907573739d862acee9459abe1c731
                    type: set_hvac_mode
                    hvac_mode: "off"
                alias: planning OFF => éteindre la PAC
            alias: test du scheduler
        alias: >-
          Tarif rouge est Désactivé => régler le chauffage en fonction du
          planning
      - conditions:
          - condition: state
            entity_id: input_boolean.tarif_rouge
            state: "on"
        sequence:
          - device_id: 5b89093e82e42fe555148e26a107faba
            domain: climate
            entity_id: climate.pac
            type: set_hvac_mode
            hvac_mode: "off"
        alias: Tarif Rouge est activé => éteindre la PAC
mode: restart

  • Pour les dashboard, j’avais vu des gens utiliser des cartes markdown pour stocker du texte. Tu peux probablement ensuite jouer sur la visibilité pour qu’elles n’apparaissent pas…
1 « J'aime »

Salut

Le souci, c’est qu’à force de cumuler, les changements sont de plus en plus nombreux… Donc forcement plus longs/compliqués/impactant

C’est pas un vrai souci, tu as pleins d’autres alternatives à la place : les labels, les catégories pour le tri, les alias pour la descriptions des étapes…
Après la questions se pose, utilises tu encore ces commentaires, si tu n’intervient que rarement sur HA ?

j’imagine

Allez, 1400 lignes c’est pas si compliqué avec un peu de méthode (et des backups)… Ici je pense que je suis autour de 20 000… Et encore j’ai utilisé les anchors, les custom_templates, declustering & co …

VS est très bien pour les fichiers à usage manuels (config) mais pour le reste blueprints, automatisations, scripts etc qui aujourd’hui disposent de leur propre interface, c’est moins vrai.

2 « J'aime »

Je passe de plus en plus mes templates via le helper pour rentrer dans le standard.

1 « J'aime »

Les commentaires dans du code sont normalement faits pour ci retrouver quand on revient dessus après un certain temps.

Je suis d’accord que cela manque.

1 « J'aime »

Oui par principe le code sert à ça. Et je pose justement la question de savoir si c’est efficace/utile/utilisé dans le cas de @Bubule
Si oui alors il faut trouver un format alternatif (les alias par exemple), si ça ne sert pas alors => poubelle.
Et accessoirement des commentaires, pas revu/corrigé en fonction des évolutions, c’est pas non plus efficace

On est d’accord que tout cela est vrai si je devais redémarrer un nouveau projet. Mais dans le cas présent où tout est déjà programmé, étudié, mis au point et fonctionnel, c’est pénible de tout revoir. Encore plus difficile de s’y retrouver lorsque l’on intervient une fois tous les 6 ou 12 mois. La logique que l’on avait au moment de la création/écriture a disparu. Il faut prendre le temps de s’y remettre. C’est très chronophage.

Du coup, j’ai pris l’habitude d’écrire les fichiers automation, scripts, etc d’une manière hiérarchisée par fonctions (chauffage, éclairages, …) et les commentaires sont bien utiles pour s’y retrouver quelques années plus tard lorsqu’une modification ou un complément doit y être apporté.
Voici un exemple :


  
  ##############################################################
  ########    ##  # #   #   # # ### ###  #   ###  ###    #######
  ########   #    # #   #   # # #   #    #   #    #      #######
  ########   #    ###  # #  # # ##  ##  # #  # ## ##     #######
  ########   #    # # ##### # # #   #  ##### #  # #      ####### 
  ########    ##  # # #   # ### #   #  #   # #### ###    #######
  ##############################################################
  
  
    
 #######################################################
      ######      Modifications CONSIGNES       #####
 #######################################################
 
 # Gestion des consignes effectuée en SCRIPT

    
  #########################################################
  ##   TRANSFERT CONSIGNES T° >>> MEMOIRE T° EN-COURS    ##
  #########################################################
  
- id: 'Selection T° Salon confort/nuit'
  alias: Selection Temp Salon
  description: 'Transfert temp consigne salon dans memoire T° Salon'

  trigger:
    - platform: state
      entity_id: 
        - input_boolean.bit_temperature_confort_salon
        - input_number.consigne_salon_confort
        - input_number.consigne_salon_nuit
  action:
    - choose:
        - conditions:
            - condition: state
              entity_id: input_boolean.bit_temperature_confort_salon
        # Si appel T° confort      
              state: 'on'
          sequence:
            - service: input_number.set_value
              data:
                entity_id: input_number.temperature_salon_en_cours
                value: "{{ states('input_number.consigne_salon_confort') }}"
              
        # Si appel T° Nuit      
      default: 
        - service: input_number.set_value
          data:
            entity_id: input_number.temperature_salon_en_cours   
            value: "{{ states('input_number.consigne_salon_nuit') }}"
         
  
  ######################################################
  
- id: 'Selection T° chambre confort/nuit'
  alias: Selection Temp Chambre
  description: 'Transfert consigne Temp chambre dans memoire T° chambre'

  trigger:
    - platform: state
      entity_id: 
        - input_boolean.bit_temperature_confort_chambre
        - input_number.consigne_chambre_confort
        - input_number.consigne_chambre_nuit
  action:
    - choose:
        - conditions:
            - condition: state
              entity_id: input_boolean.bit_temperature_confort_chambre
        # Si appel T° confort      
              state: 'on'
          sequence:
            - service: input_number.set_value
              data: 
                entity_id: input_number.temperature_chambre_en_cours
                value: "{{ states('input_number.consigne_chambre_confort') }}"
             
        # Si appel T° Nuit      
      default: 
        - service: input_number.set_value
          data: 
            entity_id: input_number.temperature_chambre_en_cours
            value: "{{ states('input_number.consigne_chambre_nuit') }}"
         
          
          
  ##############################################
  ####  Selection zone maitresse Chauffage  ####
  ##############################################
  
- id: 'Selection Zone maitresse T° Salon ou Chambre'
  alias: Selection Zone Temperature
  description: 'Transfert temp mesure et consigne salon ou chambre dans memoires T°'
  
  trigger:
    - platform: state
      entity_id:
        - input_boolean.bit_zone_temperature
        - input_number.temperature_salon_en_cours
        - input_number.temperature_chambre_en_cours
        - sensor.temperature_t_Salon
        - sensor.temperature_t_chambre
  action:
    - choose:
        # Si appel T° zone salon  >>> Envoi consigne T° salon et Mesure T° salon dans les en-cours
        - conditions:
            - condition: state
              entity_id: input_boolean.bit_zone_temperature
              state: 'on'
    
          sequence:
            - service: input_number.set_value
              data:
                entity_id: input_number.temperature_consigne_en_cours
                value: "{{ states('input_number.temperature_salon_en_cours') }}"
              
            - service: input_number.set_value
              data:
                entity_id: input_number.mesure_temperature_en_cours
                value: "{{ states('sensor.temperature_t_Salon') }}"
          
              
        # Si appel T° Zone Chambre >>> Envoi consigne T° chambre et Mesure T° chambre dans les en-cours
      default: 
        - service: input_number.set_value
          data: 
            entity_id: input_number.temperature_consigne_en_cours 
            value: "{{ states('input_number.temperature_chambre_en_cours') }}"
        
        - service: input_number.set_value
          data: 
            entity_id: input_number.mesure_temperature_en_cours  
            value: "{{ states('sensor.temperature_t_chambre') }}"
         
  
  ###################################################
  ######    GESTION REGULATION PID CHAUFFAGE   ######
  ###################################################
  
  ######### SALON ###########
  
  
- id: 'Demande Marche Chauffage Salon'
  alias: Marche Chauffage Salon 
  description: 'Demande de mise en service du chauffage Salon'
  
    #   Si tendance à la baisse ET T° < ( consigne + anticipation)
    #                 OU
    #   Consigne à la hausse ET consigne > T°
    
  trigger:
    - platform: state
      entity_id:
        - sensor.temperature_t_Salon
        - input_number.temperature_salon_en_cours
    - platform: time_pattern  # rafraichissement supplémentaire toutes les /x minutes
      minutes: '/2'

  condition:
    condition: and
    conditions:
     # Chauffage déjà à l'arret
      - condition: state 
        entity_id: input_boolean.bit_marche_chauffage
        state: 'off'
     # Zone Salon maitresse
      - condition: state 
        entity_id: input_boolean.bit_zone_temperature
        state: 'on'
      
      - condition: or
        conditions:
          - condition: and
            conditions:
              # Température sous consigne avec delta anticipation
              - condition: numeric_state 
                entity_id: sensor.temperature_t_Salon
                below: input_number.temperature_salon_en_cours
                value_template: "{{ float(state.state) - states('input_number.anticip_marche_chauffage_salon') | float }}"
              # Tendance à la baisse
              - condition: state 
                entity_id: binary_sensor.tendance_temp_salon
                state: 'off'
                
             #### OU  ####  
             
          - condition: and
            conditions: 
               # tendance consigne à la hausse
              - condition: state
                entity_id: binary_sensor.tendance_consigne_temp
                state: 'on'
               # consigne T° supérieure à mesure T°
              - condition: numeric_state
                entity_id: input_number.temperature_consigne_en_cours
                below: input_number.temperature_salon_en_cours
                
  action:
  - service: input_boolean.turn_on
    entity_id: input_boolean.bit_marche_chauffage
    
  mode: restart
  
           ##########################################
 
- id: 'Demande Arret Chauffage Salon'

Alors effectivement, l’utilisation des descriptions et alias devrait permettre de compenser la disparition de mes commentaires. Mais il faudra m’y pencher et réécrire la plupart des commentaires avant que la ‘compression’ soit effectuée si je devais l’écraser avec l’EI.
C’est à anticiper, mais je ne suis pas encore prêt tant c’est une énergie à y mettre que je n’ai pas actuellement.
Je sais que je ne vais pas avoir d’autre choix que d’y repasser des heures si je ne veux pas me retrouver en panne de chauffage un jour, ou pire, avec des animaux en détresse, voir morts si je confie leur gestion à de l’informatique/domotique. (Mais je vous rassure, heureusement, de ce coté là, je n’utilise HA que pour remonter des informations. La logique électrique des fonctions vitales reste basée sur des automatismes à relais.)
Je vais pour l’heure tenter de modifier mes automations afin qu’elles soient prêtes aux futures MAJ (TriggerS, actionS et action, etc. Parce que j’imagine que ce qui est encore accepté aujourd’hui ne le sera rapidement plus.

En résumer, les évolutions accompagnées de leurs mise à jour restent tout de même une problématique importante à prendre en compte dans la création d’une solution domotique.

Salut

Peu importe si c’est un ancien ou un nouveau projet, la méthode est la même

ça c’est une catégorie à faire… Natif

comme ça difficile de voir la hierarchie mais encore une autre catégorie ou un tag

ça dans le bloc de description

Toute cette partie là, c’est vraiment pas compliqué, il n’y a rien à faire.
Ensuite le plus long, c’est de remettre les commentaires dans les alias comme là

C’est là où généralement les commentaires sont moins importants, je prends un exemple concret :

Là je pense qu’on sait déjà tout avant de lire commentaire.

Alors certes, c’est la partie la plus longue mais c’est loin d’être insurmontable, même avec plusieurs dizaines d’automatisations. Il y a même moyen de se le faire ajouter par chatgtp. (attention par contre à bien relire, il a tendance à réinventer l’automatisation et c’est pas toujours heureux)
En plus, à l’avenir, au lieu de se farcir les écritures à la main, on pourrait profiter de la partie UI qui même si pas parfaite, commence sérieusement à devenir fun.

1 « J'aime »

De ce coté là, a priori pas de soucis, il n’y a pas prévu que cette manière de faire soit dépréciée…

Donc ton code devrait rester valide « ad vitam »…

C’est reculer pour mieux sauter… Comme disait @Pulpy-Luke

Mais honnêtement entre les catégories (pour trier, référencer les automatisations), les étiquettes labels (idem + des fonctions transverses), la description et les alias. Reprendre les automatisations n’est pas insurmontable, et les « pertes » liées au passage par l’UI peuvent être vite récupérées…

Toutes tes automatisations ont déjà une description qui est assez explicite (donc le commentaire est plus une mise en forme du fichier yaml pour s’y retrouver dedans qu’un besoin de description, qui est déjà dans le champ description).
par ex:

Donc si ti tu fais ce tri dans la liste d’automatisation (avec des labels et des catégories), tu n’as rien à faire de plus dans le code…

Les commentaires qui restent dans le code ne me semblent pas insurmontables.
D’autant plus que l’UI te met un alias « par défaut » qui décrit le bloc dans l’UI: (ex sans alias:)

qui utilise le friendly name et est souvent suffisamment explicite pour ne pas nécessiter un alias particulier.

1 « J'aime »

Donc tout pareil que @BBE :wink: et il a des exemples en plus

Pour moi s’il y avait un travail génant et long à faire, je pense que ce serait de voir le nommage des entités
image
En faisant :

  • input_boolean.bit_temperature _salon _confort
  • input_number.temperature_salon_en_cours
  • input_number.consigne_salon_confort

On reste vachement plus homogène (et ça permet de faire plein de chose avec des triggers/remplacements, la chaine temperature_salon_ est la clé). Bon c’est un autre sujet en tout cas.

1 « J'aime »

Là par contre on met le doigt dans un engrenage plus difficile… Mais les bénéfices sont évidents.

Mon prochain chantier (si j’ose…)

Un exemple chez nous:

Les catégories te permettent de faire du tri dans tes automatisations et tes scripts, une catégorie par script/ automatisation:

Nous avons 91 automatisation, mais de base l’interface ressemble à ça grace aux catégories:


Si je cherche une automatisation de chauffage, je clique sur PAC :
image

Si on regarde les scripts (27 scripts):
image
Pareil je clique sur PAC:
image

Et là on voit un libellé: Alexa qui est collé à tous les elements qui remontent dans Alexa (scripts comme entités) pour permettre un contrôle vocal.

Les libellés (labels, étiquettes suivant les traductions…) te permettent de faire du tri (et même plus) dans toutes tes entités. Tu peux mettre autant de libellés que tu veux à chaque entité.

Pour l’instant je n’ai que deux libellés d’utilisés, mais pour l’exemple ça te montre les possibilités:

Du coup dans la liste des entités:
J’ai 1088 entités activées, difficile de s’y retrouver…:

Si je clique sur le libellé Alexa:


J’ai seulement les 50 entités pilotables à la voix qui remontent (scripts, lights, switchs, covers).

Si je clique sur Notifications:


J’ai seulement les 20 automatisations qui comportent des notifications qui remontent…

On peut de plus appeler le libellé dans des automatisations, scripts, templates… Par exemple je pourrais créer un trigger « si une entité ayant le label « alexa » devient indisponible », et m’en servir pour faire une notification.

Çà je n’y crois pas. Un jour ou l’autre, et dans ce domaine ça va très vite, quelque chose de plus important fera que les vieux écrits deviendront incompatibles.

Il va bien falloir s’y coller. Je me dois de vous faire confiance pour avancer. Même progressivement.
Mais concrètement, par où commencer ?

J’imagine copier mon fichier Automation (pour commencer) et le renommer. Sauvegarder (sauvegarde totale)
Créer une nouvelle automation simpliste, juste pour laisser l’EI compresser mon fichier, et ouvrir pour voir les dégâts.
A partir de là, commencer le travail de commentaire en m’appuyant sur mon vieux fichier renommé comme base de compréhension.

Çà vous semble une bonne méthode ?

Mais quid des catégories ?

Je ne vois pas où le déclarer. Puis-je encore le faire, maintenant que toutes mes automations/scripts/Lovelace(UI) sont écrites ?


PS : N’aurait-on pas intérêt de sortir de ce sujet qui n’a peut-être plus rien à voir avec la release pour en créer un nouveau ?

Ca je laisse faire les modos… mais je pense que c’est une bonne idée…

C’est dans la liste de toutes tes automatisations crées avec l’UI que tu peux attribuer les catégories. On tatone un peu au début, mais c’est assez simple au final:
la doc officielle:

Et pour les labels, ça se gère un peu comme les pièces…

et leur utilisation dans des templates: Templating - Home Assistant

Je ne sais pas si l’UI va récupérer toutes tes automatisations dans ce cas. Si oui, c’est une bonne méthode.
Si non, il te faudra copier tes automatisations une par une (en YAML) Au fur et à mesure.

Mais bon, je ne suis pas spécialiste, vu que je fais toutes mes automatisations avec l’UI, donc attend d’autres avis avant de te lancer

1 « J'aime »

Je laisse @Pulpy-Luke s’en occuper, c’est lui qui a lancer le débat :joy:
C’est l’heure de l’apéro, repas et sieste :crazy_face:
Si rien de fais dans l’après midi, je le ferais. :wink:

2 « J'aime »

Je ne pense pas que tu as 1 fichier .yaml pour toutes tes automations. Donc tu dois facilement pouvoir désactiver 1 automation par 1 dans le yaml.
Ce que je ferai, et que j’ai fait de mon côté, c’est de faire 1 automation par 1.
Tu choisis une automation pas trop critique et que tu peux facilement tester, pour te faire la main. Puis tu la « réécris » dans l’UI, et tu testes.
Puis au fur et à mesure tu prends celle plus complexe / moins facile à lancer des tests, jusqu’à ce que tout soit basculé dans l’UI.

Le plus difficile, étant de commencer, afin de bien prendre en main les mécanismes nouveaux. Mais la logique reste la même, vu que tu ne changes pas de système domotique.

Aussi, l’avantage de passer par l’UI, c’est que quand il y a des changements comme celui annoncé dans cet release d’Amélioration de la syntaxe YAML pour les automatismes, ça se fait tout seul sans que tu aies à reprendre chaque fichier .yaml manuellement.

En tout cas, bon courage, parce que ça ne se fait pas en 2 minutes :wink: Mais le jeu en vaut la chandelle pour la suite (pouvoir faire les mises à jour plus sereinement).

2 « J'aime »

Si le fichier complet contient les ID, je pense que ça marche directement, l’ui sait le prendre en charge et les commentaires vont disparaitre tous seuls.
Il faut juste prévoir une copie à coté pour faire copié/collé

EDIT: Les id sont là mais pas au format numérique classique… Donc à tester (et donc backup à garder sous la main)

2 « J'aime »

Testé l’import brut, sur l’extrait dispo. Reboot et hop


L’id ne lui plait pas trop mais il propose une migration

Qu’on peut enregistrer
image
avec un autre nom

Donc le plus simple c’est de remplacer les ID AVANT sous cette forme
- id: '1728316892993' (et de mettre l’ID Actuel dans l’alias s’il est plus clair)
Sinon il faut tout dérouler avec la migration et faire le nettoyage à la main

PS : j’ai comme l’impression que l’id a été bidouillé à un moment donné, pour être utilisé comme descripteur…

1 « J'aime »

Merci pour votre aide.

De retour…, j’ai sauvegardé le fichier et créé une mini automatisation via l’UI. Le fichier s’est ‘bien’ compressé. Plus de ligne vide ni de commentaire.

La clarté de mon fichier a totalement disparu :sob:. Ça devient difficile de s’y retrouver sur un tel listing. Il va falloir que je me fasse à l’UI… (je ne le sens pas pour l’avenir tant j’ai toujours galéré à comprendre sa logique, préférant toujours le mode .yaml).

J’ai effectué l’opération avant de toucher aux ID tel que tu me le proposais (opération effectuée avant d’avoir vu ton message).

Contrairement à l’essai que tu as réalisé avec le début de mon fichier, et qui me donnait les mêmes erreurs, la plupart de mes automations ne mettaient aucun message d’erreur dans l’UI, alors qu’il s’agit aussi de commentaires ‹ textes › au lieu de nombres dans le champ ID.
Cela m’a paru étrange dans la mesure où la gestion du chauffage est arrivée la première année d’utilisation de HA. De nombreuses autres automations ont ensuite été réalisées selon le même principe (ID avec texte), et elles ne semblaient pas poser de soucis à l’EI.

Je viens de me rendre compte que c’est le caractère spécial (/) dans le texte de l’ID qui génère cette erreur. Dont celui que tu as testé.

Lorsque j’ai voulu corriger les deux automations qui posaient problème en effectuant la migration proposée par l’UI, cela m’a créé une nouvelle automation en fin de liste ( :flushed: pas glop pour s’y retrouver ensuite). Et cette fois avec un ID numérique. Sans pour autant supprimer l’ancienne automation. J’imagine que si je ne fais pas gaffe, je vais droit dans le mur avec plusieurs automations identiques en simultané…
Je ne vois pas d’autre possibilité de créer un ID manuellement pour celles qui ne semblent pas poser de problème. Dois-je mettre un ID numérique au hasard ? (ce qui m’évitera d’avoir plusieurs automations identiques en cas d’oubli.)

1 « J'aime »

Mais en théorie tu ne l’ouvriras plus jamais, donc c’est pas si grave…
:innocent:

Seulement pour l’accès à tes automations, au début tu auras tout en vrac, il te faudra créer des catégories et/ou des labels puis gérer le groupement d’affichage (par piece, par catégories, etc…):

Dans tous les cas tu disposeras d’ores et déjà d’un champ de recherche ainsi que de filtres très efficaces pour retrouver tes automatisations:
image
par exemple le filtre par entité te permet d’afficher toutes les automatisations qui utilisent une entité…

Franchement, s’y retrouver dans la liste des automatisation, depuis quelques versions, c’est vraiment facile et intuitif… Il faut vraiment le vouloir pour préférer un fichier YAML, même commenté, à cette liste avec tous les types de tri, recherche et filtres qui y sont proposés…
:wink:

Ensuite, en ce qui concerne les automatisations elles memes, rien n’interdit de les modifier en YAML.


Suffit de cliquer sur les 3 petits points en haut à droite et passer en YAML ou en editeur visuel (on peut faire autant d’aller retour que l’on veut… il faut juste éviter de commenter le YAML car ce sera perdu à la sauvegarde ou à la bascule dans l’UI)

Pour les commentaires / alias si besoin tu peux le faire en YAML comme via l’UI…

Tu t’en sors bien si tu as identifié le truc et que tu n’as que 2 automations à reprendre !!
:partying_face:

Tu as essayé de juste renommer les deux automations qui posent problème (avant ou après le transfert…) au pire tu supprimes les doublons et c’est bon…