Home Assistant na serwerze domowym: praktyczny poradnik instalacji na Proxmox i Docker krok po kroku

Dlaczego Home Assistant na serwerze domowym ma sens

Centralny mózg automatyki zamiast dziesięciu aplikacji

Home Assistant to centralna platforma do sterowania sprzętem smart home, automatyzacją i zbieraniem danych z domu. Łączy żarówki, czujniki, rolety, ogrzewanie, kamery i sprzęt AV w jednym miejscu, zamiast skakać po aplikacjach producentów.

Na serwerze domowym homelab Home Assistant staje się usługą działającą 24/7, z mocą obliczeniową i zasobami nieporównywalnymi z budżetową bramką producenta. Daje to szybkie reakcje automatyzacji, więcej integracji i możliwość logowania praktycznie wszystkiego.

W praktyce oznacza to prostsze scenariusze: światła, rolety, ogrzewanie, multimedia i monitoring spięte w jeden interfejs, bez zależności od aplikacji chmurowych i zmian w polityce producenta.

Różnice między serwerem domowym a gotowymi bramkami

Gotowe bramki (Tuya, IKEA, Xiaomi, Sonoff, Philips Hue) są wygodne na start, ale z czasem zaczynają ograniczać. To zamknięte ekosystemy, które mają własne sceny i automatyzacje, ale słabo współpracują między sobą.

Home Assistant na serwerze domowym działa jak „tłumacz” i „dyrygent” dla wszystkich tych światów. Łączy Wi‑Fi, Zigbee, Z‑Wave, BLE, urządzenia chmurowe i lokalne. Większość reguł można zbudować lokalnie, bez wysyłania danych do chmury.

Różnica kluczowa: w gotowych bramkach jesteś ograniczony do tego, co przewidział producent. Na własnym serwerze z Home Assistantem granicą są głównie czas i umiejętności.

Scenariusze: blok, dom jednorodzinny, wynajem

W mieszkaniu w bloku Home Assistant często zaczyna od oświetlenia, kilku gniazdek i sterowania RTV. Typowy zestaw to kilkanaście urządzeń Wi‑Fi, jeden dongle Zigbee i kilka prostych automatyzacji typu „światło w korytarzu po zmroku przy ruchu”.

W domu jednorodzinnym dochodzą: ogrzewanie, klimatyzacja, bramy, rolety, nawadnianie, monitoring, często także fotowoltaika i pompa ciepła. Serwer domowy z Proxmox VE konfiguracja staje się tu atrakcyjny, bo na tej samej maszynie można utrzymywać także serwery multimediów, backupy czy lab testowy.

W wynajmowanym lokum nacisk zwykle idzie na to, by sprzęt dało się łatwo zdemontować: żarówki, czujniki na baterie, gniazdka, listwy LED. Home Assistant działa wtedy głównie jako warstwa logiki i wygodnego sterowania, a nie jako centrum infrastruktury.

Korzyści: niezależność, szybkość, automatyzacje „pod siebie”

Największa zaleta: niezależność od chmury. Home Assistant może sterować większością urządzeń lokalnie. Gdy internet padnie, światło, ogrzewanie i sceny czasowe nadal działają.

Druga rzecz to szybkość. Automatyzacje uruchamiane lokalnie na mocniejszym CPU reagują natychmiast, bez opóźnień, które potrafią pojawiać się przy rozwiązaniach chmurowych. Widać to szczególnie przy czujnikach ruchu i światłach.

Trzeci element to pełna kontrola nad logiką. Można definiować warunki zależne od pogody, taryf prądu, stanu baterii, ruchu w określonych strefach czy obecności domowników wykrywanej po Wi‑Fi lub GPS.

Konsekwencje: odpowiedzialność za utrzymanie

Własny serwer z Home Assistantem oznacza też odpowiedzialność za kopie zapasowe, aktualizacje i bezpieczeństwo. To nie jest „włącz i zapomnij” jak fabryczna bramka.

Trzeba pilnować miejsca na dysku, robić backup i snapshoty Home Assistant przed większymi zmianami, rozsądnie aktualizować dodatki i integracje. W zamian zyskuje się pełną kontrolę nad środowiskiem.

Przy sensownie ustawionym Proxmoxie – z porządnym storage i prostym schematem backupu – utrzymanie tego zestawu nie jest dużo trudniejsze niż aktualizowanie zwykłego komputera.

Sprzęt i sieć – co naprawdę musi unieść Proxmox i Home Assistant

CPU, RAM, dyski – realne wymagania

Home Assistant sam w sobie nie jest bardzo wymagający. Działa płynnie na 2 rdzeniach CPU i 2–4 GB RAM w większości domowych scenariuszy. Prawdziwe obciążenie pojawia się, gdy na tym samym serwerze działa więcej maszyn wirtualnych i kontenerów.

Jeśli serwer domowy ma jednocześnie obsługiwać Home Assistant, kilka lekkich VM (np. router wirtualny, mały serwer plików, monitoring) i parę kontenerów Dockera, rozsądne minimum to 4 rdzenie/8 wątków i 16 GB RAM. Daje to komfort, by nie pilnować co chwilę użycia pamięci.

Dysk: dla HA i Proxmoxa warto użyć SSD NVMe zamiast HDD. Przy wirtualizacji i wielu małych operacjach zapisu różnica w responsywności jest ogromna. Dobrze sprawdza się konfiguracja: mały SSD na system (Proxmox) i większy SSD na dane VM/LXC.

Przykładowe konfiguracje serwera domowego

W praktyce używa się czterech głównych typów sprzętu:

• miniPC / „chiński NUC” z CPU typu Intel i5/i7 niskonapięciowy, 16–32 GB RAM, SSD NVMe,
• oryginalny Intel/AMD NUC – cichy, mały, energooszczędny, idealny do salonu,
• stary desktop z wymienionym zasilaczem i SSD – tania opcja na start, zwykle głośniejsza i prądożerna,
• NAS (Synology/QNAP) – gdy ma wsparcie dla wirtualizacji, ale zwykle z gorszym CPU.

MiniPC i NUC to najczęstszy wybór: małe wymiary, rozsądne zużycie energii, przyzwoita moc. Stary desktop opłaca się, gdy już stoi w szafie, ale przy pracy 24/7 rachunek za prąd szybko pokazuje różnice.

Sieć domowa: router, VLANy, kabel czy Wi‑Fi

Pod Home Assistant i Proxmox przydaje się stabilna, przewodowa sieć. Serwer powinien być podłączony kablem Ethernet do głównego routera lub przełącznika. Wi‑Fi jako uplink serwera to gotowy przepis na losowe problemy.

Przy większej liczbie urządzeń IoT dobrym pomysłem są osobne VLANy lub przynajmniej osobna sieć Wi‑Fi dla sprzętów smart. Ułatwia to odseparowanie ich od sieci roboczej i lepszą kontrolę ruchu.

Z punktu widzenia Home Assistanta ważne jest, aby mógł się bez problemu komunikować z urządzeniami po lokalnym IP, a ewentualne reguły firewall nie blokowały odkrywania urządzeń typu mDNS, SSDP czy integracji po HTTP/MQTT.

Lokalizacja serwera, hałas i zasilanie awaryjne

Serwer domowy najlepiej ustawić tam, gdzie nie będzie przeszkadzać wentylatorami: garderoba, schowek, szafa telekomunikacyjna, piwnica. W przypadku NUC‑ów i miniPC problem hałasu zwykle jest mniejszy.

Jeśli Home Assistant ma odpowiadać za bezpieczeństwo (alarm, czujniki, bramy), serwer powinien być podpięty do UPS‑a. Nawet tani zasilacz awaryjny pozwoli przetrzymać krótkie zaniki zasilania i bezpiecznie wyłączyć maszyny przy dłuższych przerwach.

Warto też fizycznie rozdzielić zasilanie routera i serwera, tak by jedno zwarcie nie wyłączyło całej infrastruktury domu.

Typowe pułapki sprzętowe

Najczęstsze błędy przy budowie serwera domowego pod Home Assistant i Proxmox VE:

Przy wyborze warto zerknąć też na świat Informatyka, Nowe technologie, AI, bo często tam pojawiają się testy sprzętu pod kątem wirtualizacji i homelabów.

• uruchamianie Proxmoxa z dysku USB jako głównego storage – psuje się, jest wolne, sprawia kłopoty przy większej liczbie VM,
• za mało RAM (np. 4–8 GB na cały serwer) – wszystko zaczyna swapować, VM się przywieszają,
• serwer podłączony do routera przez Wi‑Fi – losowe utraty połączeń z HA, problemy z integracjami,
• przegrzewający się miniPC w szafce bez wentylacji – throttling CPU, niestabilność systemu.

Rozsądnie jest od razu założyć, że oprócz Home Assistanta pojawią się inne projekty i zostawić sobie zapas: RAM, dysk i porty sieciowe.

Proxmox VE – hipernadzorca jako fundament serwera domowego

Dlaczego Proxmox ułatwia życie z Home Assistantem

Proxmox VE daje to, czego brakuje gołemu systemowi: wygodne snapshoty, prosty backup całych maszyn i elastyczność w przydzielaniu zasobów. Home Assistant staje się wtedy jedną z usług, którą można odtworzyć z kopii jednym kliknięciem.

Snapshot VM z Home Assistantem przed większą aktualizacją to dosłownie kilka sekund. Gdy coś pójdzie nie tak, powrót do działającego stanu to jedna operacja w GUI Proxmoxa.

W homelabie Proxmox pozwala na łatwe testowanie różnych wersji systemów: obok produkcyjnego HA można mieć kopię testową albo osobną VM z Dockera dla eksperymentów.

Szybka instalacja Proxmox VE na gołym metalu

Proces instalacji Proxmoxa wygląda zwykle tak:

• pobranie ISO Proxmox VE ze strony producenta i przygotowanie bootowalnego pendrive,
• ustawienie w BIOS/UEFI bootowania z USB, włączenie wirtualizacji sprzętowej (Intel VT‑x/AMD‑V),
• jeśli są dwa dyski i chcemy prostą redundancję – konfiguracja RAID1 z poziomu instalatora,
• wybór dysku na system, ustawienie hasła root i adresu sieciowego,
• restart i dostęp do panelu przez przeglądarkę.

Na starcie wystarczy pojedynczy dysk i pojedynczy bridge sieciowy (vmbr0). Resztę można dostosować później, gdy pojawi się potrzeba.

Pierwsza konfiguracja po instalacji

Po instalacji Proxmoxa warto od razu:

• ustawić statyczny adres IP serwera (w instalatorze lub jako rezerwację DHCP w routerze),
• zalogować się przez przeglądarkę pod adresem https://IP‑serwera:8006,
• zaktualizować repozytoria (ustawiając wersję bez subskrypcji lub z subskrypcją – w zależności od scenariusza),
• wykonać pierwszą aktualizację systemu z poziomu GUI lub SSH.

Stały adres IP Proxmoxa jest kluczowy, bo na nim opiera się cała administracja serwerem. Raz ustawiony nie powinien się zmieniać, tak samo jak IP Home Assistanta w środku.

Podstawowe pojęcia: VM, LXC, storage, vmbr0

Proxmox rozróżnia dwa typy maszyn: klasyczne VM (wirtualne maszyny pełnego systemu) i kontenery LXC (lżejsze, współdzielące kernel hosta). Home Assistant najczęściej ląduje w VM (HA OS) lub w kontenerze/VM z Debianem i Dockerem.

Storage to definicje przestrzeni dyskowej: lokalny dysk, ZFS, NFS z NAS, itp. Warto ustalić jedno miejsce na dyski VM i jedno na kopie zapasowe, by później się nie gubić.

Bridge sieciowy vmbr0 działa jak wirtualny switch. Do niego podłączone są wszystkie VM i kontenery, dzięki czemu maszyny dostają adresy z domowej sieci, jakby były fizycznymi komputerami.

Bezpieczeństwo na start: hasło root, 2FA, aktualizacje

Najważniejsze kroki po instalacji Proxmoxa pod kątem bezpieczeństwa:

• mocne, unikalne hasło dla konta root, przechowywane w menedżerze haseł,
• włączenie 2FA dla logowania do GUI (TOTP w telefonie),
• ograniczenie dostępu do portu 8006 tylko z sieci LAN lub określonych adresów,
• regularne aktualizacje Proxmoxa (np. raz w miesiącu lub przy większych zmianach).

Dobrą praktyką jest też posiadanie drugiego konta administracyjnego i ewentualne odcięcie logowania roota przez SSH, jeśli jest włączone.

Trzy drogi do Home Assistanta: OS, Supervised, Container

Home Assistant OS, Supervised i Container/Core – czym się różnią

Home Assistant występuje w trzech głównych wariantach instalacji:

• Home Assistant OS – kompletny system operacyjny z HA, dodatkami (Add‑ons), łatwymi aktualizacjami i pełnym „ekosystemem” HA,
• Home Assistant Supervised – HA z supervisor’em na Debianie, zapewniający Add‑ons, ale wymagający bardziej restrykcyjnego środowiska,
• Home Assistant Container/Core – sam rdzeń Home Assistanta uruchamiany w kontenerze Docker, bez supervisor’a i dodatków.

W codziennym użyciu różnica kluczowa to obecność supervisor’a i dodatków. HA OS i Supervised mają wbudowany sklepik z Add‑ons, Container/Core tego nie oferuje.

Co daje i co odbiera wariant kontenerowy

Home Assistant w kontenerze Docker (Container/Core) jest elastyczny i prosty do zarządzania standardowymi narzędziami Dockera. Można łatwo przenosić konfigurację, aktualizować kontener, budować własne otoczenie (np. osobny broker MQTT, osobne bazy).

W zamian traci się supervisor’a i Add‑ons. Integracje takie jak Zigbee2MQTT, Node‑RED czy ESPHome trzeba uruchamiać w osobnych kontenerach i łączyć ręcznie siecią oraz volumenami.

Dla osób, które dobrze czują się w Dockerze, Home Assistant w Docker Compose bywa wygodniejszy niż HA OS, bo cały stos da się opisać w jednym pliku YAML i wersjonować w Git.

Który wariant najlepiej pasuje na Proxmoxa

Dobór wariantu do scenariusza domowego

Dla większości zastosowań domowych najprostszym wyborem na Proxmoxie jest Home Assistant OS w VM. Dostaje się pełen ekosystem, dodatki i bezproblemowe aktualizacje, a Proxmox zapewnia snapshoty i backup.

Wariant Supervised na Debianie ma sens, gdy na tej samej maszynie chcemy inne usługi linuksowe poza HA, ale dalej zależy nam na Add‑ons. Trzeba jednak pilnować zgodności z zaleceniami projektu HA.

Container/Core to opcja dla tych, którzy chcą mieć pełną kontrolę nad każdym kontenerem i siecią Dockera. Wymaga więcej pracy, ale daje większą elastyczność przy rozbudowanych homelabach.

Plusy i minusy pod kątem Proxmoxa

Home Assistant OS jako pojedyncza VM jest łatwy do opanowania. Backup to jedna kopia pliku dysku, a migracja na inny host Proxmoxa trwa tyle, co przeniesienie VM.

Supervised dziedziczy zalety pełnego Debiana – łatwiejszy dostęp do narzędzi systemowych, ale też więcej rzeczy może się „rozjechać” po latach aktualizacji i ręcznych modyfikacji.

Container/Core najlepiej czuje się w scenariuszu, w którym Debian (lub inny Linux) działa w VM, a na nim cała orkiestracja Dockera. Wtedy Proxmox „widzi” tylko jedną VM, a wewnątrz można żonglować kontenerami bez dotykania hipernadzorcy.

Instalacja Home Assistant jako maszyna wirtualna na Proxmox VE

Przygotowanie obrazu Home Assistant OS

Najpierw trzeba pobrać obrazy dla VM ze strony projektu Home Assistant. W sekcji instalacji dla wirtualizacji dostępny jest obraz qcow2 lub vmdk przeznaczony dla KVM.

Na Proxmoxie najwygodniej przesłać obraz na serwer (np. przez SCP lub z poziomu GUI) i umieścić go w storage typu local lub local-lvm, w sekcji „ISO Image” lub „Disk image” zależnie od sposobu importu.

Tworzenie nowej maszyny wirtualnej

Proces tworzenia VM na Proxmoxie dla Home Assistant OS wygląda w uproszczeniu tak:

• kliknięcie „Create VM” w GUI Proxmoxa, nadanie numeru ID i nazwy (np. ha-os),
• w zakładce „OS” wybranie opcji „Do not use any media” (obraz podłączymy później),
• w zakładce „System” ustawienie BIOS na OVMF (UEFI) oraz włączenie Qemu Agent w późniejszej konfiguracji,
• dla dysku – utworzenie tymczasowego dysku lub całkowite jego pominięcie, jeśli planujemy import istniejącego obrazu,
• CPU – przydzielenie 2 vCPU na start,
• RAM – 4–6 GB jako punkt wyjścia dla małej instalacji,
• Sieć – zwykle model virtio, podłączony do vmbr0.

Po utworzeniu VM można ją jeszcze dostosować przed pierwszym uruchomieniem, podmieniając dysk na właściwy obraz HA OS.

Import obrazu dysku Home Assistant OS

Obraz qcow2 lub vmdk trzeba zamienić na dysk VM. W praktyce robi się to raz i później jedynie aktualizuje HA z poziomu interfejsu webowego.

Typowy schemat importu w konsoli Proxmoxa:

• przesłanie pliku obrazu do katalogu /var/lib/vz/template/iso lub innego storage,
• użycie komendy qm importdisk <VMID> <plik> <storage>,
• wejście w ustawienia VM i podpięcie nowo utworzonego dysku jako głównego (SATA/virtio).

Po tej operacji pierwotny „pusty” dysk można usunąć, zostawiając tylko dysk z Home Assistant OS.

Ustawienia CPU, RAM i dysku dla stabilnej pracy

Dla domu wystarcza konfiguracja:

• CPU: 2–4 vCPU, typ host dla lepszej wydajności,
• RAM: 4 GB dla małych instalacji, 8 GB przy większej liczbie integracji i dodatków,
• Dysk: 32–64 GB SSD na start, najlepiej storage z dobrym IOPS.

Parametr „Ballooning” RAM można włączyć, ale w małych homelabach czytelniej jest przydzielić na sztywno zapas pamięci i obserwować użycie z poziomu Proxmoxa.

Konfiguracja sieci VM z Home Assistant OS

Standardowo VM z Home Assistantem podłącza się do tego samego bridge’a, co resztę maszyn, czyli vmbr0. Dzięki temu HA dostaje adres z domowego DHCP i jest widoczny jak każde inne urządzenie.

Adres IP najlepiej „przytrzymać” rezerwacją DHCP w routerze, przypisując go do MAC karty sieciowej VM. Pozwala to uniknąć zmian IP i problemów z dostępem do panelu HA.

Przy instalacjach, gdzie Home Assistant ma działać jako element sieci VLAN, można podpiąć drugą kartę sieciową VM do innego bridge’a powiązanego z konkretnym VLANem.

Pierwsze uruchomienie i inicjalna konfiguracja VM

Po starcie VM Home Assistant OS przez kilka minut kończy instalację i aktualizuje się do najnowszej wersji. Można obserwować log konsoli w Proxmoxie lub po prostu poczekać.

Panel HA jest zwykle dostępny pod adresem http://IP-HA:8123. Pierwsze logowanie to utworzenie konta administratora, ustawienie strefy czasowej i podstawowych parametrów.

Gdy UI się pojawi, dobrze jest od razu włączyć kopie zapasowe konfiguracji HA i przetestować snapshot VM w Proxmoxie, aby mieć pewność, że proces przywracania działa.

Snapshoty i backupy Home Assistanta w Proxmox

Przed każdą większą aktualizacją HA OS (lub serii dodatków) przydaje się snapshot VM. Operacja trwa zazwyczaj kilkanaście sekund i potrafi uratować wiele godzin pracy przy nieudanej aktualizacji.

Backup całej VM można skonfigurować cyklicznie w zakładce „Backup” datacentre lub konkretnego node’a. Typowym wyborem jest tygodniowa kopia na storage NFS lub drugi dysk.

Oprócz backupu poziomu Proxmoxa dobrze działa równoległe tworzenie backupów z poziomu samego HA (tzw. snapshots). Ułatwia to przywrócenie konkretnej konfiguracji bez cofania całej maszyny.

Home Assistant w Dockerze na Proxmox – scenariusz dla lubiących kontrolę

Architektura: Linux w VM + Docker

Wariant dockerowy zakłada VM z linuksem (np. Debian/Ubuntu), a na nim Dockera i docker-compose. Proxmox zarządza tylko tą jedną maszyną, a wewnątrz VM powstaje mały ekosystem kontenerów.

Taki układ upraszcza migrację między hostami Proxmoxa: wystarczy przenieść VM i kopię katalogu z plikami konfiguracyjnymi Dockera. Cały stos (HA, MQTT, integracje) odtwarza się jednym docker compose up.

Tworzenie VM pod Dockera

Tworzenie VM jest podobne jak dla HA OS, z kilkoma różnicami:

• instalacyjny ISO wybranego systemu (np. Debian netinstall) jako media,
• CPU: 2–4 vCPU,
• RAM: 4–8 GB na start,
• dysk: min. 64 GB, jeśli w kontenerach będzie więcej usług.

Po instalacji systemu warto zainstalować Qemu Guest Agent, aby Proxmox miał lepszy wgląd w stan VM i mógł ją poprawnie zamykać.

Instalacja Docker i docker-compose

Na czystym Debianie instalacja Dockera sprowadza się do dodania repozytorium producenta, zainstalowania pakietów docker-ce, docker-ce-cli i containerd.io, a następnie dodania użytkownika do grupy docker.

W tym miejscu przyda się jeszcze jeden praktyczny punkt odniesienia: SSD NVMe PCIe 4.0 vs 5.0: realne różnice w grach, pracy i wirtualizacji.

docker-compose można zainstalować z repozytoriów lub jako wtyczkę docker compose w nowym CLI. Ważne, by używać wspieranej wersji, bo Home Assistant Container jest mocno zależny od prawidłowego mapowania wolumenów.

Definicja kontenera Home Assistant w docker-compose

Najwygodniej jest opisać Home Assistanta w pliku docker-compose.yml. Prosty przykład sekcji usługi:

services:
  homeassistant:
    image: ghcr.io/home-assistant/home-assistant:stable
    container_name: homeassistant
    volumes:
      - /opt/homeassistant/config:/config
    environment:
      - TZ=Europe/Warsaw
    restart: unless-stopped
    network_mode: host
    privileged: true

Korzystanie z network_mode: host upraszcza integracje sieciowe, bo kontener „widzi” sieć tak jak host. Jest to szczególnie ważne przy multicastach i autodetekcji urządzeń.

Struktura katalogów i backup konfiguracji

Katalog z konfiguracją (/opt/homeassistant/config w przykładzie) dobrze jest trzymać na osobnym dysku lub przynajmniej osobnej partycji. Ułatwia to backup i ewentualne odtworzenie na innej maszynie.

Backup można wykonywać prostym archiwizowaniem katalogu config (np. cron + tar), a dodatkowo snapshotem dysku VM w Proxmoxie. Taki podwójny mechanizm jest odporny na błędy jednej warstwy.

Dodawanie kolejnych usług: MQTT, Zigbee2MQTT, Node-RED

Kolejne usługi opłaca się uruchamiać w dodatkowych kontenerach, które opisuje ten sam plik docker-compose.yml. Przykładowo, broker MQTT (Mosquitto) i Zigbee2MQTT mogą współdzielić sieć i wolumeny:

services:
  mosquitto:
    image: eclipse-mosquitto
    volumes:
      - /opt/mosquitto/config:/mosquitto/config
      - /opt/mosquitto/data:/mosquitto/data
    ports:
      - "1883:1883"
    restart: unless-stopped

  zigbee2mqtt:
    image: koenkk/zigbee2mqtt
    volumes:
      - /opt/zigbee2mqtt/data:/app/data
    devices:
      - /dev/ttyUSB0:/dev/ttyUSB0
    depends_on:
      - mosquitto
    restart: unless-stopped

Takie podejście rozdziela odpowiedzialności: HA korzysta z MQTT jako usługi zewnętrznej, a Zigbee2MQTT obsługuje wyłącznie sieć Zigbee.

Aktualizacje i rollback w środowisku dockerowym

Aktualizacja Home Assistant Container to zmiana taga obrazu na nowszy lub uruchomienie docker compose pull, a następnie docker compose up -d. W praktyce warto mieć spisany prosty skrypt do aktualizacji.

Rollback jest możliwy, jeśli zachowa się wcześniejszy obraz lub ma się backup katalogu konfiguracji. Często wystarczy powrót do poprzedniej wersji tagu i podmiana katalogu config na kopię sprzed aktualizacji.

Integracja sprzętu z Home Assistantem na Proxmoxie

Przekazywanie urządzeń USB do VM

Najczęstszy scenariusz to podpięcie do serwera domowego dongla Zigbee, Z-Wave lub adaptera RS-485 na USB. Trzeba go „przełożyć” z hosta Proxmoxa do VM z Home Assistantem.

W GUI Proxmoxa służy do tego zakładka „Hardware” danej VM i opcja „Add > USB Device”. Po wybraniu odpowiedniego urządzenia będzie ono widoczne wewnątrz VM jak lokalny port szeregowy.

Przy kilku urządzeniach istotne jest, aby nie wybierać pozycji „Use USB Port”, tylko konkretne urządzenie po identyfikatorze, co zmniejsza ryzyko „przestawienia” się sprzętu po restarcie.

Passthrough PCIe dla bardziej wymagającego sprzętu

Dla kart PCIe (np. dedykowane karty sieciowe, kontrolery dysków, czasem specjalne interfejsy radiowe) można użyć mechanizmu passthrough IOMMU. Wymaga to włączenia odpowiednich opcji w BIOS i konfiguracji vfio na Proxmoxie.

Taki sprzęt jest wtedy widoczny w VM jak w fizycznej maszynie. Sprawdza się to, gdy Home Assistant lub towarzyszące usługi potrzebują pełnego dostępu do określonej karty, a nie tylko wirtualizowanego interfejsu.

Zigbee: HA Yellow, SkyConnect, ConBee i inne dongle

Najprostszym podejściem jest pojedynczy dongle Zigbee na USB przekazany do VM. Może to być HA SkyConnect, ConBee II czy tani adapter CC2652.

Wariant z HA OS często korzysta z dodatku Zigbee Home Automation lub Zigbee2MQTT jako Add-on. W Docker/VM lepiej sprawdza się zewnętrzny kontener Zigbee2MQTT, który korzysta z przełączonego do VM urządzenia /dev/ttyUSBx.

Przy większych instalacjach Zigbee kluczowa jest dobra antena i lokalizacja dongla. Często wystarczy przedłużacz USB i wyniesienie adaptera poza metalową obudowę serwera.

MQTT jako kręgosłup komunikacji

Broker MQTT jest centrum wymiany danych między Home Assistantem a wieloma innymi usługami: Zigbee2MQTT, Tasmota, ESPHome, integracje DIY. Dobrze, by był stabilny i miał backup konfiguracji.

Można użyć dodatku Mosquitto w HA OS lub osobnego kontenera/Dockera na tej samej VM, co HA Container. Osobny broker ułatwia diagnostykę i pozwala na testy z innych aplikacji niezależnie od HA.

Przy większej liczbie urządzeń przydaje się prosty monitoring brokera (np. metryki w Prometheusie) i limitowanie niepotrzebnych retencji wiadomości.

Obsługa „dziwnych” urządzeń: RS-485, Modbus, liczniki mediów

Integracja liczników energii, wody i ciepła

Większość liczników mediów da się odczytać przez Modbus, impulsy S0 lub gotowe bramki (np. Wi-Fi/LAN). Na Proxmoxie zwykle kończy się to dodatkowym adapterem USB–RS485 albo małym urządzeniem ESP jako pośrednikiem.

Przy adapterach USB–RS485 stosuje się ten sam mechanizm passthrough do VM co przy donglach Zigbee. W systemie pojawia się port szeregowy /dev/ttyUSBx, który następnie obsługuje integracja Modbus w HA lub dedykowany kontener (np. skrypt Python + MQTT).

Gdy licznik nie ma wygodnego interfejsu, praktyczne są gotowe moduły ESPHome z optycznym odczytem diody LED lub portu IR. Taki moduł publikuje dane po Wi-Fi, a Home Assistant pobiera je bez kombinowania z fizycznym dostępem do licznika.

Modbus TCP i RTU w Home Assistant

Modbus TCP jest najprostszy w środowisku wirtualnym, bo nie wymaga przekazywania sprzętu. Wystarczy, że urządzenie jest w tej samej sieci co VM, a konfiguracja w HA to kilka wpisów w configuration.yaml.

Przy Modbus RTU (RS-485) wybór jest między bezpośrednim podłączeniem USB–RS485 do serwera a małym konwerterem TCP–RS485 w rozdzielnicy. Drugi wariant lepiej skaluje się przy kilku licznikach rozproszonych po budynku.

Dane z Modbusa często przychodzą w surowej formie rejestrów. Dobrym nawykiem jest od razu ich przeliczenie w template sensors na kWh, m³ czy stopnie, zamiast nosić w konfiguracji „magiczne” współczynniki.

Integracja falowników PV i magazynów energii

Nowoczesne falowniki PV zwykle oferują Modbus TCP, REST API lub MQTT. Na Proxmoxie nie trzeba żadnych specjalnych zabiegów – wystarczy poprawnie ustawiona sieć VM i stałe IP falownika.

Jeśli producent dostarcza tylko chmurowe API, rozsądne jest ograniczenie się do odczytu danych (monitoring), bez opierania krytycznych automatyzacji na chmurze. Awaria internetu nie powinna zatrzymywać pracy domu.

Przy integracji magazynu energii dobrze jest wyraźnie rozdzielić encje pomiarowe (moc, stan naładowania) od sterujących. Reguły typu „ładuj/rozładuj” należy budować ostrożnie, z kilkoma warunkami zabezpieczającymi.

Do kompletu polecam jeszcze: Docker od zera: uruchom pierwszą aplikację w kontenerze w 15 minut — znajdziesz tam dodatkowe wskazówki.

ESPHome jako „rozszerzenie rąk” Home Assistanta

ESPHome dobrze łączy się z Proxmoxem w scenariuszur dockerowym: ESPHome można uruchomić jako osobny kontener obok Home Assistant Container lub jako dodatek w HA OS na osobnej VM.

Konfiguracje urządzeń ESP trzymane są w repozytorium (Git) lub na dysku VM. Migracja między node’ami Proxmoxa to wtedy tylko przeniesienie VM wraz z katalogiem esphome/.

Espami można „przyciągnąć” do Home Assistanta wiele dziwnych sygnałów: styk z kotła, czujnik analogowy 0–10V, przekaźnik do sterowania bramą. Zmniejsza to liczbę adapterów USB wpiętych bezpośrednio w serwer.

Sterowanie ogrzewaniem i kotłownią

Kotły i pompy ciepła pojawiają się w HA najczęściej jako:

• integracja po Modbus TCP/RTU,
• lokalne API producenta (HTTP, UDP),
• prosta automatyka na stycznikach przez przekaźniki ESP.

Przy sterowaniu źródłem ciepła nie ma miejsca na eksperymenty w godzinach szczytu. Reguły powinny zakładać bezpieczne stany domyślne, np. w razie braku odpowiedzi HA urządzenie przechodzi na własną krzywą pogodową lub termostat pokojowy.

Ha warto traktować jako „nadbudowę” nad istniejącą automatyką, a nie jedyne źródło sygnałów sterujących. Warstwa Proxmoxa i wirtualizacji dodaje kolejną złożoność – dobrze jest założyć, że może kiedyś przestać działać na kilka godzin.

Sieć VLAN i separacja ruchu IoT

W domu z rozbudowanym HA sensowne jest rozdzielenie ruchu IoT od sieci domowników, najczęściej przez VLAN-y na routerze i przełącznikach. Proxmox obsługuje VLAN tagging na interfejsach bridge bez problemu.

VM z Home Assistantem może mieć jeden wirtualny interfejs wpięty w bridge z dostępem do kilku VLAN-ów (tagowanych), a routing realizuje router. Alternatywnie można przydzielić osobny vNIC per VLAN i prostą segregację zrobić już w samej VM.

Odcinanie IoT od reszty LAN-u zmniejsza ryzyko, że „inteligentna” żarówka zobaczy NAS-a, a jednocześnie niczego nie utrudnia Home Assistantowi – to on jest centralnym punktem integracji.

Reverse proxy i dostęp z zewnątrz

Jeżeli panel HA ma być dostępny z internetu, lepiej nie wystawiać portu 8123 bezpośrednio z VM. Bezpieczniej jest użyć reverse proxy (np. Traefik, Nginx, Caddy) w osobnym kontenerze lub VM.

Proxy zajmuje się TLS (Let’s Encrypt), terminowaniem HTTPS i ewentualnym filtrowaniem ruchu. Home Assistant pozostaje schowany w sieci wewnętrznej, zwykle za adresem prywatnym.

Dobra praktyka to dodatkowa warstwa uwierzytelniania (np. Authelia, Cloudflare Access) przed HA. Nawet gdy samo konto HA zostanie przejęte, napastnik nie ominie drugiej bariery.

Monitorowanie Proxmoxa i Home Assistanta

Środowisko z Proxmoxem, Dockerem i HA łatwo rozbudować o lekki monitoring. Najprościej: kontener z Prometheusem i Grafaną, który zbiera dane zarówno z Proxmoxa (API), jak i HA (integracja Prometheus lub InfluxDB).

Podstawowe metryki to obciążenie CPU, RAM, opóźnienia I/O dysku, miejsce na storage oraz liczba restartów kontenerów. Alarmy można wysyłać z powrotem do HA (notyfikacje mobilne) albo do komunikatora.

Awarię dysku systemowego Proxmoxa lub storage’u VM lepiej wychwycić wcześniej po rosnącej liczbie błędów I/O niż po nagłym braku światła w domu, gdy przestaną działać automatyzacje.

Automatyzacje a warstwa wirtualizacji

Planowanie automatyzacji należy robić z założeniem, że VM może zostać zatrzymana na czas backupu, migracji czy aktualizacji Proxmoxa. Lepiej unikać scenariuszy, które wymagają ciągłej obecności HA do podtrzymania bezpiecznego stanu.

Tam, gdzie to możliwe, urządzenia powinny mieć swoje lokalne harmonogramy (np. głowice termostatyczne z własnym programem), a HA dodaje „inteligencję” – optymalizuje, ale nie podtrzymuje działania w ogóle.

Warto też utrzymywać krótki katalog integracji krytycznych: zasilanie, ogrzewanie, alarm. Im prostsza zależność między HA, VM i fizycznym sprzętem, tym mniej zaskoczeń podczas prac na Proxmoxie.

Strategie migracji między node’ami Proxmoxa

Przy klastrze Proxmoxa mocną stroną jest live migration VM z HA OS lub z Dockerem na inny host. Wymaga to współdzielonego storage’u lub replikacji wolumenów między węzłami.

Jeżeli współdzielony storage jest niemożliwy, sprawdza się kopia VM (backup na NFS) i odtworzenie na drugim node. Dla Home Assistant Container kluczowy jest przeniesiony katalog /config i analogiczne katalogi usług towarzyszących.

Migracje dobrze jest ćwiczyć „na sucho”, gdy w domu nikomu nie zależy na pełnej dostępności – np. rano w weekend. Pozwala to oszacować czas przerwy i wyłapać problemy z siecią lub storage’em zanim pojawią się pod presją.

Porządkowanie konfiguracji i wersjonowanie

Konfigurację YAML (szczególnie w scenariuszu dockerowym) wygodnie wersjonować w Git. Wystarczy repozytorium z configuration.yaml, szablonami, automatyzacjami i plikami docker-compose.yml.

Przy zmianach w środowisku (nowy node, inny storage, zmiana nazw interfejsów sieciowych) historia w Git szybko pokazuje, co zostało ruszone. Łatwiej też wykryć, kiedy „nagle” przestał działać konkretny fragment konfiguracji.

Kilka krótkich gałęzi na testy (np. nowy sposób obsługi oświetlenia) pozwala spokojnie eksperymentować bez rozwalania produkcyjnego HA, który steruje domem reszty domowników.

Bezpieczeństwo dostępu do Proxmoxa i HA

Panel Proxmoxa nie powinien być dostępny z internetu bezpośrednio. Najprościej: dostęp wyłącznie z VPN (WireGuard, OpenVPN), a ewentualne porty do HA – przez reverse proxy z dodatkową ochroną.

Kontrolę dostępu w HA warto oprzeć na kontach imiennych i rolach, a nie jednym koncie „admin” używanym wszędzie. Dla automatyzacji i integracji API dobrze jest tworzyć osobne tokeny o wąskim zakresie uprawnień.

Regularne aktualizacje Proxmoxa, systemów w VM i samych kontenerów da się ująć w prosty harmonogram. Stałe okno serwisowe raz w miesiącu to mniejszy stres niż łatanie kilkuletnich zaległości pod presją świeżo wykrytej podatności.

Najczęściej zadawane pytania (FAQ)

Czy Home Assistant na serwerze domowym jest lepszy niż gotowa bramka (Tuya, Xiaomi, IKEA)?

Na serwerze domowym Home Assistant daje więcej swobody niż gotowe bramki producentów. Nie ogranicza do jednego ekosystemu i pozwala łączyć sprzęty Wi‑Fi, Zigbee, Z‑Wave, BLE i urządzenia chmurowe w jednym miejscu.

Różnica jest szczególnie widoczna przy rozbudowanych automatyzacjach, np. łączących światła, rolety, ogrzewanie i fotowoltaikę. Na bramkach często się po prostu nie da tego zrobić albo trzeba kombinować z obejściami.

Jaki sprzęt wybrać pod Home Assistant na Proxmox – miniPC, NUC czy stary desktop?

Najpraktyczniejsze są miniPC i NUC: małe, ciche, z niskim zużyciem prądu i wystarczającą mocą pod Proxmoxa, Home Assistanta i kilka dodatkowych usług. Dobrze sprawdza się konfiguracja z 16 GB RAM i SSD NVMe.

Stary desktop jest dobry na start, gdy już stoi w domu, ale przy pracy 24/7 zwykle wychodzi drożej na rachunku za prąd i bywa głośny. NAS z wirtualizacją może wystarczyć, ale ma słabsze CPU i mniej elastyczną rozbudowę.

Ile RAM i CPU potrzebuje Home Assistant na serwerze domowym?

Dla samego Home Assistanta wystarczą 2 rdzenie CPU i 2–4 GB RAM. Taka konfiguracja spokojnie obsłuży kilkadziesiąt urządzeń i podstawowe automatyzacje.

Jeśli na tym samym serwerze mają działać inne maszyny (np. router wirtualny, serwer plików, monitoring, kontenery Dockera), rozsądnym minimum jest 4 rdzenie/8 wątków i 16 GB RAM. Dzięki temu nie trzeba co chwilę patrzeć w zużycie pamięci i można bez stresu dodać kolejne usługi.

Czy Home Assistant na serwerze domowym działa bez internetu?

Tak, większość integracji Home Assistanta może pracować lokalnie, o ile same urządzenia nie są „twardo” chmurowe. Gdy padnie internet, światła, ogrzewanie, sceny czasowe i proste automatyzacje nadal będą działać.

Problem pojawia się przy sprzętach i integracjach, które wymagają chmury producenta (część gniazdek Wi‑Fi, kamer czy systemów alarmowych). Dlatego przy nowym zakupie lepiej szukać urządzeń z obsługą lokalnego API, MQTT albo standardów typu Zigbee czy Z‑Wave.

Czy do Home Assistant na Proxmox potrzebny jest UPS?

UPS nie jest wymagany, ale przy automatyce odpowiedzialnej za bezpieczeństwo (alarm, czujniki, bramy) jest bardzo rozsądnym dodatkiem. Chroni przed nagłą utratą zasilania i uszkodzeniem systemu plików.

Nawet prosty UPS wystarczy, żeby serwer i router wytrzymały krótkie przerwy w dostawie prądu, a przy dłuższej awarii dał się spokojnie wyłączyć Proxmox i maszyny wirtualne. Dobrą praktyką jest też podpięcie routera i serwera do różnych obwodów zasilania.

Jak najlepiej podłączyć serwer z Home Assistantem do sieci domowej?

Serwer powinien być podłączony przewodowo przez Ethernet do głównego routera lub przełącznika. Uplink po Wi‑Fi to proszenie się o losowe problemy z integracjami i opóźnienia w reakcjach automatyzacji.

Przy większej liczbie urządzeń IoT często stosuje się osobny SSID lub VLAN dla „sprzętów smart”. Ułatwia to odseparowanie ich od komputerów domowników i lepszą kontrolę ruchu, a Home Assistant nadal może się z nimi swobodnie komunikować po lokalnych adresach IP.

Jakie są najczęstsze błędy przy budowie serwera domowego pod Home Assistant i Proxmox?

Najczęstsze problemy to:

• instalacja Proxmoxa na pendrivie USB jako głównym dysku (niska żywotność, słaba wydajność),
• zbyt mało RAM, np. 4–8 GB na całość, co kończy się intensywnym swapowaniem i „przywieszaniem” maszyn,
• serwer podłączony do routera po Wi‑Fi zamiast po kablu,
• miniPC upchnięty w szafce bez wentylacji, który się przegrzewa i zaczyna zbijać taktowanie CPU.

Bezpieczniej od razu założyć, że oprócz Home Assistanta pojawią się też inne projekty i zostawić zapas: RAM, miejsce na SSD i przynajmniej jeden wolny port sieciowy.

Źródła informacji

• Home Assistant Documentation. Home Assistant Project – Oficjalna dokumentacja instalacji, wymagań i integracji Home Assistant
• Proxmox VE Administration Guide. Proxmox Server Solutions – Oficjalny podręcznik Proxmox VE: instalacja, storage, backup, VM/LXC
• Docker Overview. Docker Inc. – Dokumentacja Dockera: podstawy kontenerów, obrazy, zastosowania w serwerach domowych
• IEEE 802.11 Wireless LAN Standards. IEEE – Normy techniczne Wi‑Fi, przydatne przy planowaniu sieci dla IoT
• Zigbee Specification. Zigbee Alliance – Specyfikacja standardu Zigbee używanego w urządzeniach smart home
• Z-Wave Technical Overview. Z-Wave Alliance – Opis technologii Z‑Wave i jej zastosowań w automatyce domowej
• Small Form Factor PC Guide for Home Labs. ServeTheHome – Przegląd miniPC/NUC pod kątem wirtualizacji i serwerów domowych