7379 Zeichen
Score aktualisiert
100%
Code: 85e663802c644c56b0f22d07b4381b78
Token in Entwicklung nicht aktualisiert
img-Tag in Entwicklung deaktiviert
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:
- Mein LAN-Konfigurationsadapter, den ich als Funk-LAN-Gateway einsetze, liefert
beständig 0 %.
- Gegen 06:00 habe ich die CCU neu gestartet. Während des Boots sendet die CCU
überdurchschnittlich, um aktuelle Daten für alle Geräte zu erhalten.
- Gegen 12:00 habe ich über den HMCompanion sämtliche Geräte vom
LAN-Konfigurationsadapter auf die CCU umgestellt. Wie man sieht, hatte sie danach deutlich
mehr zu tun.
- Gegen 16:00 habe ich angefangen, die Geräte wieder dem LAN-Konfigurationsadapter
zuzuweisen. Dabei habe ich sehr viele Aktoren sehr häufig geschaltet, um aktuelle
RSSI-Werte (Signalstärke) in HMCompanion zu erhalten.
- Ab 20:00 sieht man, dass der Duty Cycle abflacht: Seit meiner Konfigurations-Arie sind
zwei Stunden vergangen und der Duty Cycle der CCU wird langsam wieder zurückgesetzt.
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.
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.
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.
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.
