Je suis comme toi sous Container.
Core trop embêtant à maintenir la version de python, HA Os fermé et Supervised trop d’interférences sur des logiciels hôtes…c’est pas le sujet.
Sous HA OS, je pense que la documentation ESPHome s’applique.
Ensuite, viens la version Supervised qui en theorie devrait accepter la méthode de la documentation d’ESPHome…
Mais @Pulpy-Luke , partir sur une Supervised et faire un lien symbolique ne me gêne pas vu que c’est une méthode pour les expérimentés.
Mais je m’etonne juste du fait que la documentation ne s’applique pas.
De toute façon, la méthode la plus permissive reste la container comme le mentionne @golfvert dans la façon dd monter les volumes par exemples…
100% en phase sur les choix !
C’est peut-être là différence… Ici : Debian + docker pour faire tourner mon HA Supervisé… Pas HA OS
Mais du point de vue container, que ce soit HA OS, Débian, ubuntu ou autre chose je vois pas bien ce que ça pourrait avoir comme impact… La containerisation c’est justement l’objectif de s’abstraire de la couche logicielle en dessous
ça l’accepte (ça compile etc) mais pour l’expérience utilisateur, c’est bofbof… Obligé de changer d’onglet pour retrouver les entrées de secrets.yaml franchement … Ya la pop-up dédiée pour le faire avec le fichier d’origine
Peut-être mais si ça s’applique uniformement quelque soit la methode d’installation, ça vaut peu-être le coup… Un case à cacher ‹ utiliser le fichier HA › dans l’UI de ESPhome => ça monte lien pour toi ça pourrait être ultra efficace !
Oui, je suis pas partie la dessus à l’origine. Pas que ça coince techniquement, mais j’ai juste pas envie à la maison de faire comme au boulot. J’ai pas eu besoin de trop bidouiller les conteneurs ni été ennuyé par la prise de contrôle du superiveur (VM dédiée HA)