Irgendwann steht es an: Der Visualisierungsserver wird abgekündigt, ein Logikmodul erreicht das Ende seiner Unterstützung, oder der Kunde will von einer gewachsenen Bastellösung auf etwas Wartbares wechseln. Dann stellt sich die Frage, wie die über Jahre entstandene Logik mitkommt.
Die unbequeme Antwort vorweg: Logik lässt sich in der Regel nicht übertragen, sondern nur nachbauen. Jedes System hat eigene Bausteine, eigene Semantik und eigene Grenzen. Was in einem grafischen Editor drei Blöcke sind, kann im anderen ein Skript sein.
Was vor der Migration geklärt sein muss
1. Was macht die Anlage überhaupt?
Die entscheidende Frage und die, die am häufigsten unbeantwortet ist. Wenn niemand aufgeschrieben hat, welche Automatik existiert, ist die Migration eine Rekonstruktion – und die kostet ein Vielfaches.
Gehen Sie durch die vorhandene Konfiguration und schreiben Sie die Funktionen in Sätzen auf, nicht als Blockdiagramm: „Wenn die Außenhelligkeit über 40 kLux steigt und im Wohnzimmer seit zehn Minuten niemand ist, fährt die Beschattung auf 70 Prozent." Diese Sätze sind das eigentliche Migrationsdokument.
2. Was davon wird noch gebraucht?
Bei gewachsenen Anlagen ist ein erheblicher Teil der Logik tot: Funktionen für Geräte, die es nicht mehr gibt, Testkonstrukte, doppelte Automatiken. Eine Migration ist die beste Gelegenheit, das auszusortieren.
Fragen Sie den Kunden konkret nach jeder Funktion: „Nutzen Sie das?" Die Antwort ist überraschend oft nein.
3. Was gehört gar nicht auf den Server?
Bei der Gelegenheit lässt sich ein Strukturfehler korrigieren, der in vielen Anlagen steckt: Grundfunktionen und Sicherheitsfunktionen auf einem Server, der ausfallen kann.
Windschutz, Frostschutz, Verriegelungen und die Grundbedienung gehören in Geräte oder ein Logikmodul – nicht in ein System, das man aktualisiert. Was auf den Server gehört: Komfort, Visualisierung, Anbindung nach außen, alles mit Kalender- oder Wetterdatenbezug.
Der Ablauf, der sich bewährt hat
1. Bestandsaufnahme und Sicherung. Alte Konfiguration exportieren, ETS-Projekt sichern, Screenshots der Visualisierung. Mehrfach, an getrennten Orten.
2. Funktionsliste schreiben. Aus der alten Konfiguration, in Sätzen. Mit dem Kunden durchgehen und streichen, was nicht mehr gebraucht wird.
3. Aufteilung neu festlegen. Was ins Gerät, was ins Logikmodul, was auf den Server. Dazu unser Beitrag zu KNX-Logikmodulen.
4. Neuen Server aufbauen, parallel. Noch ohne Schreibzugriff auf den Bus – erst mitlesen, dann schrittweise übernehmen.
5. Funktionsweise Stück für Stück umschalten. Nicht alles an einem Tag. Beleuchtung zuerst, Beschattung danach, Heizung zuletzt.
6. Alten Server erst abschalten, wenn eine Woche störungsfrei lief. Und ihn nicht sofort ausbauen.
7. Dokumentation aktualisieren. Sonst beginnt der nächste Wechsel wieder bei Schritt eins.
Was das kostet – und warum es sich lohnt, das vorher zu sagen
Eine Migration ist selten günstiger als ein Neuaufbau der Logik. Der Aufwand steckt nicht im Umsetzen, sondern im Verstehen: Was tut die Anlage, warum, und was davon ist gewollt?
Bei einer Anlage mit fünfzehn bis zwanzig Automatikfunktionen sind zwei bis vier Tage realistisch, wenn Dokumentation vorliegt. Ohne Dokumentation eher das Doppelte.
Das gehört vor dem Angebot gesagt, nicht danach. Kunden erwarten häufig, dass „einfach übertragen" wird – wenn man erklärt, warum das nicht geht, ist die Zahl nachvollziehbar.
Die Gelegenheit nutzen
Eine Migration ist der einzige Moment, in dem ein Kunde bereit ist, für Aufräumen zu bezahlen. Nutzen Sie ihn:
- Adressstruktur bereinigen, wo es ohne Neuprogrammierung aller Geräte geht
- Unbenutzte Gruppenadressen entfernen
- Benennung vervollständigen
- Dokumentation neu erstellen
- Sicherheitsfunktionen aus dem Server herausnehmen
Danach ist die Anlage nicht nur auf einem neuen Server, sondern in einem Zustand, in dem der nächste Wechsel halb so aufwendig wird.
