bonjour,
j’arrive a créer un input_select dynamique, avec les identités des capteurs de température:
- id: "z_maj_test2_z000"
alias: z_maj_test2_z000
description: ""
trigger:
- platform: state
entity_id:
- input_boolean.z_maj_z000
from: "off"
to: "on"
condition: []
action:
- service: input_select.set_options
data:
entity_id: input_select.z_choix_capteur_z000
options: >
{% set entities = states | selectattr('entity_id', 'match', 'sensor.*temp.*') | map(attribute='entity_id') %}
{{ entities | list if entities else ["none"] }}
- service: input_select.select_first
data: {}
target:
entity_id: input_select.z_choix_capteur_z000
mode: single
une fois lancé, le script remplit correctement l input_select en question:
super…
mais ensuite il est impossible de récupérer la valeur choisie.
par exemple récupérer la valeur pour la mettre dans un input_text:
action:
- service: input_text.set_value
data:
value: "{{ states('input_select.z_capteur_z000') }}"
target:
entity_id: input_text.z_capteur_z000
donne tout le temps:
donc:
comment donc récupérer la valeur choisie dans l’input_select ?
Personne ?
je suis bloqué dans l’écriture de mon magnifique chauffage 
(ca va qu’il ne fait pas encore trop froid.)
C’est pas clair… En dehors de ne pas bien voir ce que tu veux faire avec les valeurs qui circulent d’intput_texte en input_text, il manque des infos
Ton erreur est due au fait que ce que la valeur que tu utilise dans ton input_text.set_value n’existe pas
Tu affectes les options suivantes => les noms de tous tes sensors…
On le voit d’ailleurs très bien sur ta capture d’écran également
Et là ton code est une mise à jour de la valeur de l’input_text (pas une récupération comme tu l’ecrit). Et tu cherche à mettre un truc qui est une valeur (à cause du state)… sur un input_text qui n’a pas le même nom et dont tu ne donnes pas la définition.
input_text.z_capteur_z000 (pas input_select.z_choix_capteur_z000 ni input_boolean.z_maj_z000)
Donc c’est peut-être pas le bon service (set /get ?) et sauf à ce que input_text existe bien et que toutes les valeurs possibles de tous tes capteurs soient déjà une option définie, ça coince
@Pulpy-Luke merci de la réponse,
le premier code est bien pour récupérer les entity_id des sensors qui retournent une température pour peupler un input_select
1 passer de la valeur de l input_select a un input_text est juste un test pour récupérer la dite valeur
2 la meme syntaxe fonctionne avec d’autres input_select codés « en dur » (non dynamiques)
action:
- service: input_text.set_value
data:
value: "{{ states('input_select.z_offset_duree_z000') }}"
target:
entity_id: input_text.z_capteur_z000
mode: single
transfère bien la valeur choisie dans input_select.z_offset_duree_z000 dans :input_text.z_capteur_z000 (qui existe évidement 
)
bref ca fonctionne SAUF dans un input_select dynamique, malgrè la copie presque directe de la doc Input Select - Home Assistant
(derniers paragraphes)
la seule différence est donc la création dynamique de l input_select de départ.
et pourtant l’affichage du selecteur est bien mis à jour 
j’ai essayé tous les services liés à input_select sans succès
impasse donc ?
D’autres ? Les mêmes codés en dur plutôt, si ça matche pas ça marche pas.
Tu as 2 vérifications à faire :
- Récupères-tu bien la bonne selection de l’input en entrée => AKA un nom de sensor
- Y a-t-il une stricte égalité de ta valeur avec une de la liste des options de l’input en sortie
@Pulpy-Luke
désolé, je ne comprends pas:
D’autres ? Les mêmes codés en dur plutôt, si ça matche pas ça marche pas.
l’exemple en détail IS de test:
input_select:
# input_select z_offset_duree_z000 vvvvvvvvvvvvvvvvvvvvvvvvvvvv
z_offset_duree_z000:
name: Durée d'action
options:
- arret
- auto
- 1 h
- 2 h
- 3 h
- 6 h
- 24 h
- 2 jours
- 3 jours
- sans fin
initial: auto
# ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
et: récupération de la valeur choisie avec remplissage de IT
action:
- service: input_text.set_value
data:
value: "{{ states('input_select.z_offset_duree_z000') }}"
target:
entity_id: input_text.z_capteur_z000
mode: single
donne:
et en déclenchant la MAJ de input_text.:
donc OK
je ne comprends pas non plus:
- Récupères-tu bien la bonne selection de l’input en entrée => AKA un nom de sensor
en réalité ici on ne manipule que des strings (la valeur n’importe pas)
en l occurrence ce sont bien les noms corrects:
- Y a-t-il une stricte égalité de ta valeur avec une de la liste des options de l’input en sortie
désolé je ne comprends pas non plus: 
Si tu donnes à chaque fois des trucs différents ça rends pas les choses plus simples …
Très simplement :
Imaginons un input avec 2 options A et B… Si tu essaye de le valoriser avec 3 ou avec C ça marche pas et ça affichera unknown. Tu ne peux y mettre via une automatisation que A ou B
Donc dans ton exemple si input_select.z_offset_duree_z000 et input_text.z_capteur_z000 n’ont pas la MEME liste d’option, tu ne peux pas affecter la valeur de l’un à l’autre.
Imaginons un input avec 2 options A et B… Si tu essaye de le valoriser avec 3 ou avec C ça marche pas et ça affichera unknown. Tu ne peux y mettre via une automatisation que A ou B
ok MAIS je ne change le selecteur que manuellement avec donc les options disponibles visuellement (que connait HA donc)
Donc dans ton exemple si input_select.z_offset_duree_z000 et input_text.z_capteur_z000 n’ont pas la MEME liste d’option, tu ne peux pas affecter la valeur de l’un à l’autre.
C’est quoi une liste d’option pour un input_text ?
le chemin est TOUJOURS depuis input_select > choix manuel > vers input_text…
Quand la liste est faite à la création du sensor, qu’elle soit dynamique ou pas ça ne doit pas changer
Si ça s’affiche, elle existe et donc tu dois pouvoir lire cette valeur. C’est quoi le déclaration yaml correspondante ?
Là tu réécrases la liste dans l’automatisation… pourquoi pas même si je vois pas bien l’usage
Effectivement méprise de ma part, pas d’option dans un input_text
Oui mais je comprends pas pour autant l’objectif dans le cas de la gestion de ton chauffage
Je vais monter un exemple ici
exactement …
pourquoi je n’arrive pas à récupérer la valeur choisie ?
Je parle bien de ta déclaration yaml, pas du code dans l’automatisation
Parce que personnellement ton code d’automatisation légèrement adapté ne produit pas l’effet attendu de setter les options correctement dans le bloc auto
VS rale mais HA valide la syntaxe
Bon ben ça marche à condition de bien passer par une automatisation pour construire la liste …
Donc la question se pose de l’efficacité / pertinence / usage / simplicité pour ma part
@Pulpy-Luke
si j arrive à lire c’est pour lister les entity_id qui sont des input_select, puis peupler un autre input_select avec leurs noms…
ca doit marcher, c’est pas ce que j’avais écrit
ca ressemble sur le principe
mais je ne vois pas l’utilité (en dehors de démonstration)
pour moi:
1 déclaration manuelle d’un imput_select peuplé de valeurs temporaires
2 peuplement automatique de ce selecteur par les capteurs renvoyant une température, le nom et le nombre de ces capteurs actifs peuvent varier d’un jour à l’autre
3 choix manuel d’un de ces capteurs dans le selecteur
(jusqu’ici ca marche)
4 affichage du graphique du capteur demandé (avec une étape de mise au point qui est donc de simplement récupérer le choix en N°3)
…et la donc ca coince
je peux voir le code yaml de la derniere image ? 
Oui j’ai juste pris une série d’entités dispos dans l’environnement
Aucun, c’est pour l’exemple
Mouais, tes points de chauffage et tes sondes varient tant que ça ??
Tout ça pour afficher un graphique d’une entité à la demande ??? Je vois au moins 3 trucs archi plus simples :
- Les cartes plotly qui sont dynamiques, avec multiaffichage à la demande
- Les cartes conditionnelles (n’afficheraient que l’entité sélectionnée par exemple)
- Les slides card
oui, rien de très différent de ton code
Les inputs
input_select:
monselectmanu:
options:
- "modeA"
- "modeB"
- "modeC"
monselectauto:
options: >-
{% set entities = states | selectattr('entity_id', 'match', 'input_select.*') | map(attribute='entity_id') %}
{{ entities | list if entities else ["none"] }}
input_text:
textmanu:
textauto:
Les automatisations
- id: '1664821258242'
alias: Manu
description: ''
trigger:
- platform: state
entity_id:
- input_select.monselectmanu
condition: []
action:
- service: input_text.set_value
data:
value: '{{states(''input_select.monselectmanu'')}}'
target:
entity_id: input_text.textmanu
mode: single
- id: '1664822122371'
alias: Auto
description: ''
trigger:
- platform: state
entity_id:
- input_select.monselectauto
condition: []
action:
- service: input_text.set_value
data:
value: '{{states(''input_select.monselectauto'')}}'
target:
entity_id: input_text.textauto
mode: single
- id: '1664823213255'
alias: set
description: ''
trigger: []
condition: []
action:
- service: input_select.set_options
data:
entity_id: input_select.monselectauto
options: '{% set entities = states | selectattr(''entity_id'', ''match'', ''input_select.*'')
| map(attribute=''entity_id'') %} {{ entities | list if entities else ["none"]
}}'
mode: single
J’ai juste séparé l’automation de maj et celle de création de la liste
Note qu’au (re)démarrage chez moi la liste est vide… c’est pas pratique du tout
Les cartes
type: entities
entities:
- entity: input_select.monselectmanu
- entity: input_text.textmanu
title: Manu
type: entities
entities:
- entity: input_select.monselectauto
- entity: input_text.textauto
title: Auto
merci pour ces renseignements
je vais regarder tout ca à tete reposée et essayer de reproduire ce qui marche et ce qui ne marche pas
bien sur/ sans doute…mais le but est de tout écrire en natif pour mieux comprendre le fonctionnement de HA
encore merci
je ferai une MAJ avec le code définitif si j’y arrive ce WE
bonne soirée
C’est relatif à mon avis. Refaire en moins efficace (forcément puisque c’est pour apprendre et donc sans véritable expérience) des choses qui s’avèrent lourdes en maintenance, pas forcément faites dans les règles de l’art, longues voire impossible à retravailler à posteriori c’est pas un bon investissement de temps.
Sans compter que les 2 derniers points sont natifs à HA…
tout ça pour ça…
la honte…
ça fonctionne !
en fait ça fonctionne depuis le début, en particulier en corrigeant une faute de frappe dans mon script
j’ai tout repris, il n’y avait pas de raison que ça marche avec Pulpy et pas avec moi.
en réécrivant tout, donc c’est OK.
le problème venait du nom de l’input_select…
la honte quoi !
@Pulpy-Luke encore merci d’avoir debugger tout ça.
PS pour éviter un input_select vide au premier lancement:
soit le declarer avec une valeur initale genre « initialisation »
soit lancer le script de peuplement au démarrage de HA
merci encore
Parfait si ça marche aussi chez toi. Bon courage pour la suite qui ne semble pas si simple vu d’ici
