Trigger une automation sur le changement d'état d'une des entités du groupe

Entraide Home Assistant
1

Mon problème

Bonsoir à tous.

J’ai créé un groupe « groupe_lumieres » contenant trois lumières, A, B et C.

Je souhaiterai déclencher une automatisation sur le changement d’état de n’importe laquelle de ces lumières.

J’ai bien tenté ça, mais ça observe le changement d’état de l’entité groupe, pas des entités le composant :

trigger:
  - platform: state
    entity_id: group.groupe_lumieres

J’ai tenté de jouer avec le expand, mais dès que je le fait intervenir je rencontre des erreurs :

trigger:
  - platform: state
    entity_id: "{{ expand(group.groupe_lumieres) }}"

=>

Message malformed: Entity {{ expand(group.groupe_lumieres) }} is neither a valid entity ID nor a valid UUID for dictionary value @ data['entity_id']

Bref, si quelqu’un avait une idée magique SVP…

Merci d’avance !

2

Salut,

Un groupe de lumièrez est allumé si au moins 1 des lumières l’est… Autrement dit, quand tu allumes une 2ème lumière, le groupe ne change pas d’état.
Je ne suis donc pas convaincu que c’est une bonne idée et je partirai sur 3 triggers différents (A, B, C)

3

On est bien d’accord pour le groupe, c’est pour ça que j’essaie de mapper automatiquement sur les entités composant ce groupe :slight_smile:

Là c’est pour l’exemple, mais dans mon monde véritable, j’ai bien plus de 3 lampes, et surtout, si j’arrive à trouver un moyen de boucler sur les entity qui composent mon groupe, ça voudra dire que je n’aurais plus besoin de toucher à mon automatisation pour qu’elle soit valable sur de nouveaux membres du groupe :slight_smile:

4

Explique (précisément) le cas d’usage de ton automatisation.
J’aime et j’applique souvent les trucs « automatiques/ajustables » etc, mais j’ai l’impression que dans ton cas, c’est pas vraiment une bonne piste. L’état d’un groupe c’est un souci (et donc la manière dont ça déclenche aussi), si ça te fait louper des déclenchement, c’est pas top.

Après tu peux jouer avec le compteur issue du groupe comme trigger template

  {%- set all = expand('group.groupe_lumieres') | selectattr('state', 'in',  ['on'])|list|count -%}
  {{ all }}
5

Mon cas précis, c’est :

Lorsque n’importe quelle clim de mon groupe passe de off à autre chose, activer le mode silencieux sur cette clim en particulier (le deuxième point, c’est bon, j’ai trouvé)

Mais on pourrait envisager aussi un :
Des que n’importe quelle lampe de mon groupe est allumée, je réinitialise sa luminosité à elle seule à 100%

Et clairement, je ne soutaite pas m’embêter avec 1 trigger pour chaque lampe :grin:

6

ça on en a parlé dans l’autre sujet :wink:

Double problème :

  • Avoir un état du groupe cohérent (entendre tous les changements des appartenant aux group déclenche le trigger)
  • Retrouver l’élément du groupe qui a changé

Pour moi, c’est mort. j’ai absolument aucune idée (sauf à mettre une usine à gaz qui va récupérer les derniers changements d’état, trouver le plus récent, et c’est même pas dit que ça le bon)

Gére X triggers pour X lampes, pour les quelques fois ou le contenu du groupe va changer, tu as plus vite fait de venir ajouter/supprimer un trigger, et fait un action générique qui se base sur le trigger id (comme ça c’est automatique)

7

C’est bien pour ça que je cherche à iterer sur la liste des entity de mon groupe, quitte à ce que ça « peuple » ligne à ligne la liste des entity de mon trigger…

Je vais continuer à farfouiller, mais tout ce que j’ai trouvé pour l’instant avec un expand ne fonctionne que dans un template, pas directement dans une automatisation…

8

Dans ton cas, tu changes le groupe de tes clim encore moins souvent que celui des ampoules.
Je reste persuadé que tu perds ton temps, mais n’hésites pas à poster la solution (et à me prouver que j’ai tord)

9

Avec NodeRed et le noeud trigger, tu peux déclencher le même flot (équivalent d’automatisation) avec une expression régulière sur les entités.
C’est peut-être une option…

10

Encore une victoire de canard !!!

alias: AAAA sandbox
description: ""
trigger:
  - platform: event
    event_type: state_changed
    event_data: {}
    enabled: true
condition:
  - condition: template
    value_template: >-
      {{ trigger.event.data.entity_id in (expand('group.lampes_test') |
      map(attribute='entity_id')) }}
action:
  - service: whatsapp.send_message
    data:
      clientId: default
      to: 33XXXXXXXXX@s.whatsapp.net
      body:
        text: "entity_id : {{ trigger.event.data.entity_id }}"
mode: single

Et ça fonctionne pile poil, ça se déclenche bien, que j’allume / éteigne, ou change la luminosité !

Merci beaucoup à vous deux pour votre aide !

Trouvé ici : https://community.home-assistant.io/t/automation-trigger-on-any-member-of-a-group-is-it-possible/55795/34

11

ça va lire beaucoup de choses : tous les changements d’états de toutes les entités (même si ça déclenche pas) !
Et puis en plus comme tu es en mode single, pas sûr que ça ne rate rien quand ça cause rapidement dans le poste

2 « J'aime »
12

Hello

ton besoin n’était pas de changer la luminosité de la lampe qui a triggué dans ton groupe ?
C’est pas du tout la même paire de manche comparée à "simplement " l’indiquer dans une notif :wink:

A mon avis il faut aussi passer par un script reprenant la variable résultant de ton auto

13

Pour le coup, ça n’est vraiment pas le problème :wink:

alias: AAAA sandbox
description: ""
trigger:
  - platform: event
    event_type: state_changed
condition:
  - condition: template
    value_template: >-
      {{ trigger.event.data.entity_id in (expand('group.lampes_test') |
      map(attribute='entity_id')) }}
action:
  - service: light.turn_on
    target:
      entity_id: "{{ trigger.event.data.entity_id }}"
    data:
      rgb_color:
        - 33
        - 215
        - 20
      brightness_pct: 100
mode: single
1 « J'aime »
14

Dans la suite de la conversation, ils parlent de « YAML anchor » qui grosso modo a l’air de reprendre un bloc de code pour le recoller :

Et ça serait effectivement vachement moins violent. Sauf que le syntax checker me jette, et je n’ose pas forcer le coup et restart HA :

unidentified alias "lampes_test" (93:30)

 90 |   description: ''
 91 |   trigger:
 92 |     - platform: state
 93 |       entity_id: *lampes_test
-----------------------------------^
 94 |   action:
 95 |   - service: light.turn_on

Mais après, pour la solution brute, ce que je me dis :

  • des events, y’a que ça tout le temps, il doit bien être capable de les gérer
  • si j’en zappe un, je m’en remettrai, c’est plus une « sécurité » que je cherche

Mais bon, j’aimerai bien tout de même que la solution soit plus propre :slight_smile:

15

pas de risque de boucle infinie ?
la lampe change, ça trigge … tu changes la même lampe…

16

Effectivement, j’avais bien zappé le risque de boucle infinie. Mais visiblement le système est bien fait, ça n’en déclenche pas ^^

Edit : et en réfléchissant un peu, ça n’est pas étonnant :

1 : changement manuel quelconque => exécution de l’action
2 : l’action a déclenché un changement d’état => exécution de action
3 : pas de changement d’état, bisous au revoir :wink:

17

Les ancres YAML (anchors) c’est juste une façon de factoriser le code (purement texte) mais son exemple ne fonctionne QUE quand la définition de l’anchor (le truc avec le &) et dans le même code yaml que sa répétition (le *)

1 « J'aime »
18

C’est pas si simple évident
Je ne vois pas bien pourquoi un état changeant en sortie de l’automatisation (turn_on), ne déclencherai pas un trigger à nouveau (state sans condition et juste sur l’id)
Il n’y a pas de raison que tu ne puisses pas chainer 2 automatisations distinctes (avec 2 triggers d’état classiques) avec cette mécanique
Pour moi ce qui te sauves c’est le mode single : en gros l’état nouveau arrive avant la sortie réelle de l’automatisation, et donc il n’est pas traité (single = 1 instance d’execution)
L’exercice est rigolo, mais je ne me risquerai pas à mettre ça chez moi

19

Je ne suis pas sûr de te suivre…
Tu passe une lampe de 50 à 100% => changement d’état
Tu passe cette même lampe de 100% à 100% => pas de changement d’état

Donc dans mon cas, une action manuelle déclenche un premier changement d’état, l’automatisation en déclenche un second, et ça s’arrête là (en tout cas selon la compréhension que j’en ai)

20

oui mais c’est pas toujours le cas… ton trigger marche aussi quand tu passes ta lampe à OFF… Il déclenche l’automatisation qui la passe à ON, le ON est un changement d’état et doit redéclencher l’automation (et ça sert à rien ce dernier tour)

1 « J'aime »