Funkbefehle wiederholen

Das BidCoS-Protokoll, über das die CCU mit den angemeldeten Komponenten kommuniziert, ist bidirektional, d.h. der Sender erhält bei Erfolg eine Quittung des Empfängers. Bei Funkstörungen wird die Nachricht wiederholt gesendet. Leider kann man nicht einstellen, mit welcher Frequenz die Aussendung wiederholt wird und wie viele Versuche der Sender unternimmt.

Die Komponenten entscheiden selbst, mit welcher Strategie sie auf Funkstörungen reagieren. Die CCU versucht einige Sekunden zu senden; erhält sie keine Quittung, gibt sie relativ schnell auf und stellt eine Servicemeldung ein („Kommunikation war gestört“). Auch Aktoren wie z. B. Schaltaktoren versuchen nur kurz, ihre Statusänderung an die Zentrale zu senden. Schlägt die Übertragung fehl, gibt es keine Fehlermeldung und die CCU arbeitet mit veralteten Informationen.

Tür-/Fensterkontakte sind da hartnäckiger und versuchen, ihre Statusänderung über längere Zeiträume an den Empfänger zu senden, bis dieser antwortet. Man sieht das daran, dass die LED so lange gelb leuchtet, bis der Versand erfolgreich war oder der Kontakt schließlich doch aufgibt.

Zumindest für die CCU schaffen die Programme auf dieser Seite Abhilfe: Ein Schaltbefehl wird so lange wiederholt, bis der Aktor zurückgemeldet hat, dass er im richtigen Zustand ist.

Systemvariable

Ich gehe wieder den Umweg über eine Systemvariable: Statt einen Aktor direkt zu schalten, wird eine Systemvariable mit dem neuen Wert gesetzt.

Die Systemvariable wird wie immer über die WebUI angelegt („Einstellungen“ / „Systemvariable“ / „Neu“).

Als Beispiel verwende ich diesmal das Programm zur Steuerung meines Rasenmäh-Roboters. Das hat einen durchaus ernsten Hintergrund: Der HM-LC-Sw2-FM, der das Ladegerät schaltet, reagiert sporadisch nicht auf Schaltbefehle. Eine ideale Gelegenheit.

Aktoren schalten

Wenn die Systemvariable gesetzt wird, wird eines von zwei zugehörigen Programmen ausgelöst, die den Aktor schalten, wenn er noch nicht den richtigen Status hat. Anschließend löst sich das Programm mit Verzögerung selbst wieder aus.

Zunächst das Programm zum Einschalten des Aktors. Es wird bei jeder Aktualisierung der Variablen ausgelöst, also auch dann, wenn sie bereits auf „ein“ steht und noch einmal „ein“ gesetzt wird – anders funktioniert es nicht.

Der Aktor wird sofort geschaltet, wenn er noch nicht eingeschaltet ist. 15 Sekunden später wird die Systemvariable wieder gesetzt, die das Programm erneut auslöst. Hat der Aktor auf den vorherigen Schaltbefehl reagiert, dann ist sein Status bereits „ein“ und das Programm wird nicht ausgeführt. Gab es einen Fehler, wird erneut versucht zu schalten und 15 Sekunden später das Programm wieder ausgelöst – ad infinitum.

Analog gibt es ein Programm zum Ausschalten des Aktors.

Wichtig ist bei beiden Programmen der Haken bei „Vor dem Ausführen alle laufenden Verzögerungen für diese Aktivitäten beenden“. Wenn das Programm zum Einschalten noch läuft, weil der Aktor nicht erreichbar ist, und die Systemvariable auf „aus“ gestellt wird (oder umgekehrt), kann es sonst passieren, dass die beiden Programme sich abwechselnd immer wieder selbst triggern.

Ebenfalls wichtig: Der Status des Aktors steht auf „nur prüfen“ – sonst würde sich das Programm auch triggern, sobald der Aktor sich meldet. Das können wir hier nicht brauchen.

Anwendung

Die Verwendung der Programme ist trivial: Der Wert der Systemvariablen wird nach Wunsch gesetzt. Fertig.

In diesem Fall wird jeden Tag um 19:30 geprüft, ob es vor kurzem geregnet hat – dafür verwende ich den Langzeit-Timer  – und ob jemand zu Hause ist. Wenn es geregnet hat oder niemand zu Hause ist, wird das Ladegerät ausgeschaltet, anderenfalls ein.