J’aimerais savoir si c’était possible d’avoir un switch virtuel affichant la même information pour pouvoir requêter ce switch et faire une query dessus (envoyer l’information par sms).
Salut
Tu peux créer un groupe de capteurs binaires avec tes différents sensors.
Appareils et services → Entrées → Créer une entrée
Tu choisis groupe et ensuite groupe de capteurs binaires.
Je n’ai pas compris ce que tu veux faire avec ce switch virtuel.
Car si tu dis « switch » ça sous entend quelque chose de binaire avec des états on ou off.
Mais du coup je ne vois pas ce que tu entends par faire des query dessus.
Donc que voudrais tu comme résultat, as tu des exemples plus concrets de ce que tu cherches?
Effectivement je n’ai pas bien exprimé le besoin et le mot switch n’est pas forcément adapté.
En fait je veux juste avoir une entité (ou autre peu importe) qui me dise quelle port est ouverte à l’instant présent. C’est ce que fais le lovelace.
Comme ça, avec une requête curl via l’API, je pourrais envoyer cette information par sms.
Par exemple, j’utilise cette automation le soir qui se déclenche si une ou plusieurs portes sont ouvertes et qui me dit lesquelles :
alias: All_Doors_Not_Closed
description: ''
trigger:
- platform: time
at: '23:30:00'
condition:
- condition: template
value_template: >-
{{ states | selectattr('entity_id', 'in',
state_attr('group.all_doors_windows','entity_id')) |
selectattr('state','in',['on','open']) | list | length >= 1 }}
action:
- service: switch.turn_on
data: {}
target:
entity_id: switch.sound_warning_all_doors_not_closed
- service: switch.turn_on
data: {}
target:
entity_id: switch.all_doors_not_closed
- service: notify.notify
data_template:
title: Tout n'est pas fermé
message: >
{% set open_windows = ( states | selectattr('entity_id', 'in',
state_attr('group.all_doors_windows','entity_id')) |
selectattr('state','in',['on','open']) | list | map(attribute='name') |
join(', ') ) %} Les portes ou fenêtres suivantes ne sont pas fermées: {{
open_windows }}
mode: single
en théorie tu peux créer une entité de type input_text dans « Appareils et services > Entrées > Créer une entrée ».
Et ensuite changer sa valeur avec une automatisation qui se déclenche à chaque changement d’état d’un des capteurs, en utilisant une logique comme celle que tu utilise déjà.
Un input_text peut se mettre à jour avec le service input_text.set_value
ça dépends …
La logique voudrais que si AUCUNE fenêtre n’est ouverte, elles sont toutes FERMEES, non ?
Après, très honnêtement, je vois mal la finalité de cette config.
Si c’est juste pour afficher/obtenir une info (=nb de fenêtres ouvertes), pas besoin d’une automatisation pour calculer tout ça : Pour moi un bête sensor template, avec quasi le même code que le trigger suffit.
ça ME semble plus léger qu’un input_text (qui est plutot destiné à un usage manuel pour choisir parmi une liste) + une automatisation pour le remplir avec un texte (qui ajourd’hui est fixe…)
Tout a fait d’accord avec Pulpy-Luke, il faut 2 sensors pour moi, 1 qui donne le nombre de porte ouverte, et un autre qui te donnera le ou les noms des portes ouverte que tu pourras envoyer par sms.
largement plus simple qu’une automation, et cela se met a jour en live.
Même sur celui là, c’est peut-être pas la peine de faire un sensor… On établit la liste au moment du message (dans l’automatisation d’envoi)
Comme ça, on évite les recalculs réguliers et l’historique en base.
Au pire, en attribut du 1er sensor
merci pour ton aide 
