Modifier l'attribut "hvac_action" via un switch

Bon j’ai encore la même erreur.

Du coup voilà ce que ça donne :

- platform: template
  switches:
    switch_climate_bureau:
      value_template: "{{ is_state('climate.bureau', 'heat') }}"
      turn_on:
        - service: climate.set_hvac_mode
          data:
            hvac_mode: 'heat'
          target:
            entity_id: climate.bureau
        - service: python_script.set_state
          data:
            entity_id: climate.bureau
            hvac_action: 'heating'
      turn_off:
        - service: climate.set_hvac_mode
          data:
            hvac_mode: 'off'
          target:
            entity_id: climate.bureau
        - service: python_script.set_state
          data:
            entity_id: climate.bureau
            hvac_action: 'idle'

Le script me change bien l’attribut. Néanmoins, dès que je bascule le switch à « on », je vois bien l’attribut hvac_action passer à « heating » mais il revient quasi aussitôt à « idle »

a voir le value_template ?

Il semblerait que ce soit la gestion des 2 services dans la partie turn_on et turn_off.

Puisque si je commente la partie :

        - service: climate.set_hvac_mode
          data:
            hvac_mode: 'heat'
          target:
            entity_id: climate.bureau

J’ai un fonctionnement correct de l’autre partie. Idem si je commente :

       - service: python_script.set_state
         data:
           entity_id: climate.bureau
           hvac_action: 'heating'

La première partie s’exécute correctement.

Du coup pour ce qui nous concernait, je considère que c’est résolu. Merci à toi @Doubledom.

Je vais chercher maintenant pourquoi ça ne se maintien pas si j’appelle 2 services dans une même action.

Je tente du côté value_template: "{{ is_state('climate.bureau', 'heat') }}" comme tu me l’a indiqué. Même si de prime abord, je sens que je vais encore bien galérer :wink:

Merci bien en tous les cas pour ce temps passé.

Bon en réalité c’était simple comme bonjour.

Je demandais trop de choses dans un délai trop court. Ce qui fait qu’entre mes 2 actions, hass n’avait pas le temps de rafraîchir l’entité. J’y ai donc adjoint un petit délai d’une demi seconde et tout fonctionne comme je le souhaitais…

Du coup comment j’ai fait pour ceux que ça pourrait intéresser :

1. Modifier l’attribut d’une entité


Il semble que ce ne soit pas possible autrement que par un script Python (ou alors je suis trop teubé pour savoir faire). Et fort de la communauté HASS, qqn s’y est attelé pour moi. Du coup, voici comment installer le script pour les gouverner tous.

a. Modifier le fichier configuration.yaml

Il faut rajouter dans le fichier configuration.yaml (via vscode ou file editor ou que sais-je encore) la ligne suivante :

python_script:

Puis dans le dossier de configuration de home assistant (là où trône fièrement votre fichier de configuration.yaml dont vous êtes très très fier) créer un petit dossier nommé :

python_scripts

Via file editor, FTP, SCP… Etc. Ce que vous avez l’habitude d’utiliser. Personnellement je n’ai pas eu à le faire mais j’ai lu sur GitHub que parfois, fallait prendre les devants alors autant le créer maintenant que de chercher 10 ans pourquoi ça ne fonctionne pas. (Merci @titoumimi pour la remarque) :wink::+1:

b. Installer le script via HACS (méthode la plus simple)

Dans HACS donc, ouvrez la partie Intégrations puis cliquez sur le menu burger (les 3 point verticaux en haut à droite) pour sélectionner dans le menu qui y apparaît : ‹ dépots personnalisés ›.

Une fois sur la fenêtre modale, en bas vous avez 2 champs. Dans le premier champs texte (Dépôt) y coller l’adresse du dépot GitHub de @xannor :

https://github.com/xannor/hass_py_set_state

Et dans la liste déroulante (Catégorie), choisir ‹ Script Python › pour terminer en cliquant sur ‹ Ajouter ›.

Une nouvelle catégorie dans HACS vient d’apparaître : Automatisation. Allez-y rentrez dedans.
Cliquez sur le plus en bas à droite et recherchez : ‹ Hass py set state › puis installez-le.

Un petit restart de Home Assistant et le tour est joué. Simple nan ?

Bien entendu, si vous préférez une autre méthode d’installation, le GitHub de @xannor vous indique la marche à suivre manuellement (qui est aussi très simple on va pas se mentir, je suis un N00b et j’ai réussi).

2. Créer et paramétrer le switch qui modifie l’entité


Pour utiliser cette fonction en Python, rien de plus simple… Il suffit de suivre le README.md sur le GitHub. Mais si vous avez une petite flemme après vous être déjà tapé mon gros pavé, voici ce que la doc dit :

Clé Facultatif Valeur Description
entity_id: Non Chaîne L’ID complète de l’entité que vous souhaitez modifier
state: Oui Tout L’attribut: sa valeur (ex : is_open: « yes »)
allow_create: Oui True/False (Booléen) Autorise le script à créer l’attribut que vous lui indiquez s’il n’existe pas. (Par défaut sur « non » afin d’éviter la création d’attributs non souhaités. Si l’attribut n’existe pas et que la valeur de cette clé est définie sur « false », alors rien ne se passe)
…: Oui Tout rajoutez autant d’états ou d’attributs que vous souhaitez ajouter/modifier à la suite…

Voici un petit exemple d’application :

/!\ ATTENTION je décris ici un cas personnel. Je cherchais à modifier l’état d’une entité climate (en gros créer un switch qui l’allume ou l’éteins) mais en plus, modifier l’attribut hvac_action qui, suivant l’état du switch passe de l’état (de la valeur) « heating » à « idle ».

Dans mon fichier configuration.yaml (ou votre fichier switch, template, bref là où vous organisez vos « template switches ») :

- platform: template
  switches:
    switch_climate_bureau: 
      value_template: "{{ is_state('climate.bureau', 'heat') }}"
      turn_on:
        - service: climate.set_hvac_mode
          data:
            hvac_mode: 'heat'
          target:
            entity_id: climate.bureau
        - delay: 0.5
        - service: python_script.set_state
          data:
            entity_id: climate.bureau
            hvac_action: 'heating'
            allow_create: true
      turn_off:
        - service: climate.set_hvac_mode
          data:
            hvac_mode: 'off'
          target:
            entity_id: climate.bureau
        - delay: 0.5
        - service: python_script.set_state
          data:
            entity_id: climate.bureau
            hvac_action: 'idle'
            allow_create: true

Vous pouvez voir dans ce code qu’entre chaque appel de service, j’y rajoute : delay: 0.5. Ce délai d’1/2 seconde est nécessaire si vous souhaitez manipuler plusieurs attributs d’une seule et même entité. Ce afin de laisser à Home Assistant le temps de rafraîchir la première valeur à modifier, et passer ensuite à la seconde valeur à changer. Si vous l’oubliez, il va se mélanger les pinceaux et adieu la logique de commande.

Dans le cas ou vous auriez à manipuler des attributs d’entités différentes, pas besoin. La tempo se fera naturellement.

Voilà. En espérant que ce petit « guide rapide » qui m’a été soufflé par les protagoniste de ce fil de discussion puisse vous servir, car il m’aurait été fort utile à moi.

A l’arvoyure :wink:

Crédits

@xannor sur GitHub (xannor · GitHub) grâce à son intégration HACS « Py Set State » (GitHub - xannor/hass_py_set_state: Home Assistant Python Script to force set an entity state)

Remerciements

@Doubledom pour m’avoir mis sur la bonne piste et avoir passé quelques heures sur ce sujet.
@Krull56 qui lui aussi à prit part à cette conversation pour m’aider dans cette tâche ingrâte.

Merci les mecs. (ou mesdames car on ne sait pas vraiment qui se cache derrière un pseudo) :smiley:

4 « J'aime »

Un grand merci à @djiwhy et aux autres participants de ce fil.

« Contraint » de migrer de zha vers z2m pour cause de TRV _TZE200_znlqjmih non supportée par zha, j’ai eu la désagréable surprise de constater que mes ZTRV-ZX-TV01-MS ne l’étaient que très partiellement sous z2m.

Sous zha, le hvac_action est émulé et permet très facilement de piloter un circulateur mais rien sous z2m. Autant dire qu’elles sont inutilisables.

J’ai longtemps tourné en rond avant de trouver ce fil très instructif et bien fait.

Une simple automatisation avec un template dans la condition pour tester la différence entre la température de consigne et la température mesurée, l’appel au service python qui me manquait pour faire un set attribute et je peux continuer à utiliser mes anciennes TRV en plus des nouvelles. :slightly_smiling_face:

1 « J'aime »

Content de ne pas avoir fait ça pour rien :wink::+1:

1 « J'aime »

Je me permettrai de rajouter un truc à ton a) :wink:
Il faut créer le dossier /python_scripts sinon ça ne fonctionne pas.

Par contre, comment as-tu résolu le problème de perte de données lors du refresh « naturel » de ton entité ?

Sur mes clims, si je définit un état via le script python, ce dernier finit par sauter plutôt vite lors du refresh « naturel » de mon entité, qui le fait disparaitre…

Merci d’avance

Salut @titoumimi

Ta remarque concernant le dossier /python_scripts est la bien venue. J’ai relu 30 fois et j’ai zappé ce passage. :pensive:

Après je ne suis pas sûr de bien comprendre de quoi il s’agit concernant ton histoire de refresh. Ce script me sert pour des vannes thermostatiques zigbee. Le refresh de l’entité (la vanne) ne se fait qu’au changement d’état de la vanne ou de la température mais ne me fait rien « sauter » … Tant au niveau de l’automatisation, que du script, ou des attributs de ma vanne thermo.

Après je ne manipule pas mes vannes a la main. HA s’occupe de tout. Néanmoins, je viens de tenter de changer quelques paramètres directement sur les vannes et je n’ai rien vu « sauter ». :thinking:

Sur ce coup là mon pauvre j’ai bien peur de ne pas trop capter. Par contre, si tu veux qu’on y réfléchisse ensemble, et que tu as un peu de temps à perdre tu peux avec grand plaisir m’exposer ton problème avec plus de précisions. Des captures par exemple de ce que tu vois ça aide vachement, je suis très visuel moi. :sweat_smile:

A+ peut être.

1 « J'aime »

En fait, j’ai essayé de mon côté pour forcer un nouvel état sur mes clims (un état inconnu au départ).

ça fonctionne bien, mais la prochaine fois que ma clim m’envoie un update de statut (température, …) ça fait sauter mon « faux » état forcé :slight_smile:

ça n’est pas grave hein, j’essayais juste de m’en servir pour éviter de faire des trucs cradingues en Json dans des input texts :wink:

Ah, alors pour toi c’est un état déjà existant que tu veux forcer sur une valeur ?Alors que dans mon cas c’est un état créé de toute pièce.

Du coup je pense que je n’ai pas ce souci là car le changement de valeur de l’attribut n’est pas commandé par le refresh de l’entité. Mon entité ne connait pas l’attribut que je lui ai créé.

Je fais quelques tests pour reproduire ce que tu me dis et je vais chercher de mon côté si j’arrive à reproduire ça. :grin:

C’est très gentil, mais ne t’embête pas plus que ça hein :slight_smile: J’ai une solution de contournement, fonctionnelle, ça mérite pas plus :wink: