Galère … Moi qui voulait migrer tous mes capteurs dans les yaml pour pouvoir gérer au petit oignons ma configuration. Il va falloir que je fasse retour arrière 
Je voulais par exemple créer mes utilisateurs via les yaml pour pouvoir définir moi-même des ID « compréhensibles », ce qui m’aiderait lorsque j’utilise l’attribut visible dans mes views.
C’est pas incompatible. Tu peux renommer toutes les entités qui sont créées par l’IHM.
Sur le papier la configuration par IHM a plus de fonctionnalités que la configuration par YAML.
1 « J'aime »
Où peut-on trouver de la doc sur « élément » configurable dans HA.
Exemple,
- je cherche à créer mes utilisateurs dans Yaml, est-ce qu’il existe de la doc sur les « personnes ».
- je cherche aussi à « déplacer » mes sensors de la configuration de l’IHM vers des fichiers yaml, où puis-je trouver de la doc là dessus à part dans les configurations des autres (qui m’aident vraiment d’ailleurs)
Bonjour,
Je commence à m’intéresser à l’organisation du fichier configuration.yaml, la lecture de ce tuto m’a éclairé une bonne partie des choses, mais il me reste des interrogations en suspend.
- Est-il possible d’avoir dans ce tuto un lien vers la structure à suivre (sur un tuto interne
, ou un lien externe 
), indentation à utiliser (je sais qu’il en faut une, sinon ça ne fonctionne pas, mais 1; 2; 4 espaces, ou une tabulation ???), la présence des tirets, le dièse pour le commentaire, … Aussi, ce qui n’est pas dans la structure, mais participe au langage yaml, pourquoi des [], pourquoi des simple quote alors que dès fois non, je crois que j’ai aussi vu des accolades dans certains exemple sur le forum. - Quand HASS est installé, il y a déjà des choses dans le configuration.yaml, à quoi correspondent-ils ? Sont-ils nécessaire ? En grand débutant, je n’ose pas les supprimer, est-ce que ça a un impact ???
- Dans le tuto, il est indiqué comment séparer dans différents fichier (ce que je préfère), et je me doute qu’il est même possible de mettre ces fichiers dans un dossier, voir un dossier par type puis un fichier par " sous-type ". Comment est-ce faisable ? Peut-être à rajouter au tuto, si ça n’allourdi pas trop.
- Plus haut Yul a indiqué une méthode pour fusionner des fichiers dans un dossier, ce qui semble être sympa, mais en même temps il est indiqué qu’il faut mettre ça sous forme de liste, et là j’ai été complètement perdu (vu que les listes n’ont pas été présentées jusque là). Pour avoir une liste, il faut quelque chose qui l’initie (au niveau 0 d’intentation) ? On peut mettre directement des listes en vrac ?
- Peut-être évoquer les fichiers secrets, pour partager sa configuration sans problème de sécurité. Je crois avoir compris le principe, mais je voudrais bien consolider ce point aussi.
Voilà, j’ai un peu poser mes questions en vrac, mais je voudrais par mes questions de grand novice aider les suivants à faciliter l’apprentissage.
EDIT : ajout du point n°5
1 « J'aime »
Bon, pour bien comprendre le sujet, j’ai lu la doc Splitting up the configuration - Home Assistant, et j’en ai profité pour la traduire ci-dessous, comme proposé par @oncleben31 plus haut.
C’est une base de traduction, vous pouvez l’adaptez à votre guise.
Surtout que certaines partie n’étant pas totalement comprise par moi-même j’ai pu bêtement traduire sans voir si c’était toujours correct.
Scinder la configuration
Vous utilisez Home Assistant depuis un certain temps déjà et votre fichier configuration.yaml devient incompréhensible, ou tout simplement, vous voulez commencer avec l’approche distribué de ce fichier. Voici comment commencer scinder le configuration.yaml en morceaux plus compréhensible (lire : pour les humains).
Tout d’abord, plusieurs membres de la communauté ont nettoyé (lire : sans clés/mots de passe API, etc.) les versions de leurs configurations disponibles pour consultation, vous pouvez en voir la liste ici, et certains membre de HACF disponible dans la Awesome List disponible ici.
Avant de vous jeter dessus, prenez le temps de lire ce qui suit. Ça facilitera la compréhension, surtout quand il n’y a pas de commentaire (assez explicite) dans les fichiers.
Maintenant, malgré le fait que nous allons découper le fichier configuration.yaml dans les explications plus bas, ce fichier va dans tous les cas continuer à exister, bien que sous forme bien moins encombrante, voir presque complètement dénudé.
Dans cette version plus légère, nous aurons encore besoin de ce que l’on pourrait appeler le code principal (exemple) :
homeassistant:
# Name of the location where Home Assistant is running
name: My Home Assistant Instance
# Location required to calculate the time the sun rises and sets
latitude: 37
longitude: -121
# 'metric' for Metric, 'imperial' for Imperial
unit_system: imperial
# Pick yours from here: http://en.wikipedia.org/wiki/List_of_tz_database_time_zones
time_zone: America/Los_Angeles
customize: !include customize.yaml
Notez que chaque ligne après homeassistant: est indentée de deux (2) espaces. Comme les fichiers de configuration de Home Assistant sont basés sur le langage YAML, l’indentation et l’espacement sont importants. Notez également que l’entrée apparemment étrange après customize:
!include nomdefichier.yaml est la déclaration qui indique à Home Assistant d’insérer le contenu de nomdefichier.yaml à ce moment-là. C’est ainsi que nous allons pouvoir décomposer un fichier monolithique et difficile à lire (lorsqu’il devient volumineux) en morceaux plus faciles à gérer.
Maintenant, avant de commencer à répartir les différents composants, examinons les autres intégrations (dans notre exemple) qui resteront dans le fichier de base :
history:
frontend:
logbook:
http:
api_password: ImNotTelling!
ifttt:
key: [nope]
wink:
access_token: [wouldn't you]
refresh_token: [like to know]
zwave:
usb_path: /dev/ttyUSB0
config_path: /usr/local/share/python-openzwave/config
polling_interval: 10000
mqtt:
broker: 127.0.0.1
Comme pour le code principal, l’indentation fait la différence. Les en-têtes d’intégration (par exemple : mqtt:) doivent être alignés à gauche (sans indentation), et les paramètres (tel que : broker:) doivent être indentés de deux (2) espaces.
Notez qu’il est techniquement possible de séparer ces intégrations de ce fichier. A vous de mesurer les avantages/inconvénients pour de si petites et " uniques" intégrations.
Vous remarquerez également le symbole # (dièse). Il débute une ligne de commentaire, dans la mesure où ce qui suit sur la même ligne ne sera pas interprété. Cela améliore la lisibilité du fichier, permet de désactiver des fonctionnalités ou de laisser une explication sur ce qui l’entoure.
Supposons désormais qu’un fichier vierge ait été créé dans le répertoire de configuration de Home Assistant pour chacun des éléments suivants :
automation.yaml
zone.yaml
sensor.yaml
switch.yaml
device_tracker.yaml
customize.yaml
automation.yaml contiendra tous les détails d’intégration de l’automatisation. zone.yaml contiendra les détails d’intégration de la zone, etc. Ces fichiers peuvent être nommés de la façon que vous désirez, mais leur donner des noms correspondant à leur fonction facilitera le suivi, et le partage avec les autres membres (aussi bien pour avoir de l’aide que pour aider quelqu’un d’autre).
Ce qui induit que le fichier configuration.yaml doit contenir les lignes suivantes :
automation: !include automation.yaml
zone: !include zone.yaml
sensor: !include sensor.yaml
switch: !include switch.yaml
device_tracker: !include device_tracker.yaml
Attention, l’imbrication des !include (le fait d’avoir un !include dans un fichier qui est lui-même !include) ne fonctionnera pas. Vous pouvez cependant avoir plusieurs !include de haut niveau pour une intégration donnée, si vous donnez un label différent à chacun d’entre eux, par exemple :
light:
- platform: group
name: Bedside Lights
entities:
- light.left_bedside_light
- light.right_bedside_light
# define more light groups in a separate file
light groups: !include light-groups.yaml
# define some light switch mappings in a different file
light switches: !include light-switches.yaml
Avec !include light-groups.yaml pouvant ressembler à ceci :
- platform: group
name: Outside Lights
entities:
- light.porch_lights
- light.patio_lights
Et !include light-switches.yaml à cela :
- platform: switch
name: Patio Lights
entity_id: switch.patio_lights
- platform: switch
name: Floor Lamp
entity_id: switch.floor_lamp_plug
Très bien, nous avons donc les intégrations uniques et les déclarations d’inclusion dans le fichier de base, mais que peut-on mettre dans ces fichiers supplémentaires ?
Regardons un exemple issue de la documentation officielle d’Home Assistant, device_tracker.yaml :
- platform: owntracks
- platform: nmap_tracker
hosts: 192.168.2.0/24
home_interval: 3
track_new_devices: true
interval_seconds: 40
consider_home: 120
Ce petit exemple illustre le fonctionnement des fichiers " split". Dans ce cas, nous commençons avec deux entrées de suivi de périphérique (owntracks et nmap). Ces fichiers suivent le « style 1 », c’est-à-dire une entrée de tête alignée entièrement à gauche (- platform: owntracks) suivie des entrées de paramètres indentées de deux espaces.
Voici un autre exemple de configuration, avec une sonde (sensor) plus complexe :
### sensor.yaml
### METEOBRIDGE #############################################
- platform: tcp
name: 'Outdoor Temp (Meteobridge)'
host: 192.168.2.82
timeout: 6
payload: "Content-type: text/xml; charset=UTF-8\n\n"
value_template: "{{value.split (' ')[2]}}"
unit: C
- platform: tcp
name: 'Outdoor Humidity (Meteobridge)'
host: 192.168.2.82
port: 5556
timeout: 6
payload: "Content-type: text/xml; charset=UTF-8\n\n"
value_template: "{{value.split (' ')[3]}}"
unit: Percent
#### STEAM FRIENDS ##################################
- platform: steam_online
api_key: [not telling]
accounts:
- 76561198012067051
#### TIME/DATE ##################################
- platform: time_date
display_options:
- 'time'
- 'date'
- platform: worldclock
time_zone: Etc/UTC
name: 'UTC'
- platform: worldclock
time_zone: America/New_York
name: 'Ann Arbor'
Vous remarquerez que cet exemple comprend une section de paramètres secondaires (sous la section STEAM) ainsi qu’un meilleur exemple de la façon dont les commentaires peuvent être utilisés pour décomposer les fichiers en sections.
Si vous avez des problèmes, consultez le fichier home-assistant.log dans le répertoire de configuration ainsi que vos indentations. Si malgré tout, ça ne fonctionne pas, n’hésitez pas à poser vos questions sur ce forum ou sur Discord.
2 « J'aime »
Là, j’ai tout simplement traduit, et je n’ai pas compris où allait les différentes commandes… Je présume que c’est dans un terminal, via une connexion SSH, mais il y a peut-être un endroit dans HASS où le mettre ???
Je veux bien que vous m’éclairiez sur ce point, pour mettre à jour cette traduction.
Débogage de plusieurs fichiers de configuration :
Si vous disposez de nombreux fichiers de configuration, le script check_config vous permet de voir comment Home Assistant les interprète. Ces commandes sontt utilisable via via l’add-on SSH & Web Terminal :
- Lister tous les fichiers chargés :
hass --script check_config --files - Visualisation de la configuration d’un composant :
hass --script check_config --info light - Ou la configuration de tous les composants :
hass --script check_config --info all
Vous pouvez obtenir de l’aide sur la ligne de commande en utilisant :hass --script check_config --help
1 « J'aime »
La commande hass est un script Linux de HassCore, donc s’y connecter en SSH via l’add-on ‹ SSH & Web Terminal ›.
Merci @Pozzi pour ce détail, j’ai mis à jour la traduction en conséquence.
Du coup, je continue et fini la traduction de cette documentation. En espérant que ça puisse servir à d’autres.
Utilisation avancée :
Il existe quatre options avancées pour inclure des répertoires entiers en une seule fois. Veuillez noter que vos fichiers doivent porter l’extension de fichier .yaml, le format .yml n’est pas pris en charge.
-
!include_dir_listrenvoie le contenu d’un répertoire sous forme de liste, chaque contenu de fichier étant une entrée dans la liste. Les entrées de la liste sont classées selon l’ordre alphanumérique des noms des fichiers. -
!include_dir_namedrenverra le contenu d’un répertoire sous la forme d’un dictionnaire qui met en correspondance nom de fichier => contenu du fichier. -
!include_dir_merge_listrenvoie le contenu d’un répertoire sous forme de liste en fusionnant tous les fichiers (qui doivent contenir une liste) en une seule grande liste. -
!include_dir_merge_namedrenverra le contenu d’un répertoire sous forme de dictionnaire en chargeant chaque fichier et en le fusionnant dans un grand dictionnaire.
Ces options fonctionnent de façon récurcives. À titre d’exemple, en utilisant !include_dir_* automation, comprendra les 6 fichiers indiqués suivant :
.
└── .homeassistant
├── automation
│ ├── lights
│ │ ├── turn_light_off_bedroom.yaml
│ │ ├── turn_light_off_lounge.yaml
│ │ ├── turn_light_on_bedroom.yaml
│ │ └── turn_light_on_lounge.yaml
│ ├── say_hello.yaml
│ └── sensors
│ └── react.yaml
└── configuration.yaml (non inclus)
Voir mes posts ci-dessous pour les exemples de chacune des options.
EDIT : je voulais mettre 1 exemple par post, pour plus de simplicité, mais je ne peux pas poster plus de 3 messages à la suite…
Exemple : !include_dir_list
À l’origine, seulement le fichier configuration.yaml contenant :
automation:
- alias: Automation 1
trigger:
platform: state
entity_id: device_tracker.iphone
to: 'home'
action:
service: light.turn_on
entity_id: light.entryway
- alias: Automation 2
trigger:
platform: state
entity_id: device_tracker.iphone
from: 'home'
action:
service: light.turn_off
entity_id: light.entryway
Avec cette option, cela devient :
-
configuration.yaml:
automation: !include_dir_list automation/presence/
-
automation/presence/automation1.yaml:
alias: Automation 1
trigger:
platform: state
entity_id: device_tracker.iphone
to: 'home'
action:
service: light.turn_on
entity_id: light.entryway
-
automation/presence/automation2.yaml:
alias: Automation 2
trigger:
platform: state
entity_id: device_tracker.iphone
from: 'home'
action:
service: light.turn_off
entity_id: light.entryway
Il est important de noter que chaque fichier ne doit contenir qu’une seule entrée lorsque vous utilisez !include_dir_list.
Il est également important de noter que si vous fractionnez un fichier après avoir ajouté -id : pour prendre en charge l’interface utilisateur d’automatisation, la ligne -id : doit être supprimée de chacun des fichiers fractionnés.
Exemple : !include_dir_named
À l’origine, seulement le fichier configuration.yaml contenant :
alexa:
intents:
LocateIntent:
action:
service: notify.pushover
data:
message: Your location has been queried via Alexa.
speech:
type: plaintext
text: >
{%- for state in states.device_tracker -%}
{%- if state.name.lower() == User.lower() -%}
{{ state.name }} is at {{ state.state }}
{%- endif -%}
{%- else -%}
I am sorry. Pootie! I do not know where {{User}} is.
{%- endfor -%}
WhereAreWeIntent:
speech:
type: plaintext
text: >
{%- if is_state('device_tracker.iphone', 'home') -%}
iPhone is home.
{%- else -%}
iPhone is not home.
{% endif %}
Avec cette option, cela devient :
-
configuration.yaml:
alexa:
intents: !include_dir_named alexa/
-
alexa/LocateIntent.yaml:
action:
service: notify.pushover
data:
message: Your location has been queried via Alexa.
speech:
type: plaintext
text: >
{%- for state in states.device_tracker -%}
{%- if state.name.lower() == User.lower() -%}
{{ state.name }} is at {{ state.state }}
{%- endif -%}
{%- else -%}
I am sorry. Pootie! I do not know where {{User}} is.
{%- endfor -%}
-
alexa/WhereAreWeIntent.yaml:
speech:
type: plaintext
text: >
{%- if is_state('device_tracker.iphone', 'home') -%}
iPhone is home.
{%- else -%}
iPhone is not home.
{% endif %}
Exemple !include_dir_merge_list
À l’origine, seulement le fichier configuration.yaml contenant :
automation:
- alias: Automation 1
trigger:
platform: state
entity_id: device_tracker.iphone
to: 'home'
action:
service: light.turn_on
entity_id: light.entryway
- alias: Automation 2
trigger:
platform: state
entity_id: device_tracker.iphone
from: 'home'
action:
service: light.turn_off
entity_id: light.entryway
Avec cette option, cela devient :
-
configuration.yaml:
automation: !include_dir_merge_list automation/
-
automation/presence.yaml:
- alias: Automation 1
trigger:
platform: state
entity_id: device_tracker.iphone
to: 'home'
action:
service: light.turn_on
entity_id: light.entryway
- alias: Automation 2
trigger:
platform: state
entity_id: device_tracker.iphone
from: 'home'
action:
service: light.turn_off
entity_id: light.entryway
Il est important de noter que lorsque vous utilisez !include_dir_merge_list, vous devez inclure une liste dans chaque fichier (chaque élément de la liste est désigné par un trait d’union [-]). Et que chaque fichier peut contenir une ou plusieurs entrées.
Exemple : !include_dir_merge_named
À l’origine, seulement le fichier configuration.yaml contenant :
group:
bedroom:
name: Bedroom
entities:
- light.bedroom_lamp
- light.bedroom_overhead
hallway:
name: Hallway
entities:
- light.hallway
- thermostat.home
front_yard:
name: Front Yard
entities:
- light.front_porch
- light.security
- light.pathway
- sensor.mailbox
- camera.front_porch
Avec cette option, cela devient :
-
configuration.yaml:
group: !include_dir_merge_named group/
-
group/interior.yaml:
bedroom:
name: Bedroom
entities:
- light.bedroom_lamp
- light.bedroom_overhead
hallway:
name: Hallway
entities:
- light.hallway
- thermostat.home
-
group/exterior.yaml:
front_yard:
name: Front Yard
entities:
- light.front_porch
- light.security
- light.pathway
- sensor.mailbox
- camera.front_porch
Exemple : combiner !include_dir_merge_list avec automations.yaml
Vous voulez passer à l’étape avancée et diviser vos automatismes, mais vous voulez quand même pouvoir créer des automatismes depuis l’interface graphique ?
Comme indiqué plus haut, il est possible d’imbriquer les includes. Voici comment nous pouvons faire cela pour les automatismes.
L’utilisation d’étiquettes comme manual ou ui permet d’utiliser plusieurs clés dans la configuration :
configuration.yaml :
# automations faites à la main
automation manual: !include_dir_merge_list automations/
# automations créées via l’interface graphique
automation ui: !include automations.yaml
1 « J'aime »
@Tank pour mettre en valeur ton travail je te propose, si tu le veux bien, de mettre ta traduction dans un nouveau post. Tu peux le faire toi même soit un @responsables peut le faire pour toi et bien sûr il sera remis à ton nom.
C’est un très bon travail. Peut être même une catégorie a part a voir.
Je veux bien le mettre dans un post dédié, juste m’indiquer où le créer.
Aussi, dans le cas où je crérais le sujet, est-ce que je serais toujours bloquer à 3 post de suite ?
Si je ne suis pas bloqué par cette limite, je pourrais découper les éléments en différents posts, pour pouvoir en faire des liens assez facilement.
Salut normalement oui tu seras toujours bloqué à 3 post mais pourquoi ne pas les mettre dans le même post ?
Même nous (staff) sommes bloqué à 3 d’affiliés (il faut regrouper tes messages)…
Créé un nouveau topic/sujet/fil (et non post… Marty ! 
) dans #decouverte-de-home-assistant:general (ici) si tu veux et on mettra un lien dans celui-ci.
Personnellement, je pense qu’il vaille mieux compléter le 1er post de ce tutoriel et préconiser l’utilisation de la méthode packages avec un lien vers l’awesone list des configurations partagées
7 messages ont été fusionnés à un sujet existant : 
Compte utilisateur communautaire
Je viens de créer un nouveau sujet pour ceci :
https://forum.hacf.fr/t/scinder-la-configuration/2480
Je pense donc que je vais « vider » mes messages au-dessus.
Le fait de pouvoir faire plus que 3 post d’affilé dans le même sujet, m’aurait permis de séparer chaque titre dans un post. Ainsi, chacun a son lien, pour être partagé avec le reste de la communauté en cas de questions sur un point précis (particulièrement vrai ici pour les exemples).
Je comprends ta remarque, mais cela fait aussi système anti-spam.
Nous avons la possibilité de définir une table des matières si les titres markdown sont bien respectés. De cette façon il y aura automatiquement un lien sur chaque titre et ils pourront être partagés indépendamment de tout le sujet ! A voir avec les @Moderateur
Autre point, si ton article est une traduction même partielle d’un article original, il faut mettre le lien vers cet article comme source.
Je viens de mettre à jour en conséquence. Merci pour l’information
1 « J'aime »