@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
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
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:
Compte utilisateur communautaire
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
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.
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.