openHAB Synchronisationsfehler mit CCU3 beheben

Um die CCU3 in openHAB einzubinden installiert man dazu das "Homatic Binding" von Gerhard Riegler. Über dieses Binding werden anschließend alle verfügbaren Geräte als Things erzeugt. Aus denen kann dann entweder per Paper UI oder durch eine .items-Datei die Items (Eigenschaften) erzeugt werden, die weiter genutzt werden sollen.

Aufgabenstellung

Ich steuere das Rauf- und Runterfahren von Rolladen morgens und abends über ein kleines openhab-Programm (rules). Unerwartet fuhren ohne Veränderungen des Gesamtsystems manchmal einige Rolladen nicht mehr rauf oder runter.

Das Ganze erzeugte dann in openHAB-Logfile einen Fehlereintrag in der folgenden Art:

"Error during the execution of startup rule 'Automatische Verschattung der Jalousien': Could not cast NULL to java.lang.Number; line 15, column 28, length 30".

In einem anderen Fall fuhren die Rollläden plötzlich zur Mittagszeit am hellen Tag im Winter herrunter. Hier konnte ich über das Logfile nur feststellen, dass der zugrundeliegende Helligkeitswert für das Runterfahren auf dem Zahelnwert Null stand.

Durch Neustart von openHAB auf einem RASPI konnten die beschriebenen Probleme behoben werden tauchte aber in unregelmäßigen Abständen immer mal wieder auf.

Ursachenforschung

Das fehlerhafte Rauf- und Runterfahren morgens oder abends konnte ich wie folgt eingrenzen:

Bei den Rollandenaktoren ergab eine kurze Prüfung, dass bei der Abfrage des Levels in openHAB (i.d.R. auf Kanal 4 des Rolladenaktors) der Wert NULL in dem betroffenen Rolladen-Item gespeichert war.

Wenn ich manuell den Rolladen anschließend hoch- oder runterfuhr wurde dies in dem betroffenen Item nicht aktualisiert.In der CCU3 wurden alle Rolladenstellungen hingegen korrekt angezeigt. Die Vermutung eines Synchronisierungsfehlers zwischen openHAB und der CCU3 über das Homeatic Binding war geboren.

Das plötzliche Herunterfahren der Rolläden zur Mittageszeit konnte ich auch identifizieren. Ich nutze für die Prüfung, ob die Helligkeit draußen schon so niedrig ist, dass die Rolläden runtergefahren werden sollen eine Mittelwertfunktion aus dem RRD4J-Binding über die letzten 10 Minuten. Dieses greift auf die für dieses Items gespeicherten Daten in der RRD4J-Datenbank zurück. Dort waren allerdings in den letzten 10 Minuten die Werte Null gespeichert worden, da scheinbar keine korrekten Werte mehr von der CCU3 empfangen werden konnten.

Dieses Sachverhalt konnte ich über einen Chart auf dem Habpanel für diese Helligkeitswerte sehen:

Hierbei stellte sich heraus, dass nicht nur Null-Werte vorhanden sondern Werte scheinbar eingefroren waren, d.h. nicht mehr aktualisiert wurden. Dies stärkte die Vermutung, dass es sich um Synchronisationsprobleme zwischen openHAB und der CCU3 handelt.

Lösung

Wer sich das homematic-Binding anschaut wird feststellen, dass hier ein wichtiges Objekt erzeugt wird, welches für den Zugriff auf Systemvariablen, Systemprogramm aber auch die Synchronisation genutzt wwerden kann: GATEWAY-EXTRAS. Nach Erzeugung des Things gibt es ein Item, über dass sich eine manuelle Snchronisation zwischen beiden Systemen starten lässt: RELOAD_ALL_FROM_GATEWAY. Dieses Item kann den Wert ON oder OFF erhalten. Sobald es auf ON steht, werden alle möglichen Items und deren Inhalte mit der CCU3 neu synchronisiert. Dies führt z.B. auch dazu, dass eine auf der CCU3 neu angelegte Systemvariable sofort in openHAB erscheint. Denselben Effekt kann man erzwingen, indem das GATEWAY-EXTRAS-Thing gelöscht und nach Erscheinen in der Inbox von openHAB wieder erzeugt wird.

Warum dieser Dienst zwischendurch ins Stocken gerät, habe ich nicht auflösen können. Stattdessen habe ich ein kleines Programm auf anderen Webseiten gefunden, welches alls paar Minuten (bei mir alle 10 Minutn) zwangsweise die Synchronisation startet.

Hierzu muss zuerst ein Item wie folgt angelegt werden:

Nun kann durch eine kleine Rule in openHAB ein Script zur Synchronisation z.B. alle 5 Minuten gestartet werden.