6774 Zeichen
Score aktualisiert
100%
Code: 48d4e8ec4e7347a28ad27430e7150682
Token in Entwicklung nicht aktualisiert
img-Tag in Entwicklung deaktiviert
Die CCU, insbesondere die CCU 2, ist sehr stabil und kann über Monate oder gar Jahre
ohne Neustart arbeiten, sofern kein Firmware-Update oder die Installation von
Zusatzsoftware stattfindet.
Manche Programmaktionen neigen dazu, die CCU instabil werden zu lassen: Die Zentrale
reagiert langsam auf Ereignisse und führt Programme verzögert aus oder reagiert im
schlimmsten Fall gar nicht mehr.
Die hier vorgestellten Scripte können dazu führen, dass die CCU sich nicht mehr
bedienen lässt und nicht mehr von Ihnen in einen funktionsfähigen Zustand versetzt
werden kann.
Bitte betrachten Sie diese Seite daher als Informationsangebot.
Alles, was Sie aufgrund meiner Informationen tun, erfolgt auf eigene Gefahr!
Strings in HomeMatic-Scripten
Durch String-Verwendung in HomeMatic-Scripten kann die CCU fehlerhaft arbeiten,
instabil werden oder sogar abstürzen. Grundsätzlich gilt: Je öfter mit Strings
hantiert wird, desto eher führt dies zu Problemen.
Ich empfehle daher, nach Umsetzung dieser Anleitung die CCU unter Beobachtung
zu halten.
system.Exec();
Wenn system.Exec() verwendet wird, um aus HomeMatic-Scripten heraus
Systemfunktionen auf der CCU zu starten, kann dies zu Fehlfunktionen der CCU
führen, die einen Neustart erforderlich machen. Außerdem „hängt“ die CCU, solange
externe Befehle ausgeführt werden.
Installieren Sie den
CUx-Daemon,
dessen Exec-Funktion für diese Probleme weniger anfällig ist.
Gründe für Abstürze
Die folgenden Aktionen sind bekannte Kandidaten dafür, die HomeMatic abstürzen zu
lassen.
Mit system.Exec() können in HomeMatic-Scripten beliebige Programme des
CCU-Betriebssystems ausgeführt werden, zum Beispiel etherwake oder der E-Mail-Versand.
system.Exec() in Scripten kann dazu führen, dass die Logikschicht der CCU sich
aufhängt und die Zentrale nicht mehr reagiert. Oft ist das erste Symptom, dass die mit system.Exec()
aufgerufenen Befehle nicht mehr ausgeführt werden, auch wenn anderes noch funktioniert.
Der Befehl sollte stets mit folgenden Parametern ausgeführt werden, damit Textausgaben
des aufgerufenen Befehls nicht zu Buffer Overflows führen:
gesamtes Script markieren / kopieren
string stdout;
string stderr;
system.Exec (" ... ", &stdout, &stderr);
Auch sollte darauf geachtet werden, dass die Ausführungszeit der aufgerufenen Befehle
nicht zu lang ist und system.Exec() nicht mehrmals gleichzeitig gestartet wird.
Die Alternative ist die Installation des CUx-Daemons, der system.Exec()
ersetzt und erweitert – neben allerlei weiteren Funktionen.
Wird in Scripten viel mit Zeichenketten gearbeitet, also Zeichenketten immer wieder
ersetzt oder ergänzt, kann dies ebenfalls zum Absturz der Logikschicht führen: Die CCU
reagiert nicht mehr.
Auch Add-ons können die CCU negativ beeinflussen – sei es durch Programmierfehler im
Add-on oder einfach dadurch, dass die CCU mit Zusatzsoftware unter Umständen stärker
belastet wird.
Man sollte darauf achten, Add-ons nur aus vertrauenswürdiger Quelle zu installieren.
Bei Problemen kann man sie versuchsweise wieder deinstallieren, um sie als Fehlerquelle
auszuschließen.
Diese Beschreibungen klingen schlimm, aber selbst bei der CCU 1 geht es hier eher um
Monate als um Wochen, bis die Zentrale mal abstürzt. Add-ons, die die CCU zum Absturz
bringen, hatte ich noch nie.
Die CCU 2 ist in dieser Hinsicht sogar noch stabiler: Es ist wirklich die Ausnahme,
dass die Zentrale außerhalb der regelmäßigen Neustarts bei Firmware-Updates neu
gestartet werden muss. Und das schreibe ich als jemand, der die Logikschicht mit seinem
Gefummel durchaus belastet und neue Firmware nicht immer zeitnah installiert …
Der sichere Weg
WebUI-Programme bergen stets die Gefahr, nicht wie erwartet ausgeführt zu werden.
Wenn Sie sich an der Kommandozeile (Shell) Ihrer CCU anmelden können, dann können Sie
auch darüber einen Reboot durchführen. Geben Sie einfach reboot oder /sbin/reboot
ein und die CCU startet neu.
Über einen Shell-Zugang kann man auch viel kaputtmachen – dies ist also nur eine
Option für erfahrenere Nutzer.
Schließlich kann man die CCU über einen Scriptbefehl neustarten, den man natürlich
auch über den Script-Parser absenden
kann.
Neustart per Scriptbefehl
Ein Neustart der CCU kann angestoßen werden, indem der Systembefehl reboot
ausgeführt wird – ironischerweise über system.Exec().
gesamtes Script markieren / kopieren
string stdout;
string stderr;
system.Exec ("/sbin/reboot", &stdout, &stderr);
Wenn die CCU noch irgendwie reagieren kann, startet sie nach diesem Befehl sofort neu.
Dies ist daher die richtige Lösung für einen „Notfallknopf“: Mit einem
einfachen WebUI-Programm, das z. B. mit der Taste einer Fernbedienung verknüpft ist, kann
die CCU neugestartet werden. Aber Vorsicht – es gibt keinerlei Rückfrage. Wer den Knopf
drückt, startet die CCU neu.
Wer genau hinsieht, der erkennt, dass ich in diesem Programm nur eine E-Mail
verschicke, aber keinen Neustart durchführe: Das Risiko, versehentlich den Knopf zu
drücken, ist größer als das Risiko, dass ich die CCU nicht mehr über QuickAccess
„einfangen“ kann“.
WebUI-Programm
Bei der Programmierung eines Neustart-Programms über die WebUI unbedingt an die
automatische Programmauslösung denken, die beim ersten Speichern des Programms sowie beim
Boot der CCU erfolgt.
Bevor das Neustart-Script in ein WebUI-Programm eingefügt wird, unbedingt prüfen, ob
es auch wirklich nur nach ausdrücklichem Befehl ausgeführt wird. Es besteht die Gefahr,
dass die CCU in einer Endlos-Schleife landet und sich immer wieder neustartet!
Einige Beispiele dafür, wann ein Programm automatisch getriggert wird, werden auf der
Seite Die Logik von WebUI-Programmen
erklärt. Es ist sinnvoll, im „Neustart“-Programm zunächst ungefährliche
Aktionen auslösen zu lassen, z. B. das Licht kurz einzuschalten oder eine E-Mail zu
versenden.
Erst wenn Sie absolut sicher sind, dass das Programm niemals ungewollt ausgeführt
wird, sollten Sie die Scriptbefehle zum Neustart einfügen.
Konfiguration sichern
Die Daten der Logikschicht, also Programme, Systemvariablen usw., werden auf
verschiedenen Ebenen zwischengespeichert. Die unterste Ebene ist das Dateisystem: Erst,
wenn die Konfiguration dort vollständig geschrieben wurde, bleibt sie bei einem Neustart
erhalten.
Über den Neustart-Befehl wird die CCU neu gestartet, ohne vorher die Konfigration zu
sichern. Wenn es darum geht, eine abgestürzte CCU wieder zum Leben zu erwecken, ist dies
genau richtig, denn das Speichern der Konfiguration im Dateisystem erfolgt selbst über
die Logikschicht – und wenn die gerade stirbt, könnte der Speichervorgang ihr den Rest
geben.
Wird dagegen ein geplanter Neustart durchgeführt, sollte man die Konfiguration vorher
mit system.Save() sichern. Das Neustart-Script sieht dann so aus:
gesamtes Script markieren / kopieren
string stdout;
string stderr;
system.Save();
system.Exec ("/sbin/reboot", &stdout, &stderr);
Die Ausführung von system.Save() kann sehr lange dauern – mindestens einige
Sekunden, bei einer CCU 1 mit vielen Geräten und Programmen sogar mehrere Minuten.
Sie können ausprobieren, wie lang system.Save() auf Ihrer CCU braucht: Melden
Sie sich an der WebUI an, ändern Sie irgendwas und klicken Sie auf „Abmelden“.
Die CCU führt jetzt ein system.Save() aus und zeigt erst danach die Bestätigung
an, dass Sie abgemeldet wurden.
Wenn Sie das system.Save() per Script anstoßen, dann dauert die Ausführung
genauso lange.