# Migracja automatyki domowej: jak przejść z MajorDoMo na osysHome bez przestoju
Po ośmiu latach eksploatacji MajorDoMo jako głównej platformy automatyki domowej autor napotkał krytyczny wzrost złożoności utrzymania. Każda poprawka w scenariuszach wymagała łańcucha weryfikacji, zamieniając rutynowe zadania w wieczorne maratony. Decyzja o przejściu na własną platformę osysHome była podyktowana praktyczną koniecznością — zmniejszeniem obciążenia poznawczego podczas pracy z systemem. W artykule opisany jest szczegółowy plan migracji krok po kroku bez przestoju, kluczowe błędy oraz taktyki stosowane do dowolnych dużych systemów automatyki.
Dlaczego MajorDoMo przestał sobie radzić
System, pierwotnie zbudowany jako stanowisko testowe, przez osiem lat przekształcił się w krytycznie ważny element infrastruktury. Liczba obiektów osiągnęła 200 jednostek: od fizycznych czujników po wirtualne encje i logikę usługową. Główne problemy miały charakter systemowy:
- Spowolnienie reakcji automatyzacji — procesy tła zaczęły konkurować o zasoby
- Fragmentacja danych — trudności w śledzeniu powiązań między obiektami
- Brak przejrzystości dostępów — konieczność ręcznej konfiguracji praw dla nowych scenariuszy
- Kruchość scenariuszy — każda poprawka wymagała weryfikacji zależności
Kluczowym wyzwalaczem stał się efekt „drobnej poprawki”: zadanie szacowane na 10 minut regularnie przeradzało się w kilkugodzinną diagnostykę. W systemach tej skali problem utrzymania wyparł problem rozszerzania funkcjonalności.
Strategia równoległego uruchomienia
Krytycznym błędem podczas migracji jest próba „wielkiego przełączenia”. Zamiast tego wdrożono etapowy przejście z zachowaniem pełnej sprawności na każdym etapie:
- Izolowane uruchomienie osysHome — instalacja obok MajorDoMo na tym samym sprzęcie (SOYO M4 AIR N95 16GB+512GB pod Ubuntu Server 25.10)
- Weryfikacja integracji — ręczne testowanie sterowania urządzeniami przez MQTT, Zigbee2MQTT i ESPHome
- Budowa modelu obiektowego — nie kopiowanie, lecz reorganizacja struktury pod kątem przyszłego utrzymania
- Dublowanie automatyzacji — nowa logika aktywowana tylko po potwierdzeniu pełnej sprawności
Ten sposób eliminował ryzyko całkowitego przestoju. W razie błędu system automatycznie pozostawał na MajorDoMo, co pozwoliło uniknąć pilnych poprawek w godzinach nocnych.
Taktyka przenoszenia urządzeń
Urządzenia migrowano grupami według kryterium funkcjonalnego, a nie fizycznego rozmieszczenia. Taka metoda minimalizowała obciążenie poznawcze i przyspieszała lokalizację problemów:
- Etap 1: Przeniesienie komponentów infrastrukturalnych (MQTT-broker, Zigbee-brama)
- Etap 2: Grupowanie według typów urządzeń (oświetlenie, klimat, bezpieczeństwo)
- Etap 3: Integracja złożonych ekosystemów (Xiaomi z odkurzaczem, żyrandolem, nawilżaczem)
Szczególnej uwagi wymagały urządzenia Xiaomi — ich API ujawniło nieoczywiste cechy, pochłaniając 30% czasu migracji. Poidełko dla zwierząt, które wydawało się trywialne, zabrało dwa wieczory z powodu asynchronicznych powiadomień.
Nieoczekiwane ulepszenia w trakcie procesu
Migracja stała się katalizatorem refaktoryzacji przestarzałych komponentów. Równolegle z przenoszeniem wykonano:
- Wymianę przekaźników Tasmota na ESPHome z ujednoliconym interfejsem
- Wdrożenie bramy Bluetooth do zbierania danych z czujników temperatury
- Przeniesienie konwertera Modbus liczników na natywne wsparcie
- Uproszczenie interfejsu bieżącej linii przez MAX7219
Ten sposób okazał się skuteczniejszy niż „czysty” transfer. Eliminacja długu technicznego podczas migracji zmniejszyła długoterminowe koszty utrzymania, mimo krótkoterminowego wzrostu nakładu pracy.
Podsumowanie: co zmieniło się po przejściu
Subiektywne wskaźniki wykazały spadek kosztów operacyjnych:
- Skrócenie czasu poprawek — z 2 godzin do 15 minut dla typowych scenariuszy
- Uproszczenie dostępów — scentralizowane zarządzanie prawami zamiast ręcznych ustawień
- Wzrost stabilności — zniknięcie fałszywych wyzwoleń dzięki uproszczonemu modelowi obiektowemu
OsysHome ma jednak ograniczenia. Początkującym trudniej opanować system z braku gotowych scenariuszy. Dokumentacja nie nadąża za rozwojem kodu, a niektóre funkcje (np. integracja z ThinQ) wymagają ręcznej konfiguracji. Dla autora te kompromisy są uzasadnione spadkiem obciążenia poznawczego.
Co najważniejsze
- Równoległe uruchomienie — warunek konieczny dla systemów z zerową tolerancją na przestoje
- Grupowanie według funkcjonalności przyspiesza debugowanie 2–3 razy w porównaniu z grupowaniem fizycznym
- Migracja — najlepszy moment na refaktoryzację przestarzałych komponentów
- Utrzymywalność ważniejsza od funkcjonalności dla systemów starszych niż 5 lat
- Urządzenia Xiaomi wymagają 30% rezerwy czasu z powodu nieoczywistych cech API
Przejście zajęło dwa tygodnie przy wieczornej pracy po 2–3 godziny. Kluczowy rezultat — spadek psychologicznej bariery przed poprawkami scenariuszy. Dla właścicieli stabilnych stanowisk MajorDoMo migracja nie jest konieczna, ale przy wzroście złożoności stopniowe przejście okazało swoją skuteczność. Główna lekcja: wybór platformy powinien zależeć nie od cech technicznych, lecz od długoterminowej utrzymywalności.
— Editorial Team
Brak komentarzy.