Jak to u mnie działa

Co znajdziesz na tej stronie?

• Core - Homeassistant
• Infrastruktura Zigbee
• Infrastruktura Bluetooth
• Agregacja odtwarzaczy audio
• DIY - własne projekty
• Storage
• Monitoring
• Podsumowanie
• Co dalej?

---

CORE

Home Assistant

Sercem całej automatyki jest Home Assistant. To centralny punkt, w którym zbiegają się wszystkie dane, decyzje i akcje w systemie.

Home Assistant u mnie:

• zarządza automatyzacjami i scenami,
• rejestruje i przetwarza zdarzenia z całego ekosystemu,
• komunikuje się z urządzeniami poprzez różne protokoły (MQTT, Zigbee, Bluetooth, HTTP),
• odpowiada za sterowanie oświetleniem, gniazdkami i urządzeniami wykonawczymi,
• zbiera dane z czujników i integracji,
• tworzy i udostępnia dane historyczne (lokalnie oraz w zewnętrznych bazach),
• stanowi interfejs decyzyjny — to tu zapada „co”, „kiedy” i „dlaczego” ma się wydarzyć.

W praktyce Home Assistant nie musi bezpośrednio obsługiwać każdego urządzenia. Często działa jako orchestrator, który:

• odbiera dane z brokerów (MQTT),
• wysyła polecenia do usług pośrednich,
• reaguje na stany i metryki,
• spina wszystkie warstwy w jeden, przewidywalny system.

To właśnie ta rola — centralnego mózgu, a nie „kolejnej aplikacji” — sprawia, że Home Assistant jest fundamentem całej architektury automatyki domowej.

---

Zigbee

Koordynator

Jako koordynatora Zigbee używam SLZB-06 — jednego z najpopularniejszych i najbardziej stabilnych urządzeń w tej klasie. Wcześniej korzystałem z Conbee II, jednak przesiadka na sprzęt z PoE pozwoliła mi całkowicie wyeliminować problemy typowe dla USB oraz zapewnić większą stabilność całej sieci Zigbee.

Zigbee2MQTT - Warstwa pośrednia

Urządzenia Zigbee obsługuję za pomocą Zigbee2MQTT. To narzędzie, które potrafi wywoływać skrajne emocje — jedni je uwielbiają, inni omijają szerokim łukiem.

U mnie sprawdza się bardzo dobrze:

• działa stabilnie,
• daje pełną kontrolę nad urządzeniami,
• i pozwala świadomie zarządzać komunikacją Zigbee ↔ MQTT.

Zigbee2MQTT pełni tu rolę tłumacza między światem Zigbee a MQTT.

EMQX - Broker MQTT

Do komunikacji pomiędzy Zigbee2MQTT a Home Assistant używam EMQX jako brokera MQTT.

Tak — to trochę armata na muchę, ale oferuje kilka kluczowych zalet:

• czytelny interfejs webowy,
• pełną kontrolę nad użytkownikami i usługami,
• autoryzację oraz ACL,
• podgląd payloadów w czasie rzeczywistym,
• natywne metryki, które trafiają później do monitoringu.

EMQX jest centralnym punktem wymiany danych w całym systemie.

Przepływ danych Zigbee

Technicznie wygląda to tak:

Zigbee2MQTT i Home Assistant są równorzędnymi klientami MQTT — komunikują się ze sobą wyłącznie za pośrednictwem brokera.

Sensor ↔ Zigbee2MQTT

Komunikacja dwukierunkowa (Zigbee) Urządzenie Zigbee wysyła m.in.:

• stany (temperature, humidity, battery, occupancy)

Zigbee2MQTT wysyła do urządzenia:

• komendy (on/off, brightness, bind, configure)

Na tym etapie nie ma MQTT — jest wyłącznie natywny protokół Zigbee.

Zigbee2MQTT ↔ Broker

Komunikacja dwukierunkowa przez MQTT

Zigbee2MQTT:

• publikuje stany urządzeń (np. zigbee2mqtt/sensor1)
• subskrybuje tematy z komendami (np. zigbee2mqtt/device1/set)

Broker:

• nie interpretuje danych,
• nie „wie”, że to Zigbee — widzi tylko payloady MQTT.

Broker ↔ Home Assistant

Komunikacja dwukierunkowa przez MQTT

Home Assistant:

• subskrybuje stany urządzeń,
• publikuje komendy (np. turn_on, set_brightness)

Broker:

• routuje wiadomości pomiędzy klientami,
• egzekwuje reguły dostępu i autoryzacji.

Dlaczego tak?

Taki układ:

• rozdziela odpowiedzialności,
• ułatwia diagnostykę problemów,
• pozwala monitorować cały przepływ danych,
• i daje pełną kontrolę nad komunikacją w systemie.

To podejście szczególnie dobrze sprawdza się w środowiskach self-hosted i większych instalacjach smart home.

---

Bluetooth

W domu korzystam również z urządzeń komunikujących się przez Bluetooth Low Energy (BLE). Do ich obsługi używam Bluetooth Proxy zbudowanych na ESP32 i opartych o ESPHome.

Bluetooth w automatyce domowej ma swoje ograniczenia — krótki zasięg, wrażliwość na zakłócenia i niestabilność połączeń. Proxy rozwiązuje te problemy, pozwalając rozmieścić punkty odbioru sygnału w różnych częściach domu, bez konieczności trzymania wszystkiego w pobliżu serwera z Home Assistant.

W praktyce działa to jak „przedłużacz Bluetooth”.

Bluetooth Proxy (ESP32 + ESPHome) Bluetooth Proxy w ESPHome nie zarządza urządzeniami samodzielnie.

ESP32 pełni rolę:

• skanera BLE,
• przekaźnika pakietów,
• zdalnej anteny Bluetooth.

Cała logika, interpretacja danych i integracja urządzeń odbywa się po stronie Home Assistant.

To bardzo ważne rozróżnienie ponieważ ESP32:

• nie zna urządzeń
• nie parsuje danych
• nie trzyma stanu

Jakie urządzenia obsługuję?

Na ten moment Bluetooth Proxy obsługuje u mnie głównie:

• czujniki roślin MiFlora
• czujniki temperatury

To typowe urządzenia BLE, które idealnie nadają się do pracy w trybie proxy.

Integracja z Home Assistant

Urządzenia wykrywane przez Bluetooth Proxy są:

• automatycznie odkrywane w Home Assistant,
• widoczne bez ręcznej konfiguracji,
• przypisywane do konkretnego proxy na podstawie siły sygnału.

Home Assistant sam buduje mapę widoczności BLE, dzięki której:

• widać, który proxy „widzi” dane urządzenie,
• można ocenić jakość sygnału (RSSI),
• łatwo zdiagnozować problemy z zasięgiem.

To ogromna zaleta przy większej liczbie sensorów i proxy.

Jak wygląda komunikacja?

W największym skrócie:

Czujnik → Bluetooth Proxy → Home Assistant

Ale technicznie wygląda to tak:

Urządzenie BLE → Bluetooth Proxy

Jednokierunkowo (broadcast / reklamy BLE)

• czujnik nadaje pakiety BLE
• ESP32 je odbiera
• brak stałego połączenia

Tu nie ma IP, MQTT ani TCP — czysty Bluetooth Low Energy.

Bluetooth Proxy → Home Assistant

Dwukierunkowo (API ESPHome)

ESP32 wysyła surowe pakiety BLE do Home Assistant

Home Assistant:

• dekoduje dane,
• identyfikuje urządzenie,
• tworzy encje,
• wysyła polecenia (jeśli urządzenie je wspiera)

ESP32 działa tu jak zdalna karta Bluetooth podpięta do Home Assistant.

Ważna konsekwencja tego podejścia

• nie obciążasz ESP32 (brak parsowania, brak logiki)
• większe obciążenie sieci (strumień danych BLE → HA)
• pełna kontrola i widoczność po stronie Home Assistant
• łatwe skalowanie (dokładasz kolejne proxy)

To świadomy trade-off, który w praktyce bardzo dobrze się sprawdza.

---

Multimedia

(prawie)Cały system audio w domu opieram o Music Assistant. Home Assistant nie steruje głośnikami bezpośrednio — pełni rolę nadrzędnej logiki i automatyzacji, a Music Assistant jest wyspecjalizowaną warstwą audio.

To celowy podział ról.

Music Assistant — warstwa pośrednia audio

Music Assistant pełni u mnie kilka kluczowych funkcji:

• proxy dla urządzeń audio. Nie muszę integrować każdego głośnika osobno w Home Assistant.
• centralny interfejs do sterowania muzyką. Jedno miejsce do wyboru źródła, strefy, głośności i odtwarzania.
• dostawca encji media_player dla Home Assistant. Home Assistant widzi logiczne encje, a nie fizyczne głośniki.

Dzięki temu HA nie musi „znać się” na protokołach audio, kodekach czy źródłach dźwięku.

Największa zaleta tego podejścia

• Music Assistant działa samodzielnie
• szybkie UI,

Home Assistant wchodzi do gry dopiero wtedy, gdy:

• potrzebujesz automatyzacji,
• scen,
• powiązania audio z innymi zdarzeniami w domu.

Jak wygląda komunikacja?

W największym skrócie:

Głośnik ↔ Music Assistant ↔ Home Assistant

Ale technicznie wygląda to tak:

Głośnik ↔ Music Assistant

Dwukierunkowo, protokół zależny od urządzenia

Music Assistant komunikuje się z głośnikami przez:

• AirPlay
• Chromecast
• DLNA
• Squeezelite (LMS) - np raspberry pi esp jako radio/odtwarzacz

Music Assistant:

• steruje odtwarzaniem,
• kontroluje głośność,
• zarządza synchronizacją stref,
• monitoruje aktualny stan odtwarzania.

Home Assistant nie widzi tych połączeń.

Music Assistant ↔ Home Assistant

Dwukierunkowo, integracja logiczna

Home Assistant:

• widzi encje media_player,
• wysyła komendy (play, pause, volume, source),
• reaguje na zmiany stanu (playing, idle, paused).

Music Assistant:

• tłumaczy te komendy na konkretne akcje audio,
• raportuje aktualny stan odtwarzania.

Co zyskujemy?

• czystą architekturę
• brak chaosu integracji audio w HA
• łatwe dodawanie nowych głośników
• możliwość sterowania muzyką bez automatyki

I co najważniejsze — audio nie blokuje ani nie komplikuje Home Assistanta.

---

Urządzenia DIY

Do własnych projektów DIY korzystam głównie z ESPHome. Powody są proste:

• intuicyjna konfiguracja i czytelny YAML,
• ogromna baza kompatybilnych czujników i modułów,
• stabilne działanie, bez ciągłych restartów,
• natywna integracja z Home Assistant — bez dodatkowych wtyczek czy obejść.

ESPHome daje pełną kontrolę nad urządzeniami i pozwala budować niestandardowe rozwiązania w prosty sposób.

Jak wygląda komunikacja?

W mojej instalacji ESPHome używa MQTT. Dzięki temu:

• wszystkie dane z urządzeń trafiają do EMQX jako centralnego brokera,
• Home Assistant subskrybuje stany i wysyła komendy przez EMQX,
• cały ekosystem ma spójny, jednolity przepływ danych i pełny wgląd w payloady.

W największym skrócie:

ESPHome device ↔ EMQX (MQTT broker) ↔ Home Assistant

Technicznie wygląda to tak:

ESPHome ↔ EMQX

Dwukierunkowo przez MQTT

• ESPHome(urządzenie) publikuje stany czujników (np. temperatura, wilgotność, stan przekaźnika).
• ESPHome(urządzenie) subskrybuje komendy (np. switch/relay1/set) wysyłane przez Home Assistant.

EMQX ↔ Home Assistant

Dwukierunkowo przez MQTT

• Home Assistant subskrybuje encje ESPHome(urządzenie) (sensor, switch, binary_sensor).
• Home Assistant publikuje komendy, które EMQX dostarcza do konkretnych urządzeń ESP.

Dlaczego tak?

• Zachowuję spójność całego ekosystemu (Zigbee, Bluetooth, DIY) — wszystko trafia przez jednego brokera.
• Mam pełny wgląd w payloady i historię komunikacji.
• Możliwość debugowania i automatyzowania działań bez ryzyka, że coś „zniknie” w sieci.

Dzięki takiemu rozwiązaniu mam pełną świadomość, co się dzieje w systemie, a diagnostyka i rozbudowa automatyzacji staje się prostsza.

Oczywiście, ESPHome można integrować bezpośrednio z Home Assistant, ale dla większych instalacji MQTT daje skalowalność i przewidywalność działania.

---

Bazy danych

Dane w Home Assistant potrafią bardzo szybko urosnąć — logi, stany czujników, historia zdarzeń, statystyki. Dlatego wybór odpowiedniej bazy danych ma realny wpływ na stabilność, wydajność i późniejsze utrzymanie systemu.

U mnie role są jasno rozdzielone: jedna baza do działania Home Assistanta „tu i teraz”, druga do długoterminowej historii.

MariaDB - Główna baza dla home assistanta

MariaDB to bardzo solidny wybór jako główna baza danych dla Home Assistanta.

Dlaczego właśnie ona:

• jest szybsza i stabilniejsza niż domyślna SQLite,
• lepiej radzi sobie z dużą liczbą zapisów (sensory, logi, zdarzenia),
• jest znacznie bardziej odporna na nagłe restarty i awarie zasilania,
• pozwala na sensowną optymalizację, backupy i monitoring,
• działa dokładnie tak, jak „dorosła” baza danych powinna działać.

To nie jest egzotyczny wybór — MariaDB jest jedną z najczęściej polecanych baz dla Home Assistanta i sprawdza się świetnie w środowiskach, gdzie system działa 24/7.

InfluxDB - dane historyczne

InfluxDB wykorzystuję do danych, które mają charakter czasowy i które chcę analizować w dłuższym okresie:

• temperatury,
• wilgotność,
• zużycie energii,
• inne metryki zmieniające się w czasie.

Dlaczego InfluxDB:

• jest zaprojektowana specjalnie pod dane typu time-series,
• bez problemu obsługuje ogromne ilości zapisów,
• idealnie nadaje się do wizualizacji i analizy trendów,
• integruje się z Grafaną praktycznie „out of the box”.

InfluxDB pełni u mnie rolę archiwum i źródła danych do wykresów — odciąża główną bazę Home Assistanta i pozwala zachować historię bez kompromisów wydajnościowych.

---

Monitoring

Żeby mieć realną kontrolę nad tym, co dzieje się w mojej infrastrukturze, postawiłem na ekosystem monitoringu od Grafana Labs. Zależało mi nie tylko na „ładnych wykresach”, ale na pełnej obserwowalności: metrykach, logach i alertach — w jednym, spójnym systemie.

Całość składa się z kilku komponentów, z których każdy ma jasno określoną rolę.

Moje rozwiązanie składa się z kilku komponentów:

Alloy agent zbierający dane

Alloy to agent od Grafana Labs, który w jednym procesie łączy funkcje kilku popularnych narzędzi:

• Node Exporter — metryki systemowe (CPU, RAM, dysk, sieć),
• cAdvisor — metryki kontenerów Docker,
• agent telemetryczny — przesył danych dalej.

Zbiera metryki zarówno z hosta, jak i z każdego kontenera. W praktyce zastąpił mi 2–3 osobne usługi, upraszczając konfigurację i zmniejszając narzut na system.

Loki logi w jednym miejscu

Loki odpowiada za zbieranie i przeszukiwanie logów.

• agreguje logi ze wszystkich kontenerów,
• pozwala na szybkie filtrowanie po źródle, poziomie czy treści,
• ułatwia diagnozowanie problemów bez „skakania” po kontenerach,
• umożliwia tworzenie alertów opartych o konkretne wpisy w logach.

Zamiast szukać logów po SSH, Dockerze czy plikach — wszystko mam w jednym panelu.

Prometheus silnik metryk

Prometheus to warstwa odpowiedzialna za:

• zbieranie metryk z Alloy,
• przechowywanie danych czasowych,
• udostępnianie ich do dalszej analizy.

Sam w sobie nie jest narzędziem wizualnym — jego zadaniem jest niezawodne gromadzenie danych, a nie ich prezentacja.

Grafana wizualizacja i analiza

Grafana to warstwa, w której wszystko nabiera sensu.

To tutaj:

• buduję dashboardy,
• analizuję historię,
• obserwuję trendy,
• konfiguruję alerty.

Widzę w jednym miejscu m.in.:

• obciążenie systemu,
• stan kontenerów,
• metryki MQTT,
• temperatury,
• zużycie zasobów,

problemy zanim staną się problemami.

Alerty

Sam monitoring to za mało — kluczowe jest to, żeby wiedzieć, kiedy coś idzie nie tak.

Dlatego alerty z Grafany wysyłam bezpośrednio do Home Assistanta. Dzięki temu:

• pojawiają się jako natywne notyfikacje,
• mogę reagować automatycznie (np. restart usługi),
• nie muszę zaglądać do Grafany „na zapas”.

Celem nie jest patrzenie w wykresy — tylko dostanie informacji zanim coś realnie przestanie działać.

---

Podsumowania

System jest zbudowany warstwowo i modułowo. Home Assistant odpowiada za logikę i automatyzacje, ale nie jest krytycznym punktem działania domu. Zigbee, MQTT, Bluetooth, bazy danych i monitoring działają niezależnie od siebie, a komunikacja jest rozproszona.

Dzięki temu:

• awaria HA nie blokuje sterowania światłami ani urządzeniami,
• dane nadal są zbierane i przesyłane,
• kluczowe elementy są backupowane,
• a część logiki działa bezpośrednio na urządzeniach.

Krótko mówiąc: system jest odporny, obserwowalny i da się nim zarządzać nawet wtedy, gdy coś się wysypie.