Merci pour le partage 
Beau boulot
Bonsoir,
Je me permet de réouvrir ce topic, excusez-moi par avance s’il était plus judicieux d’en ouvrir un nouveau.
Ma configuration actuelle fait déjà appel au split de la configuration en me basant sur ceci:
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
sensor: !include sensor.yaml
binary_sensor: !include binary_sensor.yaml
mais ces derniers temps faisant de plus en plus d’intégration je souhaite je pense qu’il serait judicieux de passer à un méthode ou j’ai un fichier dédier par élément ou intégration mais j’ai quelques intérrogations qui m’empèchent de sauter le pas.
Vaut-il mieux de partir sur la base du packages :
homeassistant:
packages: !include_dir_named packages
ou
homeassistant:
packages: !include_dir_merge_named packages/
ou alors continuer avec mon modèle actuel indiqué plus haut, mais qui je pense va s’avérer compliqué à gérer sur le long terme au fur et à mésure que je viendrais ajouter des nouvelles choses?
J’avoue être un peu perdu avec tout ça et aussi avec la gestion des intégrations que ce soit via HACS ou directement depuis HA; comment sont-elles ou doivent-elles être gérés si on fait le choix d’utiliser packages?
Peut-être que je suis en train de me faire des noeuds au cerveau pour rien mais j’aimerais simplifier la gestion de HA un maximum en sachant quel fichier aller voir directement et non pas aller trifouiller de centaines ou des milliers de lignes de code.
Merci d’avance pour votre aide
Al
Salut.
La question se pose effectivement. Et je pense que la réponse est assez propre à chaque personne… Et à sa manière de mentaliser ha
La structuration par types à l’avantage d’être rapide d’accès. Tu connais le type de l’entité, le fichier est unique. Par ailleurs le nom reprenant le plus souvent le type, il est facile à repérer.
La vue par package est une vue logique dans le sens où tous les éléments qui sont directement en relation sont regroupés. Tu as un problème sur la gestion des volets, zou direct en édition et tout est sous la main.
Cependant je trouve que le deuxième classement à des limites. La relation pour mettre dans tel ou tel package se définit comment ? Volet par exemple, on le mets dans le package nuit, mais s’il est aussi utilisé pour empêcher les reflets sur la télévision, pourquoi pas dans le package télé alors ?
Et comment on nomme ce package justement ? Un nom court facile à lire et à trouver mais qui du coup n’est pas précis ? Ou alors une description à rallonge pour être très restrictif et multiplier les découpages ?
A partir de quand on remet en cause le groupement ? Je suis parti au début sur un package par pièce, le salon était facile car ça faisait que la gestion de la télé, mais désormais il y a l’éclairage d’ambiance, la sono, le chauffage, l’écran google avec la météo. Ça fait vite un fichier fourre tout.
Et comme de mon côté, j’utilise un éditeur multi onglets avec fonctions de recherche (vstudio) c’est pas vraiment compliqué de basculer du fichier sensor à binary_sensor…
Pas sur que ça aide vraiment mais ça peu te faire réfléchir à la façon dont tu conceptualises tout ça
Salut Pulpy,
Merci pour ce retour, en effet j’ai en effet un peu du mal à conceptualiser tout ça, je vais continuer à creuser le sujet jusqu’à ce que je sois prêt à sauter le pas même si cela m’oblige à mettre en standby un certain nombre d’intégration jusqu’à nouvel ordre; ce que je cherche avant tout est simplifier pour retrouver plus facilement ce que je chercher tout en pouvant ajouter des nouvelles intégrations « sans trop des contriantes »
Salut,
Il est aussi possible de cumuler les deux et prendre l’avantage de chaque organisation.
Un input seul ira dans lenfuchier input et un mode complet ira dans un package ( exemple notification telegram )
Personnellement, si je fais un Mix des deux je ne donne pas cher de ma santé mentale. S’il faut se souvenir de où c’est ranger avant, ça marche quand c’est tout frais mais après quelques mois et plusieurs évolutions j’aurais forcément oublié la logique du moment
1 « J'aime »
Je suis un peu comme toi mais dans ce cas, est-ce que le fait de mettre un commentaire dans ton fichier devrait justement palier à ce problème,non?
Oui et non.
Si le commentaire est dans le fichier final, ça sert à rien. S’il faut lire un roman en amont (et les mettre à jour !), on y passe vite plus de temps qu’à chercher.
Comme dirait l’autre le fils rouge sur le bouton rouge, le fil vert sur le bouton… Vert !
Quand j’ai une erreur, j’ai le nom de l’entité, l’entité est typée et c’est directement.
Je mets des séparations et des commentaires pour rendre les gros fichiers plus visuels et j’essaye d’avoir une logique de nommage de mes entités (genre climate.radiateur_salon ou cover.velux_salledebain)
Deux petites interpellations à la lecture du sujet.
- Qu’est ce qui est prévilégié, la packaging ou le splitting ? Les deux semblent assez proches. Il permettent d’exploser un fichier en morceaux plus pratique à la maintenance.
- Est ce que dans le splitting, il y a un ordre à respecter dans les noms de fichiers ? J’ai lu que HA allait les lire les 1 à la suite des autres. Mais si par exemple, la config du modbus se situe dans le fichier 5, il aura parcourut 4 fichiers avant, ce qui ne correspond pas à un ordre de lecture qu’il aurait eu dans le fichier config.
Tout dépend de l’utilisation et de l’organisation de chacun.
Le split permet de mettre un input par-ci par là alors que le packaging permet de mettre tout une « gestion » présence, alarme etc, mais certaine peuvent être aussi utilisée par d’autres donc pas évident.
Je n’en sais rien il faut attendre d’autres réponses.
L’ordre de lecture n’a pas d’importance dans ce contexte. Par exemple peu importe l’organisation, on arrive bien à déclarer un binary qui se base sur un sensor et un sensor qui se base sur un binary sans pour autant devoir gérer à la fin le sens de lecture.
Là où ça a un impact c’est si on déclare 2 fois la même chose par exemple binary.toto dans un split puis binary.toto dans un fichier binary… La config du 1er binary sera écrasé par le 2ème (dans l’ordre d’inclusion/lecture)
Et pour moi, le risque de doublon est à mon avis plus important quand on fait du split que du fichier par type… Sans compter qu’au sein d’un même fichier VSStudio sait voir le doublon, mais pas dans 2 fichiers différents
1 « J'aime »
Salut !
J’ai lu avec attention le post, j’ai commencé à diviser ma config pour améliorer l’organisation et, donc, la maintenance.
En revanche j’ai besoin de vos lumières pour obtenir quelque chose de pertinent eu égard à mes petites connaissances et à ce que je pourrais faire plus tard mais dont je ne suis pas encore au courant 
(C’est à dire : Privilégié une organisation car si, aujourd’hui, cela me semble bizarre, demain j’aurai la clé pour comprendre !).
Et donc aujourd’hui, j’ai utilisé les petits…
sensor: !include_dir_merge_list sensors/
binary_sensor: !include_dir_merge_list binary_sensors/
A savoir que je récupère tout de MQTT et que je pense qu’il y a largement mieux à faire…
Mon capteur fenetre_open_cuisine ressemble à ça :
{
"battery": 100,
"battery_low": false,
"contact": true,
"linkquality": 39,
"tamper": false
}
Avec dans HA :
- platform: mqtt
object_id: "fenetre_open_cuisine_contact"
name: "Cuisine - Fenêtre"
device_class: window
icon: mdi:window-closed-variant
payload_on: false
payload_off: true
availability_topic: "zigbee2mqtt/bridge/state"
value_template: "{{value_json.contact}}"
state_topic: "zigbee2mqtt/fenetre_open_cuisine"
Sauf que je souhaite suivre, pour chacun de mes capteurs, le contact (logiquement…), le niveau de batterie et la qualité de signal… et aujourd’hui j’ai le contact via un binary_sensors/ et d’autres via sensors/... Je ne comprends pas comment organiser ça ? Je pense que, quelque soit l’info, je dois pouvoir faire des templates perso mais je souhaite tout de même avoir les logos, les couleurs etc…
Une idée de ce que je dois lire ? genre un truc template: ? qui rassemble tous mes sensors via mqtt ? (un fichier yaml par ligne mqtt ?
Merci !
Vincent
Salut
Pour un même appareil, séparer ses entités ça me semble pas plus simple à gérer.
Dans un cas comme ça, puisque platform mqtt c’est un sous ensemble de sensor, ça fini dans sensor
Mon problème c’est que je n’obtiens plus de binary_sensor (logique) et donc je n’ai plus les ouvert / fermé simplement (mais true et false…).
Comment vous faites, vous, avec vos capteurs de porte en mqtt ?
Au fond de moi j’espère qu’il existe un truc genre
- platform: mqtt
name: "Cuisine Test"
object_id: "cuisine_test"
state_topic: "zigbee2mqtt/fenetre_open_cuisine"
value_template:
- contact = if value_json["contact"] = true: 'Fermé' else 'ouvert'
- battery = '{{ value_json["battery"] }}'
unit_of_measurement: "%"
- linkquality = '{{ value_json["linkquality"] }}'
unit_of_measurement: "LQI"
Récupérable dans une entité genre cuisine_test.battery 
Ce qui permettait de n’avoir que quelques lignes par entité, et donc simplifier le système
@McFly Le lien vers l’article sur l’intégration du matériel xiaomi du premier message ne fonctionne pas
1 « J'aime »
Pour un ouvrant personnellement je construirai un cover, pour profiter des fonctions
Ca marche pour des ouvrants électriques. Moi, ici, ce ne sont que des capteurs d’ouvertures de portes et fenêtres (je n’ai pas ce soucis pour les thermomètres puisque les 3 infos que je souhaite suivre sont toutes 3 des sensors).
Merci pour le signalement c’est changé
Passe directement à la méthode package :
sur le même principe que ce post :
cela donnerais :
#fichier config/packages/cuisine/mqtt_fenetre.yaml
sensor:
- platform: mqtt
object_id: "fenetre_open_cuisine_contact"
name: "Cuisine - Fenêtre"
device_class: window
icon: mdi:window-closed-variant
payload_on: false
payload_off: true
availability_topic: "zigbee2mqtt/bridge/state"
value_template: "{{value_json.contact}}"
state_topic: "zigbee2mqtt/fenetre_open_cuisine"
binary_sensor:
- platform: mqtt
state_topic: "home-assistant/window/contact/cuisine"
et par exemple :
#fichier config/packages/salon/mqtt_fenetre.yaml
sensor:
- platform: mqtt
object_id: "fenetre_open_salon_contact"
name: "Salon - Fenêtre"
device_class: window
icon: mdi:window-closed-variant
payload_on: false
payload_off: true
availability_topic: "zigbee2mqtt/bridge/state"
value_template: "{{value_json.contact}}"
state_topic: "zigbee2mqtt/fenetre_open_salon"
binary_sensor:
- platform: mqtt
state_topic: "home-assistant/window/contact/salon"
Bref : comme dit un peu partout :
Elle permet de tout mélanger de façon à tout ranger… (j’adore cette phrase… lol)
J’ai fait ça ce soir 
La méthode package est exactement ce qu’il me fallait!
Le seul truc dingue serait de pouvoir donner un dossier au lieu d’un fichier yaml 
ça obligé à créer un package par fichier.
Exemple dans config.yaml.
# Salon
salon_fenetre_droite: !include packages/maison_rdc/salon/fenetre_droite_open.yaml
salon_fenetre_gauche: !include packages/maison_rdc/salon/fenetre_gauche_open.yaml
salon_thermometre: !include packages/maison_rdc/salon/thermometre.yaml
S’eut été cool de pouvoir faire un truc genre
salon : !include_dir packages/maison_rdc/salon
Ça éviterai 1 package par capteur. Mais j’en demande trop (sensor et binary_sensor apparaissant dans chaque fichier).
Merci pour le message 