Konfiguracja HA wraz ze wzrostem liczby urzadzeń i automatyzacji w pewnym momencie staje się mało czytelna, rozwiązaniem tego jest uzupełnienie konfiguracji o tzw. package. Najprościej to opisać jako zbiór osobnych plików konfiguracyjnych HA, które razem tworzą całość. Każdy plik musi spełniać zasady konfiguracji pliku configuration.yaml.
Mój plik konfiguracyjny configuration.yaml po zakończeniu migracji na package (bo to chciałem osiągnąć) zawiera tylko to:
homeassistant:
# In the packages directory you can store any number of packages in a YAML file but not subfolders (use: packages: !include_dir_merge_named packages/)
packages: !include_dir_named packages
# List of folders that can be used as sources for sending files.
allowlist_external_dirs:
- /config
# Configure a default setup of Home Assistant (frontend, api, etc)
default_config:
# Text to speech
tts:
- platform: google_translate
# -- start default config
group: !include groups.yaml
automation: !include automations.yaml
script: !include scripts.yaml
scene: !include scenes.yaml
# -- stop default config
# https://www.home-assistant.io/integrations/time_date/
sensor:
- platform: time_date
display_options:
- 'date'
- 'time'
- 'date_time'
- 'date_time_utc'
- 'date_time_iso'
- 'time_utc'
python_script:
# https://www.home-assistant.io/integrations/logger/
logger:
default: info
reszta jest w osobnych plikach yaml w katalogu \config\packages\. Jak widać nadal korzystam z plików groups.yaml, automations.yaml.
W ten sposób każdy nowy pomysł w HA realizuje od stworzenia nowego pliku z testową konfiguracją np. printer_test.yaml, dopiero po testach i akceptacji rozwiązania zmieniam nazwę pliku na printer.yaml. W przypadku problemów lub porzucenia tematu usuwam plik testowy, w prosty sposobów usuwam wszystkie testowe zmiany w HA.
Jeden z wielu przykładów takiego podejścia do konfiguracji HA:
Gorąco polecam skorzystanie z takiej konfiguracji Home Assistanta.
Rozwiązanie z użyciem packages jest moim zdaniem nie do przebicia. Szczególnie gdy masz rozbudowaną konfigurację, korzystasz często z templates i tym podobne. Dodając cokolwiek nowego do HA tworzysz po prostu kolejny plik yaml nadając mu charakterystyczną nazwę i w nim zawierasz wszystko co nowego dotyczy. Niezwykle łatwo się w tym wszystkim jest później odnaleźć i w razie potrzeby dokonywać zmian.
Wolę wszystko co dotyczy np. pralki np. input_select, sensor, utility_meter, automation, notify umieścić w jednym pliku pralka.yaml niż “skakać” między kilkoma plikami. Dokonując zmian, robię to w jednym pliku, jak coś nie działa przywracam z kopii tylko jeden plik. Nic i nikt nie przekona mnie do innej konfiguracji HA .
Odkopię ten temat, bo w końcu zabieram się do porządków z konfiguracji po latach mnożenia spontanicznych wpisów. A zapewne jest spora liczba nowych użytkowników, dla których będzie to nowa wiedza.
Chcę dobrze zrozumieć mechanizm i po lekturze dokumentacji HA w tym zakresie widzę, że jest kilka metodologii na wprowadzenie pakietów. @macek - możesz przedstawić jak masz zagnieżdżony wpis odsyłający w głównym pliku konfiguracji HA i dalej ścieżkę dla tej przykładowej pralki. Jak wygląda wówczas układ katalogów?
Podoba mi się bardzo pomył robienia pliku yaml dla danego urządzenia (może też dla pomieszczenia ). Mam część encji tworzonych z mqtt i trochę własnych wpisów pod customize.yaml (jeden plik dostosowujący różne encje, róznych urządzeń). Rozumiem, że w takim pliku pralka.yaml mógłbym zamieścić również zapisy dla dostosowania encji dotyczących np. pralki, które obecnie mam w tym customize.yaml?
OK, to rozumiem. Tylko chciałbym zrozumieć jak zapisywać ścieżkę do tego pliku. Pokazujecie własny układ katalogów ale ja tego nie widzę.
Widzę ścieżkę na grafice od Ciebie /usr/share/hassio/hameassistant/packages/
i w tej lokalizacji na grafice masz pojedyncze pliku yaml, jest też folder z devices, to w nim masz plik dla np. Telefon App Package?
Chodzi mi o zrozumienie tego mapowania, tak aby nie świadomie utworzyć to drzewo.
.
). Mam część encji tworzonych z 
