Automatykę domową prowadzę w tym budynku od 2019 roku, na Home Assistant.
Początkowo było to programowanie sterowników, które z czasem przerodziło się w pełni zintegrowany system oparty na Home Assistant.
Rozwój przebiegał stopniowo: system rozbudowywałem o kolejne czujniki i integracje.
Obecnie obejmuje około 400 encji, z czego 40–50 to oświetlenie. Każdy punkt świetlny w budynku jest sterowany przez ten system.
Architektura
Home Assistant jako mózg, MySensors i Arduino jako ciało
Fundamentem jest MySensors. Sześć płytek Arduino Mega podłączono do jednego huba USB, który łączy się bezpośrednio z mini PC z uruchomionym Home Assistant.
Rozwiązanie nie wykorzystuje warstwy radiowej ani pośredniczącej bramki, co eliminuje dwa potencjalne punkty awarii. Niektóre sensory są jednak połączone przez RFID / Zigbee oraz wykorzystywany jest MQTT.
Systemy wizyjne zostały świadomie odseparowane od głównego hosta. Frigate działa na drugim mini PC w środowisku Proxmox. Dzięki temu analiza wideo i sterowanie oświetleniem nie współdzielą zasobów jednej maszyny.
To jedna z nielicznych decyzji architektonicznych, do których nie musiałem wracać.
Co się zepsuło
Trzy awarie w siedem lat
W ciągu siedmiu lat eksploatacji wystąpiły trzy awarie. Żadna z nich nie dotyczyła logiki automatyzacji.
1. Raspberry Pi. Urządzenie nie utrzymywało stabilnego połączenia sieciowego po kablu, a łącze ulegało okresowym zerwaniom. Jest to znany problem w Raspberry Pi 3/4. Można pracować po Wi-Fi, natomiast moim założeniem było pełne bezpieczeństwo, niezawodność, szybkość i brak zakłóceń.
W budynku, w którym całe oświetlenie, rolety i urządzenia zależą od jednego hosta, niestabilny interfejs sieciowy jest niedopuszczalny. Migracja na mini PC kilka lat temu całkowicie rozwiązała problem.
2. Moje własne okablowanie Arduino. Instalacja była funkcjonalna, ale wykonana niestarannie. Powodowała sporadyczne usterki, których nie dało się odtworzyć, a ich diagnoza pochłaniała całe wieczory. Szczegółowy opis: pułapka Arduino, która psuje projekty
3. Dwa stare przekaźniki Shelly. Uległy awarii po kilku latach pracy. Nowsze egzemplarze działają bez zastrzeżeń, co wskazuje na naturalne zużycie podzespołów, a nie na wadę projektową.
Wszystkie awarie miały charakter fizyczny (interfejs sieciowy, połączenie lutowane, przekaźnik), a nie programowy. Zakładałem, że najsłabszym ogniwem będzie oprogramowanie. Okazało się inaczej. Dlatego dziś więcej uwagi poświęcam warstwie podstawowej, mniej efektownej, niż warstwie logiki.
Konwencja nazewnictwa
Jak czytać nazwy encji
Kolejne człony oznaczają urządzenie, numer węzła, numer dziecka (child ID) oraz typ wartości. Identyfikator generowany maszynowo jest stabilny i jednoznaczny, co ma kluczowe znaczenie, gdy sześć płytek raportuje do jednej instancji. Jest jednak nieczytelny dla człowieka, dlatego warstwę prezentacji zapewnia friendly name, przypisany do każdej encji:
switch.arduino_4_0_6 → „Światło Iga sufit 1/2”
Obie warstwy mają jedno, ściśle określone zadanie. Identyfikator jest generowany automatycznie, niezmienny i nigdy nie wprowadzam go ręcznie. Friendly name to jedyny element widoczny dla domowników. Nie zmieniałem identyfikatorów 400 encji i nie polecam tego nikomu.
Automatyzacją procesów zajmuję się zawodowo od dwudziestu lat i posiadam certyfikaty ITIL 4, Six Sigma oraz PRINCE2. Do środowiska domowego przenoszę z tego doświadczenia jedną zasadę, czyli kolejność działań: standaryzacja, monitorowanie, optymalizacja, automatyzacja. Chaosu nie da się zautomatyzować, a automatyka domowa łamie tę regułę niemal systematycznie: najpierw automatyzuje, a standaryzacji nie wdraża wcale.
Rozwiązania, z których zrezygnowałem
Testuję wiele automatyzacji, ale w eksploatacji zostawiam niewiele. Wszystkie wycofane rozwiązania łączy jedno: dobrze wypadają w demonstracji, a w codziennym użytkowaniu nie dają wartości. Pełną listę tych, które zostały, i tych, które wyłączyłem, zebrałem osobno: 10 automatyzacji, które faktycznie działają.
- Oświetlenie RGB synchronizowane z muzyką, której nikt nie słuchał.
- Panel monitorowania zużycia energii w czasie rzeczywistym, który ani razu nie stał się podstawą żadnej decyzji.
- Rozbudowane komendy głosowe. Wypowiedzenie frazy „Hey Google, włącz scenę wieczór filmowy” trwało dłużej niż ręczne ściemnienie światła.
- Nadmiar powiadomień informacyjnych. Doprowadził on do tego, że zacząłem ignorować wszystkie, także te krytyczne (alert fatigue).
Analiza przyczyn niepowodzenia każdego z nich: anatomia nieudanych pomysłów na automatykę domową
Dwa tryby działania i ryzyko ich mieszania
Tryb automatyczny kontra tryb ręczny
Dwa tryby działania są w Home Assistant jedyną decyzją, której po siedmiu latach nie żałuję. Reszta architektury jest dość typowa.
Ostatecznie całość sprowadziła się do podziału na dwa tryby pracy. To prawdopodobnie najbardziej praktyczna część tego opisu. Te dwa tryby rozwinąłem później w pięciostopniową skalę: od automatyzacji do autonomii.
- Tryb za zgodą (human-in-the-loop). System mierzy, analizuje i przedstawia rekomendacje, a decyzję i działanie pozostawia człowiekowi. To użytkownik pełni rolę warstwy integrującej. Tryb jest przewidywalny i stabilny, dlatego od niego powinien zaczynać każdy.
- Tryb w ramach barier ochronnych (guardrails). System samodzielnie obserwuje, podejmuje decyzje, działa w wyznaczonych granicach i raportuje wyniki. Rola człowieka zmienia się z operatora na osobę definiującą te granice.
Przez lata popełniałem jeden błąd: łączyłem oba tryby w jednej instalacji, nie określając, do którego należy dana automatyzacja. To właśnie ta niejednoznaczność sprawia, że rozbudowana konfiguracja zaczyna działać w sposób nieprzewidywalny.
Co zrobiłbym inaczej
W budynku poprowadziłem około 6 km skrętki UTP kat. 5. Drugi raz zrobiłbym to inaczej.
- Mniej okablowania wewnątrz. Trasy w sufitach i przy drzwiach nigdy nie zostały wykorzystane. Projektowałem pod scenariusze, które się nie zmaterializowały.
- Więcej okablowania na zewnątrz. Ogród jest naturalnym kierunkiem dalszej rozbudowy, a obecnie nie ma tam żadnej infrastruktury. Okablowanie zewnętrzne jest tanie, dopóki wykopy są otwarte, a po ich zasypaniu jego koszt rośnie wielokrotnie.
Poza okablowaniem nie wprowadzałbym istotnych zmian. Rozwiązanie działa.
Dokumentacja architektury
Całą instalację dokumentuję w repozytorium, bo po siedmiu latach Home Assistant w domu to bardziej problem konfiguracji niż sprzętu. Architekturę opisałem w formie dokumentacji zamiast polegać na wiedzy w głowie: autonomous-living-architecture na GitHubie.
Projekt udostępniono na licencji MIT. Jest celowo niezależny od konkretnego oprogramowania, więc opisuje architekturę, a nie listę komponentów. Repozytorium zawiera dwie gałęzie, po jednej dla każdego z opisanych trybów działania.
