Kolega na razie cały czas walczy z ponownym przywróceniem serwera Home Assistant Operating System (HAOS) do działania, ale coraz śmielej przebąkuje, że chyba pora mnie posłuchać, i przejść na Dockera, czyli Home Assistant Container. Zwłaszcza że zapowiedziałem mu wsparcie w tym procesie. A skoro tak, to pomyślałem, że może warto zrobić z tego artykuł. Tak więc dziś na tapet leci Home Assistant, ESPHome i bonusem tunel od Cloudflare (opcjonalnie), w wersji kontenerowej (Docker).
Spis treści w artykule
Home Assistant, ESPHome i tunel od Cloudflare w kontenerach Dockera
A dokładnie to nawet nie tyle “goły Docker”, co Docker Compose, bo nie tylko wygodniej wg mnie, to jeszcze ew. migracja na nową maszynę, czy choćby przywracanie z kopii zapasowej jest wygodniejsze. Choć może to tylko wrażenie, bo Dockera tak na poziomie choćby średnio zaawansowanym, to cały czas jeszcze mam raczej tylko w planach…
I choć na potrzeby tego artykułu bazuję na Raspberry Pi z systemem Raspberry Pi OS, bazującym na 64-bitowym Debianie (x64), to zasadniczo zawartość plików konfiguracyjnych dla Docker Compose jest uniwersalna. Mogę ewentualnie wystąpić różnice w ścieżkach, ale to nic trudnego do zmodyfikowania, by dopasować do używanego systemu.
Instalacja Docker i Docker Compose
Oczywiście zacząć trzeba od instalacji Dockera, ale tutaj wyjątkowo nie będę podawał konkretnych poleceń, nawet dla konkretnego systemu, a odeślę do dokumentacji, gdzie jest to chyba wystarczająco przystępnie opisane. W każdym razie na koniec instalujemy cały zestaw, czyli dla Debiana będzie to np.:
sudo apt install docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-pluginGdy już Docker zainstalowany, pora przygotować odpowiednie pliki, do uruchomienia Home Assistant, ESPHome i tunelu od Cloudflare (opcjonalnie). A konfigurację kontenerów będziemy zapisywać w plikach “compose.yml”, które należy zapisać… Tutaj jest dość duża dowolność, ale ja proponuję dla Home Assistant umieścić w katalogu:
/opt/docker/homeassistantPlik dla ESPHome w katalogu:
/opt/docker/esphomeA plik dla Cloudflare (opcjonalnie) w katalogu:
/opt/docker/cloudflaredNatomiast jak już napisałem – tutaj panuje dość spora dowolność, więc mogą to być inne katalogi.
I tak dochodzimy do zawartości poszczególnych plików “compose.yml”, a więc dla Home Assistant będzie to:
version: '3'
services:
homeassistant:
container_name: homeassistant
image: "ghcr.io/home-assistant/home-assistant:stable"
volumes:
- /opt/docker/homeassistant/config:/config
- /etc/localtime:/etc/localtime:ro
# Bluetooth:
- /run/dbus:/run/dbus:ro
restart: unless-stopped
privileged: true
network_mode: hostJest to wersja dość standardowa, ale z małym dodatkiem w postaci wsparcia wbudowanego w Raspberry Pi Bluetootha.
Dla ESPHome plik “compose.yml” może wyglądać tak:
version: '3'
services:
esphome:
container_name: esphome
image: esphome/esphome
volumes:
- /opt/docker/esphome/config:/config
- /etc/localtime:/etc/localtime:ro
restart: unless-stopped
privileged: true
network_mode: hostA dla Cloudflare – jeśli korzystamy – tak:
version: "3"
services:
cloudflared:
image: cloudflare/cloudflared
container_name: cloudflare-tunnel
restart: unless-stopped
network_mode: host
command: tunnel run
environment:
- TUNNEL_TOKEN=[TOKEN]Tutaj w miejsce “[TOKEN]” należy wstawić token uzyskany podczas konfigurowania tunelu w Cloudflare. Więcej o tym niebawem…
Następnie z poziomu konsoli (np. SSH) wchodzimy do każdego katalog, np. za pomocą polecenia:
cd /opt/docker/homeassistanti uruchamiamy usługę, za pomocą polecenia:
sudo docker compose up -dW tym momencie nastąpi cała “magia”, czyli pobranie odpowiednich obrazów, oraz ich uruchomienie, wedle zdefiniowanej wcześniej konfiguracji.
Aktualizacja kontenerów
Na deser jeszcze jak takie środowisko aktualizować. Najlepiej za pomocą skryptu, który wchodzi do kolejnych katalogów i uruchamia odpowiednie komendy. Np.:
cd /opt/docker/homeassistant/
sudo docker compose down
sudo docker compose pull
sudo docker compose up -dI właściwie to tyle, przynajmniej jeśli chodzi o podstawową pracę z Dockerem (Docker Compose), nie tylko w kontekście Home Assistant, ESPHome i Cloudflare, bo nie licząc zawartości pliku “compose.yml”, która, chociaż w każdym przypadku dość podobna, to jednak jest specyficzna dla danego oprogramowania, resztą będzie identyczna…
| Lub postaw nam kawę :-)
Pasjonat nowych technologii - od sprzętu po oprogramowanie, od serwerów po smartfony i rozwiązania IoT. Potencjalnie kiepski bloger, bo nie robi zdjęć "talerza" zanim zacznie jeść.
Dumny przyjaciel swoich psów :-)
- Mały dron, duże zamieszanie, czyli seria DJI Mini i zabawa w klasy (unijne klasy dla dronów) z EASA i użytkownikami - 1970-01-01
- Opcja “restore_from_flash”, czyli sposób na zapamiętywanie ustawień w ESPHome na układach ESP8266 - 1970-01-01
- Blokowe szablony powiadomień (block notice) w WooCommerce, nawet w klasycznych motywach - 1970-01-01
Ja mało linuxowy człowiek, czemu w ogóle w drzewie /opt/, a nie naprzykład w /user//??
Też nie jestem aż takim linuksiarzem, bo na stacjonarnym i laptopie mam Windowsa i raczej nie wyobrażam sobie, by było inaczej. Znaczy mam też różne Linuksy, ale jako wirtualne maszyny, lub serwery, ale to już co innego. A czemu opt? Z przyzwyczajenia, że tam lądują “dodatki”. Do tego ja do katalogu “user” daje tylko to, co jest specyficznego dla konkretnego użytkownika. A np. kontenery Dockera traktuję raczej jako coś ogólnosystemowego w większości, niezależnego od konkretnego użytkownika. Ale to dlatego, że nie ma innych użytkowników niż moi. Co innego, gdyby to np. była maszyna typu “hosting współdzielony”.
A kontenerów nie da się nazwać? Tak by nie działać na katalogach, tylko na nazwach kontenerów?
Możesz nazywać. Ale tu katalogi są nie tylko po to, by plik konfiguracyjne Docker Compose (compose.yml) miały “swoje miejsce”, ale też w tych podkatalogach są zapisywane pliki związane z działaniem danej usługi. Np. w Home Assistant jest to m.in. baza danych (przy wersji z bazą w pliku) i masa plików konfiguracyjnych, dodatki (HACK). W przypadku ESPHome są pliki konfiguracyjne poszczególnych urządzeń, biblioteki do kompilacji…
O ile kojarzę HA i sam się do niego przymierzam. To w ogóle nie kojarzę o co chodzi w ESP Home. Kojarzę jakieś tematy typu HA+Red-node, ale nie ESP Home.
ESPHome to oprogramowanie od tej samej firmy co Home Assistant (Nabu Casa), choć chyba pierwotny Twórca inny, i ESPHome powstało sporo później. W skrócie: ESPHome to platforma, która pozwala łatwo tworzyć swego rodzaju oprogramowanie dla układów typu ESP8266, ESP32 (obecnie to już nie tylko), za pomocą języka YAML. Więc dość szybko można przygotować układ z obsługą wielu czujników, który może działać samodzielnie (MQTT, Webserwer, automatyzacje wewnętrzne), lub zostać łatwo zintegrowany z Home Assistant (API), lub innym oprogramowaniem (np. po MQTT). O ile kiedyś większość oprogramowanie dla ESP piałem samodzielnie, korzystając ew. z gotowych bibliotek (Arduino IDE), to od dawna korzystam głównie z ESPHome, i na ESPHome przenoszę kolejne układy (o ile nie są to jakieś “specjalistycznego i nietypowego zastosowania”, gdzie albo własny kod, albo jakieś inne oprogramowanie).
“Home Assistant porzuca HAOS”, czy chodzi o to że Ty (Wy) przechodzicie do dockerów, czy Home Assistant ma plany odejścia od HAOS? Bo jakoś tak dwuznacznie brzmi tytuł. Dzięki!
Bo oprócz tytułów, warto czytać treść… ;-) A już tak bardziej konkretnie (i serio), to nie tyle ja, bo ja od zawsze HA w kontenerach, ale tu chodzi o kolegę (i zabawę formą w tytule ;-)), który po kolejnej awarii HAOS postanowił jednak spróbować wersji w kontenerach Dockera. A tak ogólnie, to raczej mało prawdopodobne, by porzucili HAOS. Jeśli już, to prędzej kiedyś odstrzelą kontenery…
Oczywiście, że przeczytałem. Zresztą to mnie nakłoniło do przetestowania tego pomysłu. Do tej pory miałem wszystko w HAOS na malince 4. Zachciało mi się spróbować w Synology na VM – przeniosłem HA poprzez wbudowany backup i śmigało, co jest o tyle ciekawe że mam moduł XComfortu więc USB (problemy z tty, hid), osobny doker i takie tam. Ale prawie wszystko się przeniosło i śmigało. Po testach wracam do malinki a ona – sru. Padła pamięć ram. Szok! Żadnego wyładowania, zero iskry, czegokolwiek. Chcąc, nie chcąc – wróciłem do Synka. A potem trafiłem na ten artykuł i zacząłem się bawić.
Dzięki przeprowadzce na dokery, sporo się o nich nauczyłem, szczególnie, że właśnie dokupiłem Conbee3 do Z2M więc to kolejny doker i kolejne rozkminy. Mam chyba 90 modułów Xcomfortu i ze 30 różnych zigbee (ikea), ESPHome liczy energię z 3 faz i wszystko musi w domu działać, bo mnie rodzina pogoni. Bawię się kontenerami w Portainerze, Unraidzie i w Synku.
Ale przyznam, że sam już nie wiem… Dużo kombinowania z kontenerami. Więcej trzeba dopilnować IMO. Niby dzięki podpięciu volumenów w Portainerze po CIFS do Synka mam w jednym miejscu załatwione bezpieczeństwo tych danych (raid 5 i dodatkowe backupy) ale jednak widzę pewną przewagę wersji HAOS.
Np. robiły mi się od zawsze pełne cotygodniowe fabryczne backupy automatyczne na zdalnym udziale w Synku (nie ma tego w core), a jak po awarii malinki przerzuciłem się na VM to również migawki codzienne dostępne wg zasad 7 codziennych 4 miesięczne itd. Zresztą, te migawki to chyba najlepsza rzecz żeby się cofnąć do stanu sprzed nieudanego updejtu (czyli coś dla kolegi) Nigdy nie miałem awarii. Najwyżej zdarzało się, że na niektórych wersjach malinka była bardziej podatna na zwiechy.
Nie wiem czy jednak nie wrócę do HAOS… Ale jak już, to raczej tylko do VM, może jakiś N100 kupię i sobie coś na nim dopostawię, np. Plexa z transkodowaniem sprzętowym, żeby dla telewizorów fullhd z gorszym softem nie robić osobnych filmów rodzinnych zmontowanych oryginalnie w UHD :-) Gdyby tylko nie ta nowa era liczenia watów, to by człowiek poszalał.
Na pewno zaletą HAOS jest to, że to ich jakby oczko w głowie, bo mają tu pełną kontrolę. Ja wybrałem kontener, bo na malince mam też inne usługi. Do tego uznałem, że przy kontenerze, w razie usterki, łatwiej będzie mi odzyskać środowisko – kilka plików i katalogów, “docker-compose up” i działamy dalej. Natomiast oczywiście trzeba sie liczyć z tym, że czasem po prostu lepiej zainstalować HAOS.
A z ciekawości – jak ESPHome liczysz energię? Miganie diody licznika, czy jakimś modułem? Ja miganie diody, bo na moduł miejsca brak w skrzynce. Ale ku mojemu zaskoczeniu, od dawna sprawdza się to dość dobrze. Wartości, jakie podaje, wydają się sensowne, a przeprowadzany od czasu do czasu test (spisanie stanu licznika i porównanie po kilku dniach) też się zgadzają…
Stan czytam na niebieskim Wemosie który siedzi w srzynce w wydrukowanym pudełku tuż obok dokupionego licznika 3-fazowego, który ma po prostu wyprowadzony impuls. Czyli u mnie kabelkiem. Działa stabilnie i rzeczywiście precyzyjnie. Przesyłam aktualny pobór dzienny (dla czystej ciekawości), który zeruje się w Wemosie o północy i chwilowy z którego liczona jest energia z pomocą sumy Riemanna i dostarcza danych do głównego modułu energii HA.
No to ja podobnie, tyle że NodeMCU, a impulsy liczę prosto z licznika (LM393). Dalej do statystyk i energii dane lecą. No i jakieś pomocnicze liczniki, w tym aktualne obciążenie (W). Do tego ogarnia dzwonek do drzwi i odczyt licznika wody (radiowy). Choć myślę o zmianie na ESP32, bo ESP8266, jeśli chodzi o GPIO to już w tej konfiguracji musiałem trochę kombinować – sam CC1101 (odczyt licznika wody) to 6 GPIO.