Kommunikationsstörungen durch Duty Cycle

Ein Bugfix in Firmware 2.17.x sorgt für Verdruss

In der Firmware-Version 2.17.x hat eQ-3 einen Fehler bei der Duty-Cycle-Überwachung behoben – was dazu führt, dass reihenweise CCUs nach dem Update für sämtliche Geräte Kommunikationsstörungen gemeldet haben.

Nachdem ich gerade in diese Falle gelaufen bin, hier einige Infos.

Benennung von Systemvariablen

Prinzipiell kann man Systemvariablen – so wie allen Objekten in der CCU – beliebige Namen geben, also z. B. auch Umlaute und Sonderzeichen verwenden. Ich empfehle jedoch, sich auf reguläre Buchstaben (a-z, A-Z) zu beschränken: Bei Umlauten und Sonderzeichen besteht die Gefahr, dass Systemvariablen in Scripten nicht überall gefunden werden.

Was ist der Duty Cycle?

Der Gesetzgeber schreibt vor, dass Geräte im 868-MHz-Band pro Stunde maximal 1 % der Zeit senden dürfen. Ist diese Sendedauer erreicht, müssen sie pausieren, bis die 1 % wieder unterschritten sind.

Da die HomeMatic in diesem Frequenzband arbeitet und insbesondere bei Installation und Konfiguration von Geräten manchmal viel senden muss, kann es dazu kommen, dass sie den Sendebetrieb für eine Stunde einstellt.

Tatsächlich ist der Duty Cycle ein Wert zwischen 0 und 100 %: Wenn die CCU 18 Sekunden lang sendet (= 0,5 % einer Stunde), dann hat sie 50 % ihres „Duty Cycles“ erreicht.

Die folgende Grafik zeigt den Duty Cycle für einen Tag meiner CCU, an dem ich einiges an der Konfiguration getestet habe.

Einige Höhepunkte:

Insgesamt sieht man, dass selbst bei meiner relativ großen Installation im Normalbetrieb die CCU fast immer deutlich unter 20 % bleibt. Selbst bei wilder Aktivität kommt sie nicht über 40 % hinaus. Wer also Probeme mit dem Duty Cycle hat, der sollte überprüfen, ob es irgendwo Probleme mit einem Programm oder mit Komponenten des Systems gibt.

Was passiert bei 100 %?

Ganz einfach: Die CCU sendet nicht mehr. Die komplette HomeMatic steht. Was noch funktioniert, sind direkte Verknüpfungen zwischen Geräten (aber nicht mit virtuellen Geräten) und natürlich die Bedienung über Gerätetaster.

Erschwerend kommt hinzu, dass die CCU auch keine Quittierung sendet. Wenn also ein Tür-/Fensterkontakt seinen neuen Status abliefern möchte, dann empfängt die CCU diese Botschaft zwar wahrscheinlich, sendet aber keine Bestätigung. Der Kontakt wird weiter mit seiner gelben LED und seinen Sendeversuchen die Batterie belasten. Schon toll, so ein Duty Cycle.

Besonders ärgerlich in meinem Fall: Nach dem Update startete die CCU mit einem Duty Cycle von 100 %, ohne überhaupt etwas gesendet zu haben. Da ging also von der ersten Sekunde des Neustarts an gar nichts mehr und für sämtliche Geräte wurden Kommunikationsstörungen angezeigt. Nach zwei Stunden beruhigte sich die Lage langsam wieder, aber wenn nach einem Software-Update nichts mehr funktioniert, ist das kein schönes Erlebnis.

Wo wird der Duty Cycle angezeigt?

Eine offensichtliche Anzeige gibt es nicht: Die CCU hört einfach auf, zu senden. In den Servicemeldungen steht für jedes Gerät, das in dieser Zeit angesprochen wurde, eine Kommunikationsstörung. Je mehr Programme versuchen, Befehle abzusenden, desto mehr Kommunikationsstörungen gibt es.

Man kann die Servicemeldungen etwas reduzieren, wenn man die „Kommunikation war gestört“-Meldungen automatisch bestätigen lässt, aber die Servicemeldungen werden sich bei einer größeren Installation dennoch sehr schnell füllen.

Über ein Script kann man den aktuellen Wert des „Duty Cycles“ für die CCU und verbundene LAN-Adapter abfragen. Hierfür wird sinnvollerweise der CUx-Daemon benötigt – ich habe es daher in den CUxD-Bereich einsortiert.

Was kann ich tun?

Man muss möglichst viel Funkverkehr der CCU vermeiden. Das ist ja grundsätzlich eine gute Idee, da Funkbefehle zu den „teuren“ Aktionen auf der CCU gehören, aber dank des „Duty Cycles“ wird es lebenswichtig.

Weitere Tipps:

Überflüssige Kommunikation vermeiden

Es ist bequem, einfach Befehle über Programme rauszukloppen, ohne groß darüber nachzudenken. Es ist aber sinnlos, einem bereits eingeschalteten Aktor einen weiteren Einschaltbefehl zu senden. Diese Art von Befehlen kann man vermeiden, indem man in Programmen den aktuellen Status seiner Aktoren prüft und wirklich nur dann sendet, wenn es auch eine Statusänderung gibt.

Bei zyklischen Aktivitäten kann man überlegen, die Frequenz zu reduzieren. Beispiel „Kommunikation gestört“: Wenn man nicht alle 5 Minuten versucht, tote Geräte wiederzufinden, sondern alle 20 Minuten, dann erzeugt das entsprechende Programm nur noch ein Viertel seines Kommunikationsaufkommens.

Funkstörungen vermeiden

Jede Kommunikationsstörung führt zur Wiederhoung von Sendungen. Daher sind alle Maßnahmen, die Störungen vermeiden, auch für den Duty Cycle sinnvoll – zum Beispiel das Entzerren von Schaltbefehlen.

Wiederholungen vermeiden

Einige meiner Tipps gegen Funkstörungen sorgen für erhöhten Datenverkehr, zum Beispiel die Übertragung von Einschaltdauern oder die Totmann-Schaltung. Klingt so, als sollte man besser darauf verzichten – oder gerade deshalb nicht, denn ein Gerät ohne Totmann-Schaltung läuft womöglich unkontrolliert weiter, wenn der Duty Cycle zuschlägt.

Die von mir beschriebene reine Wiederholung von Schaltbefehlen ist übrigens kein Problem – im Gegenteil: Es wird nur wiederholt, wenn der erste Befehl nicht ankam. Das gilt auch für Befehle, die wegen Duty Cycle versacken. Ich habe hier also gleich meinen ersten Tipp befolgt und sende nur, wenn es nötig ist.

Direkte Verknüpfungen nutzen

Über eine virtuelle Fernbedienung werden umfangreiche Programme nicht nur schneller ausgeführt, sondern es werden auch massig Datenübertragungen gespart. Auch wenn die Einrichtung mehr Arbeit ist – es lohnt sich oft.

Funk-LAN-Gateway oder Repeater nutzen

Wenn es zu Duty-Cycle-Problemen kommt und man die Möglichkeit dazu hat, sollte man ein Funk-LAN-Gateway bzw. den LAN-Konfigurationsadapter nutzen – das gilt natürlich auch bei Kommunikationsstörungen aus anderen Gründen. Wenn man seine Geräte auf die CCU und ein (oder mehrere) Funk-LAN-Gateway(s) verteilt, dann verteilt sich auch die Kommunikationslast.

Ein Repeater ist die schlechtere Möglichkeit, da die CCU in diesem Fall immer noch jeden Befehl erst einmal selbst senden muss. Der einzige Vorteil besteht darin, dass der Repeater möglicherweise für Aktoren zuverlässiger erreichbar ist als die CCU und diese keine Befehlswiederholungen senden muss, weil alle Geräte auf Anhieb erreicht werden.

Programme priorisieren

Speichert man den Duty Cycle in einer Systemvariablen, kann man diese in seinen Programmen zusätzlich prüfen und bei Überschreitung eines Grenzwertes die Ausführung aussetzen. Beispielsweise könnte man die Prüfung des Lichtstatus unterbinden, wenn der Duty Cycle über 50 % liegt, um die Kommunikation auf das Wesentliche zu reduzieren.

Verwendet man ein Script zur regelmäßigen Aktualisierung einer Systemvariablen, die den Duty Cycle anzeigt, kann man diese Variable sogar direkt als Systemtakt verwenden.

Navigation