# Migrace domácí automatizace: jak přejít z MajorDoMo na osysHome bez výpadků
Po osmi letech provozu MajorDoMo jako hlavní platformy domácí automatizace se autor setkal s kritickým nárůstem složitosti údržby. Jakákoli úprava v scénářích vyžadovala řetězec kontrol, čímž měnila rutinní úkoly v večerní maratony. Rozhodnutí přejít na vlastní vývoj osysHome bylo diktováno praktickou nezbytností – snížit kognitivní zátěž při práci se systémem. V článku je podrobně popsán krok za krokem plán migrace bez výpadků, klíčové chyby a taktiky použitelné pro jakékoli velké systémy automatizace.
Proč MajorDoMo přestal zvládat
Systém, původně postavený jako testovací prostředí, se za osm let proměnil v kriticky důležitý infrastrukturní komponent. Počet objektů dosáhl 200 kusů: od fyzických senzorů přes virtuální entity až po servisní logiku. Hlavní problémy měly systémový charakter:
- Zpomalení reakcí automatizací – pozadí procesy začaly soutěžit o zdroje
- Fragmentace dat – složitost sledování vazeb mezi objekty
- Neprůhlednost přístupů – nutnost ručního nastavování práv pro nové scénáře
- Křehkost scénářů – jakákoli úprava vyžadovala ověření závislostí
Klíčovým spouštěčem se stal efekt „malé úpravy": úkol odhadovaný na 10 minut se pravidelně protáhl na hodiny ladění. Pro systémy takového rozsahu problém údržby vytlačil problém rozšiřování funkcí.
Strategie paralelního spuštění
Kritická chyba při migraci – pokus o „velké přepnutí“. Místo toho byl realizován postupný přechod s udržením funkčnosti na každém kroku:
- Izolované spuštění osysHome – instalace vedle MajorDoMo na stejném hardware (SOYO M4 AIR N95 16GB+512GB pod Ubuntu Server 25.10)
- Ověření integrací – ruční testování ovládání zařízení přes MQTT, Zigbee2MQTT a ESPHome
- Vytvoření model objektů – ne kopírování, ale reorganizace struktury pro pohodlí budoucí údržby
- Duplikování automatizací – nová logika se aktivovala až po potvrzení funkčnosti
Tento přístup eliminoval rizika úplného výpadku. Při objevení chyby systém automaticky zůstal na MajorDoMo, což umožnilo vyhnout se nouzovým opravám v nepracovní době.
Taktika přenosu zařízení
Zařízení se migrovala ve skupinách podle funkčního kritéria, ne fyzického umístění. Tato metoda minimalizovala kognitivní zátěž a urychlila lokalizaci problémů:
- Etapa 1: Přenos infrastrukturních komponent (MQTT broker, Zigbee brána)
- Etapa 2: Seskupení podle typů zařízení (osvětlení, klima, bezpečnost)
- Etapa 3: Integrace složitých ekosystémů (Xiaomi s vysavačem, lustr, zvlhčovačem)
Osobní pozornost si vyžádala zařízení Xiaomi – jejich API ukázalo neobvyklé vlastnosti, které si vymohly 30 % času migrace. Pojička pro zvířata, jež se zdála triviální, spotřebovala dva večery kvůli asynchronním upozorněním.
Neočekávaná zlepšení v průběhu
Migrace se stala katalyzátorem pro refaktoring zastaralých komponent. Paralelně s přenosem byly provedeny:
- Výměna Tasmota relé za ESPHome s unifikovaným rozhraním
- Zavedení Bluetooth brány pro sběr dat z teplotních senzorů
- Převod Modbus měniče měřičů na nativní podporu
- Zjednodušení rozhraní běžícího řádku přes MAX7219
Tento přístup se ukázal efektivnější než „čistý“ přenos. Odstranění technického dluhu během migrace snížilo dlouhodobé náklady na údržbu, navzdory krátkodobému nárůstu náročnosti.
Výsledky: co se změnilo po přechodu
Subjektivní metriky ukázaly snížení provozních nákladů:
- Skrácení času úprav – z 2 hodin na 15 minut pro typové scénáře
- Zjednodušení přístupů – centralizované řízení práv místo ručního nastavování
- Zvýšení stability – zmizení falešných spuštění díky zjednodušenému modelu objektů
Nicméně osysHome má omezení. Začátečníkům je těžší systém opanovat kvůli absenci typových scénářů. Dokumentace zaostává za vývojem kódu a některé funkce (např. integrace s ThinQ) vyžadují ruční nastavení. Pro autora tyto kompromisy ospravedlňuje snížení kognitivní zátěže.
Co je důležité
- Paralelní spuštění – povinná podmínka pro systémy s nulovou tolerancí k výpadekům
- Seskupování podle funkce urychluje ladění 2–3krát oproti fyzickému seskupení
- Migrace – nejlepší okamžik pro refaktoring zastaralých komponent
- Údržbovost důležitější než funkcionalita pro systémy starší 5 let
- Xiaomi zařízení vyžadují 30% rezervy času kvůli neobvyklým vlastnostem API
Přechod trval dva týdny při večerní práci po 2–3 hodinách. Klíčový výsledek – snížení psychologické bariéry před úpravami scénářů. Pro majitele stabilních MajorDoMo prostředí není migrace nutná, ale při růstu složitosti se postupný přechod ukázal efektivní. Hlavní lekce: volba platformy by měla záviset ne na technických parametrech, ale na dlouhodobé údržbovosti.
— Editorial Team
Zatím žádné komentáře.