J’ai installé des détecteurs de fuite d’eau dans les salles de bain, la cuisine.et les wc.
Dans les entrées j’ai fait un groupe (binary.sensor). Ce groupe me permet de détécter quand au moins un des capteurs a son état qui change (non activé vers activé).
Dans l’intégration visuelle j’ai ajouté l’envoi d’une notification perisitante qui me prévient qu’une fuite d’eau à eu lieu.
Je souhaite que dans cette notifiaction ca me donne aussi le nom du capteur qui a été déclanché.
J’ai essayer plein de trucs repris par-ci par-là sur le net mais rien ne fonctionne.
Je ne suis pas adpete du YAML et je pensais qu’avec l’interface visuelle pour créer les automatiqme, j’alais m’en sortir.
Après avoir patiné pendant de heures, je viens vous demander un coup de main.
Qui maîtrise bien l’interface visuelle de création des automatismes ?
Je suis curieux de voir la réponse parce que je pense qu’on ne peut pas en full UI.
J’essaye aussi dans la mesure du possible d’éviter les définitions qui n’existent qu’en YAML mais parfois c’est impossible.
En tous cas j’ai des blueprints pour mes alarmes et j’ai du faire du template jinja pour aller extraire le ou les capteurs activés et leur localisation, on ne peut pas avec des blocs graphiques.
Ou si jamais on le peut, avec une complexité inintéressante.
Slt..
Sur ce type de groupe tu ne peut pas récupérer un attrib de celui en défaut
Il faut tester en conditions des différents Entités du groupe
Donc code YAML dans l’automation
Le plus simple pour moi sera de créer un automatisme en mode visuel pour chaque détecteur de fuite, avec son propre message à chaque fois. Ça évitera de partir sur du YAML trop “entortillé”.
C’est un peu dommage, parce que le principe des groupes était intéressant.
Je viens de l’univers Homey Pro. Il a ses défauts, notamment un Zigbee pas très fiable, mais la partie automatisation en mode graphique est franchement mieux pensée, et les états/variables sont a portée de souris.
oui c’est vrai, on répond selon ses habitudes, j’aime bien les trigger je les utilise depuis le début et perso je trouve ça lisible mais chacun des gouts
dans ce cas l’automatisation bien pensée ne sert pas à grand chose
C’est exactement ainsi que j’aurais fait aussi
Autant de passer du yaml c’est assez faisable
Pour les templates en jinga par contre c’est quasiment impossible
Pour faire la même chose sans avoir à faire la liste des capteurs et sans utiliser les groups qui ne remontent pas l’entité qui a déclenché, le plus simple aujourd’hui est de passer par les labels.
Tu mets ensuite le label en trigger et il ça remontera l’entité declencheuse
Bon pour 2 capteurs c’est pas vraiment nécessaire.
oui j’ai essayé de faire ça pour mes vannes sonoff, mais ça m’a posé problème, ce n’était pas adapté pour l’envoi des consignes, mais pour remonter des infos dans l’autre sens ça marche
Tout dépends ce que tu appelles full ui. C’est pas parce que pour une condition template il faut du jinja qu’on ne peut pas le faire en full ui, mais forcément le template ne se fera pas avec des clics, il faudra le taper.
Par contre tout ça ça peut se faire dans l’Ui automatisation sans même avoir besoin de faire, modifier en yaml
Je sais pas précisément ce que les gens entendent pas là, moi ce que je comprends de la question initiale et des remarques qu’on me fait régulièrement, c’est de ne pas passer par les « switch to yaml » ou par des blocs codes, et de toujours faire quelque chose qui peut ensuite s’ouvrir via l’interface, donc pas le bloc qui dit qu’on ne peut pas éditer ce noeud autrement que par du yaml.
Sinon de mon côté ce n’est pas très problématique je bascule de l’un à l’autre sans soucis, c’est juste que j’évite de le faire pour avoir toujours quelque chose de démontrable dans l’interface.
Par contre je suis curieux de creuser cette histoire de labels. Mais je ne veux pas polluer la question initiale, mais je crois que ca va dans le même sens.
L’idée de la question d’origine c’était bien d’avoir comme déclencheur un groupe de capteur, mais ensuite d’en extraire le ou les capteurs du groupe qui ont permis le déclenchement, c’est bien ça ?
Parce que j’ai travaillé toutes mes alarmes ainsi, pour les zones, les types (perimétrique, volumétrique, nuit …) ce qui rend le tout très modulaire, y a pas besoin de retoucher les automatisations quand on change de capteur ou d’avis dans le placement.
Et donc on a à un moment donné un déclencheur groupe, et il faut en extrairement le ou les élements qui sont la source du déclenchement.
Je suis dans le sujet initial ?
mode: single
variables:
monitored_entities:
- binary_sensor.groupe_incendie
triggers:
- trigger: state
entity_id: alarm_control_panel.securite_incendie
to: triggered
actions:
- parallel:
- action: script.notification_smartphone
data:
title: 🔥 Incendie
severity: critical
message: >-
{% from 'macros.jinja' import format_sensors %} Alarme déclenchée !
{% set panel_sensors = state_attr(trigger.entity_id, 'sensors') %}
{% if panel_sensors %}
Capteur : {{ format_sensors(panel_sensors) }}
{% else %}
{# On filtre les capteurs surveillés qui sont actuellement à 'on' #}
{% set active = monitored_entities | select('is_state', 'on') | list %}
Capteur : {{ format_sensors(active) }}
{% endif %}
- action: script.alerte_incendie
description: ""
Attention, le yaml ça reste un moyen d’écrire ses automatisations. Il ne faut pas faire d’amalgame.
Tu passes pas l’UI native pour faire tes automations en YAML ou avec les blocs, tout va bien.
Tu prends un éditeur de fichier, tu tapes dans le fichier natif automatisation.yaml, là c’est pas.
Mon avis est que faire un groupe pour une automatisation, c’est pas plus simple que de faire X triggers individuels (avec le même ID s’il le faut). En plus de devoir créer une entité de plus (historique etc)
Les groupes sont bien pour les comptages etc, mais pour la gestion des états c’est beaucoup moins pertinant
dans ce cas l’automatisation bien pensée ne sert pas à grand chose