# Heimautomatisierung-Migration: Wechsel von MajorDoMo zu osysHome ohne Ausfälle
Nach acht Jahren mit MajorDoMo als primäre Heimautomatisierungsplattform stieß der Autor an Grenzen durch explodierende Wartungskomplexität. Jede Skriptänderung erforderte eine Kette von Überprüfungen und verwandelte Routineaufgaben in Abendmarathons. Der Wechsel zum selbst entwickelten osysHome war pure Notwendigkeit – um die kognitive Belastung beim Systemmanagement zu senken. Dieser Artikel zerlegt einen schrittweisen Plan für eine Migration ohne Ausfälle, zentrale Fallstricke und Taktiken, die für jede große Automatisierungsanlage gelten.
Warum MajorDoMo nicht mehr ausreichte
Was als Testumgebung begann, entwickelte sich über acht Jahre zu einem missionstragenden Infrastrukturelement. Die Objektanzahl erreichte 200, von physischen Sensoren über virtuelle Entitäten bis hin zu Hilfslogiken. Die Kernprobleme waren systemisch:
- Langsamere Automatisierungsreaktionen – Hintergrundprozesse konkurrierten um Ressourcen
- Datenfragmentierung – schwierig, Verbindungen zwischen Objekten nachzuverfolgen
- Undurchsichtige Berechtigungen – manuelle Rechtevergabe für jedes neue Skript
- Zerbrechliche Skripte – jede Änderung verlangte Abhängigkeitsprüfungen
Der Knackpunkt war die Falle des „kleinen Tweaks“: Eine 10-Minuten-Aufgabe blähte sich routinemäßig zu Stunden des Debuggings auf. Bei Systemen dieser Größe überlagerten Wartungsprobleme das Hinzufügen neuer Features.
Strategie des parallelen Starts
Der größte Migrationsfehler? Der Versuch eines „Big Bang“-Wechsels. Stattdessen führten wir eine schrittweise Übergabe durch, bei der alles in jedem Schritt weiterlief:
- Isolierter osysHome-Start – Installation neben MajorDoMo auf derselben Hardware (SOYO M4 AIR N95 16GB+512GB auf Ubuntu Server 25.10)
- Integrationsprüfung – praktische Tests der Gerätesteuerung via MQTT, Zigbee2MQTT und ESPHome
- Objektmodell-Neubau – nicht Kopieren, sondern Umstrukturieren für einfachere Langzeitwartung
- Automatisierungsduplizierung – neue Logik ging nur live, nachdem sie bestätigt funktionierte
Das eliminierte Risiken vollständiger Ausfälle. Problem entdeckt? Das System fiel automatisch auf MajorDoMo zurück und sparte nächtliche Brandbekämpfung.
Taktiken für die Geräte-Migration
Geräte wanderten in funktionalen Gruppen, nicht nach physischer Lage. Das reduzierte den mentalen Aufwand und beschleunigte das Troubleshooting:
- Phase 1: Kerninfrastruktur (MQTT-Broker, Zigbee-Gateway)
- Phase 2: Nach Gerätetyp (Beleuchtung, Klima, Sicherheit)
- Phase 3: Komplexe Ökosysteme (Xiaomi mit Staubsauger, Kronleuchter, Befeuchter)
Xiaomi-Geräte waren ein Albtraum – ihre API hatte Eigenarten, die 30 % der Migrationszeit fraßen. Sogar der Tiertränker, der unkompliziert wirkte, kostete zwei Abende wegen asynchroner Benachrichtigungen.
Unerwartete Erfolge unterwegs
Die Migration löste eine Refaktorung veralteter Teile aus. Parallel dazu:
- Ersetzten wir Tasmota-Relais durch ESPHome mit einheitlicher Oberfläche
- Fügten ein Bluetooth-Gateway für Temperatursensordaten hinzu
- Konvertierten Modbus-Zähleradapter zu nativer Unterstützung
- Optimierten die Scroll-Ticker-Anzeige via MAX7219
Das übertraf einen reinen Port. Die Tilgung technischer Schulden während der Migration senkte Langzeit-Supportkosten, auch wenn es kurzfristig mehr Aufwand bedeutete.
Die Nachwirkungen: Was sich nach dem Wechsel änderte
Persönliche Metriken zeigten sinkende Betriebskosten:
- Bearbeitungszeit halbiert – von 2 Stunden auf 15 Minuten für Standardskripte
- Vereinfachte Berechtigungen – zentrale Rechteverwaltung statt manueller Anpassungen
- Erhöhte Stabilität – keine Fehltrigger mehr dank sauberem Objektmodell
Allerdings hat osysHome Grenzen. Neulinge kämpfen ohne fertige Skripte. Die Dokumentation hinkt dem Code hinterher, und einige Features (wie ThinQ-Integration) erfordern manuelle Einrichtung. Für den Autor überwiegen die Vorteile durch reduzierte mentale Belastung.
Wichtige Erkenntnisse
- Parallele Läufe sind unverzichtbar für Systeme ohne Ausfälle
- Funktionale Gruppierung beschleunigt Debugging um das 2–3-Fache gegenüber physischen Layouts
- Migration ist ideale Zeit für Refactoring von Legacy-Komponenten
- Wartbarkeit geht vor Features bei Systemen über 5 Jahre
- 30 % Mehrzeit für Xiaomi-Geräte einplanen wegen API-Eigenarten
Der Wechsel dauerte zwei Wochen bei 2–3 Stunden pro Abend. Großer Gewinn: Kein Grauen mehr vor Skriptänderungen. Stabile MajorDoMo-Setups brauchen das nicht, aber bei wachsender Komplexität lohnt ein schrittweiser Wechsel. Hauptlehre: Plattformen nach Langzeitwartbarkeit wählen, nicht nach Specs.
— Editorial Team
Noch keine Kommentare.