HomeMatic & RaspberryMatic: Duty Cycle, eine schlummernde GEFAHR und was man tun kann

Man könnte den Duty Cycle als eine schlummernde Gefahr im Hintergrund einer HomeMatic Umgebung bezeichnen. Es gibt verschiedene Auslöser des Problemes und man sollte aus meiner Sicht den Duty Cycle überwachen und bei einem kritischer Wert eine Info aufs Handy versenden. In den meisten Installationen wird es aufgrund der Anzahl der eingesetzten Aktoren oder der Anzahl von Programmen wahrscheinlich nie zu einem Problem kommen. Aber schon ein defekter Aktor oder ein Firmware Update kann es Auslösen. Ich beschreibe in diesem Artikel was Duty Cycle bedeutet, wie man ihn überwachen und melden kann. Weiter zeige ich ein paar Gefahren auf, die zum Problem mit Duty Cycle führen können. Natürlich führe ich auch ein paar Möglichkeiten auf, um den Duty Cycle im Zaum zu halten.

Übertrieben? Ich finde nicht, denn wenn der Duty Cycle mal bei 100% angekommen ist, steht eure komplette Hausautomation, egal ob auf der CCU2 oder RaspberryMatic für eine Stunde still. Das ist auch durch einen Neustart nicht zu beheben und besonders kritisch, wenn ihr mit HomeMatic eine Alarmanlage realisiert habt. Der gesamte  Funkverkehr zwischen Zentrale und allen Aktoren ist für eine Stunde lahmgelegt.

Was bedeutet Duty Cycle? (Quelle eQ-3)

Der Duty Cycle beschreibt eine gesetzlich geregelte Begrenzung der Sendezeit von Geräten im 868 MHz Bereich. Das Ziel dieser Regelung ist es, die Funktion aller im 868 MHz Bereich arbeitenden Geräte zu gewährleisten.

In dem von uns genutzten Frequenzbereich 868 MHz beträgt die maximale Sendezeit eines jeden Gerätes 1 % einer Stunde (36 Sekunden in einer Stunde). Die Geräte dürfen bei Erreichung des 1 %- Limits nicht mehr senden, bis diese zeitliche Begrenzung vorüber ist.)


Im normalen Betrieb wird der Duty Cycle in der Regel nicht erreicht. Dieses kann jedoch in Einzelfällen, bei der Inbetriebnahme oder Erstinstallation eines Systems durch vermehrte und funkintensive Anlernprozesse, der Fall sein. Dies tritt beispielsweise beim Einstellen und Testen des Erfassungsbereiches von angelernten Bewegungsmeldern auf. Eine Überschreitung des Duty Cycle Limits kann sich durch eine temporär fehlende Funktion äußern.

Das geschilderte Verhalten ist darauf zurückzuführen, dass im 868 MHz Bereich keine Dauersender zulässig sind (maximale Sendezeit 36 Sekunden/Std) und daher werden beim Erreichen dieses Limits alle weiteren Sendevorgänge unterbunden. Nehmen Sie eine kurze Funktionsprüfung des Gerätes vor (z.B. durch Entnehmen und Wiedereinsetzen der Batterien). Sollte das Gerät danach noch nicht wieder einsatzbereit sein, ist dies auf die Überschreitung des Duty Cycles zurückzuführen und die Funktion des Gerätes ist nach einer Stunde wieder hergestellt.

Lösungsansatz

Wie kann man die oben beschriebenen Probleme und Auswirkungen durch einen zu hohen Duty Cycle verhindern?

Als Erstes müssen wir eine Möglichkeit finden, den Duty Cycle auszuwerten. Leider bietet weder die Hardware noch die Firmware von HomeMatic diese Funktion von Hause aus. Wenn wir den aktuellen Wert des Duty Cycle kennen, möchte ich eine automatische Alarmierung auf mein Handy bekommen, um über bevorstehende Probleme bzw. einen definierten Schwellwert informiert zu werden.

Abschließend zeige ich dann sowohl ein paar mögliche Ursachen für einen hohen Duty Cycle auf, sowie diverse Möglichkeiten das Problem in den Griff zu bekommen.

Auswertung des aktuellen Duty Cycles

Auf der Suche nach einer Möglichkeit den Duty Cycle auszuwerten bin ich HomeMatic-Forum auf ein Script von Alchy gestoßen. Es gibt dieses Script in zwei Varianten. Zum einen mit dem Einsatz eines TCL-Scriptes.

TCl = (Aussprache englisch tickle oder auch als Abkürzung für Tool command language) ist eine Open-Source-Skriptsprache.

TCL-Skripte müssen per SSH oder FTP auf die CCU oder Raspberry übertragen werden, um diese dann über ein HomeMatic-Skript innerhalb eines HomeMatic Programmes aufzurufen.

Da dieser Artikel auch Anwender ansprechen soll, die damit nicht so vertraut sind, verwende ich die einfachere Version eines HomeMatic-Skriptes. Im Ergebnis sind beide Varianten gleichwertig. Sollte Interesse an der TCL Variante bestehen, schreibt mit bitte einfach eine Mail.

Script und Systemvariablen einrichten

Ich habe das entsprechende Script von Alchy im HomeMatic-Forum gefunden (Danke dafür). Ich verwende dieses Script bei mir auch, habe aber die weitere Verarbeitung angepasst bzw. erweitert.

Nachfolgend beschreibe ich, wie ihr das Ganze in eurem HomeMatic System einbinden könnt.

Voraussetzung CUx-Daemon

Da das Script in einem sehr kurzen Zeit-Intervall aufgerufen wird, empfehle ich das AddOn CUx-Daemon (CUxD) zu verwenden. Es ist die deutlich bessere Methode um Systembefehle aufzurufen. Weil die Methode über „system.exec“ bei so etwas sehr schnell zu Problemen führt. Wie ihr das AddOn CUxD installiert und ein virtuelles Gerät einrichten könnt, habe ich im Artikel „AddOn CUx-Daemon (CUxD) – system.exec ersetzen“ beschrieben. Keine Sorge, das ist recht einfach.

Script zum Auslesen Duty Cycle von allen Interfaces

Ich habe mich entschieden hier das Script einzufügen welches alle Interface in eurer HomeMatic Installation anzeigt und auswertet. Damit ist gemeint, dass neben der HomeMatic Zentrale (CCU2 oder RaspberryMatic) auch die vorhandenen LAN-Gateways ausgewertet werden. Egal ob ihr nur eine CCU2 betreibt oder zusätzlich LAN-Gateways, ist egal. Das Script funktioniert in jedem Fall.

Am besten führt ihr das Script erst einmal unter „Script testen“ aus. Dazu müsst ihr in der WebUI die folgende Funktion aufrufen:

Startseite > Programme und Verknüpfungen > Programme

Am unteren Bildschirmrand findet ihr den Button „Script testen“. Diesen bitte klicken und das Script in das obere Fenster einfügen. Dabei die vorhandene Zeile „Hallo Welt“ löschen bzw. überschreiben. Wenn ihr das Script eingefügt habt, bitte „Ausführen“ klicken. (siehe Screenshot)

Erklärung der Ausgabe

In der ersten Zeile findet ihr die Seriennummern der gefundenen Interface und den aktuellen Duty Cycle. Bei mir ist die erste Seriennummer mein LAN-Gateway mit einem Duty Cycle von 6 und die Zweite meine HomeMatic Zentrale mit RaspberryMatic mit einem Duty Cycle von 12.)


In den nächsten vier Zeilen findet ihr die Namen der Systemvariablen (VariableDC1, VariableDC2, VariableCON1 und VariableCON2), welche angelegt werden müssen, um die entsprechenden Werte zu speichern. Neben dem Wert des jeweiligen Duty Cycles wird ebenfalls der Verbindungsstatus ausgewertet und gespeichert.

Systemvariablen anlegen und im Script anpassen

Script testen“ bitte mit „Schließen“ verlassen.

Wenn ihr die Namen der Variablen so lassen wollt, reicht es die benötigten Systemvariablen anzulegen. Ich habe bei meiner Installation die Namen der Variablen angepasst und die Namen der Gateways eingefügt.

Dazu müsst ihr zuerst über das WebUI Menü: Startseite > Einstellungen > Systemvariable und der Funktion „Neu“ die entsprechenden Variablen mit dem notwendigen Typ anlegen:

Für den Duty Cycle eine Variable vom Typ „Zahl“ mit den Werten 0 bzw. 100 anlegen.

Für den Verbindungsstatus eine Variable vom Typ „Logikwert“ mit den entsprechenden Eintragungen.

Bei Verwendung von weiteren Interfaces (LAN-Gateway) analog die weiteren Variablen anlegen.

Programm erstellen

Nun müsst ihr ein Programm erstellen, welches das oben aufgeführte Script zyklisch durchführt. Dabei solltet ihr es beim Zyklus nicht übertreiben. Es reicht vollkommen aus wenn das Programm alle 5-15 Minuten ausgeführt wird. Die CCU aktualisiert den Wert auch nicht alle paar Sekunden.

Hier ein Screenshot meines Programmes:

Wenn euch der Ausdruck des Programmes und die Übersichtlichkeit gefällt, dann lest den folgenden Artikel: „Dokumentation und Archivierung von Programmen“.

Wenn ihr die Variablen wie im Ursprungs-Script vorhanden, behalten wollt, dann könnt ihr ohne Änderung speichern.

Habt ihr die Variablen jedoch verändert, dann müsst ihr diese in den beiden folgenden Zeilen im Script anpassen bevor ihr speichert.

Ab diesem Zeitpunkt läuft das Programm in dem definierten Zyklus und füllt die angelegten Systemvariablen.

Systemvariablen anzeigen und auswerten

Nachdem wir nun die Werte des Duty Cycles regelmäßig ermitteln, müssen wir eine Möglichkeit schaffen, diese zum einen anzuzeigen, zum anderen zu sammeln, um später einen Trend zu erkennen. Des Weiteren sollte eine Überwachung der Werte mittels Programm erfolgen, um Warnmeldungen aufs Handy zu senden, wenn ein Schwellwert überschritten wird.

Als Erstes lasse ich mir die Werte der Systemvariablen auf dem WebUI Startbildschirm anzeigen:

Automatische Alarmierung bei Schwellwerten

Um mich rechtzeitig informieren zu lassen wenn der Duty Cycle ungewöhnlich stark ansteigt, habe ich für mich einen Schwellwert von 50% festgelegt- Wird dieser erreicht oder überschritten, sende ich mir eine PUSH Nachricht über Telegram  auf mein Handy. Wie das über den CUx-Daemon geht, findet ihr hier.

Hier findet ihr das entsprechende Programm:

Sinnvolle Zusatzfunktion

In dem oben beschriebenen Script wird auch der Verbindungstatus der diversen Interface überprüft und in eine Variable geschrieben. Daher können wir dies auch nutzen uns per PUSH Nachricht über Verbindungsprobleme informieren zu lassen.

Weitergehende Analyse des Duty Cycles

Mit den bisher vorgestellten Möglichkeiten können wir den Duty Cycle im Auge behalten bzw. werden informiert wenn er ungewöhnlich stark ansteigt.

Hier möchte ich euch noch eine Möglichkeit vorstellen, den Duty Cycle im Bedarfsfalle genauer zu analysieren, um einen Grund zu finden, warum er ansteigt.

Dazu müsst ihr als erstes die beiden definierten Systemvariablen mit den Werten für den Duty Cycle auf „protokoliert“ setzen. Dadurch werden die Werte für den Duty Cycle im Zyklus der Programm Durchführung in das Systemprotokoll geschrieben.

ACHTUNG:  Bei einem Zyklus von 5 bis 15 Minuten werden sehr viele Sätze in das Systemprotokoll geschrieben. Daher solltet ihr das Systemprotokoll regelmäßig löschen, nachdem ihr die Daten zur Auswertung exportiert habt.

Auszug aus Systemprotokoll mit gesetztem Filter „DC_“

Wenn ihr die Daten aus HomeMatic exportiert, könnt ihr im Excel entsprechende Grafiken erstellen, welche den Verlauf des Duty Cycles im Laufe eines Tages darstellt. Nachfolgend ein Beispiel:

Man kann dann sehr einfach feststellen wo Spitzen im Duty Cycle existieren und dann nach der Ursache forschen, um entsprechende Maßnahmen zu ergreifen. Was das konkret bedeutet, versuche ich im nachfolgenden Absatz zu beschrieben.

Was ist zu tun um einen erhöhten Duty Cycle zu vermeiden

Wie bereits am Anfang dieses Artikel beschrieben ist der Duty Cycle eine sehr wichtige Komponente für den Funkverkehr innerhalb einer HomeMatic Installation. Die wichtigste Aussage ist, unnötigen Funkverkehr zu vermeiden. Das ist grundsätzlich schon eine sinnvolle Idee, aber in Bezug auf den zur Verfügung stehenden Funkverkehr von gerade einmal 36 Sekunden in einer Stunde, ist das fast schon existenziell für unsere Hausautomation.

Zur Wiederholung: Wenn die 100% erreicht sind, geht eine Stunde lang nichts mehr in eurer Installation!

  • Funkverkehr reduzieren durch die Nutzung von Systemvariablen

Wenn man verstärkt mit Systemvariablen arbeitet, um beispielsweise den Status einer Lampe auszuwerten, verhindert das sehr viel unnötigen „teuren“ Funkverkehr. Der Status wir beim Anschalten der Lampe auf AN und beim Ausschalten der Lampe auf AUS gesetzt werden. Danach kann ich beliebig oft den Status der Systemvariablen abfragen, ohne eine Funkbefehl zu generieren. Diese Abfragen sind „billige“ Befehle, weil sie keinen Funkverkehr generieren und auch sonst die CCU nicht besonders fordern.

  • Funkverkehr reduzieren durch deaktivieren von Bewegungsmeldern

Ich habe in meiner Installation eine Vielzahl von verschiedenen Bewegungsmeldern. Wenn viel Bewegung im Haus ist, wird durch die Bewegungsmelder auch viel Funkverkehr generiert. Dort wo bei Anwesenheit nicht unmittelbar eine Aktion durch einen Bewegungsmelder ausgelöst wird, macht es durchaus Sinn ihn zu deaktivieren. Leider geht das nur mit den HomeMatic IP Bewegungsmelder und dem IP Präsenzmelder. Die HomeMatic Bewegungsmelder können leider nicht deaktiviert werden.




  • Funkstörungen vermeiden

Es ist relativ einfach in einem Programm viele Befehle zur gleichen Zeit abzuschicken. Wenn ich in einem Programm mehrere Befehle an verschiedene Aktoren gleichzeitig sende, kommt es des Öfteren zu Kommunikationsproblemen. Das führt dann zu verstärktem Funkverkehr, um die Befehle an den Aktor zu senden bzw. die für BidCoS übliche Bidirektionale Kommunikation die Status-Rückmeldung des Aktors. Eine Vielzahl dieser Probleme lassen sich einfach vermeiden, indem man die Befehle ein wenig entzerrt. Das heißt wenn ich mehrere Befehle in einem Programm an viele Aktoren senden will, dann am besten  um 1 bis 2 Sekunden zeitversetzt.

  • Direkte Verknüpfungen verwenden

Über eine direkte Verknüpfung bzw. eine virtuelle Fernbedienung können sehr umfangreiche Programme nicht nur deutlich schneller ausgeführt werden können, sondern auch in hohem Maße Funkverkehr reduziert werden. Die Einrichtung ist sicherlich deutlich aufwendiger, aber der Aufwand lohnt sich auf jeden Fall. Die Aktoren kommunizieren direkt miteinander, ohne CCU2 zu belasten. Ja es funktioniert sogar wenn die CCU nicht verfügbar ist. Als Beispiel führe ich hier mal ein Programm auf, welches über eine Fernbedienung alle Lampen im Haus ausschalten soll. Da kommt mit den Rückmeldungen eine Vielzahl von Funkverkehr zustande.

  • Programme in Abhängigkeit vom Duty Cycle ausführen

Da wir ja durch die in diesem Artikel beschriebene Auswertung des Duty Cycle eine neue Systemvariable erstellt haben, sind wir auch in der Lage diesen Wert in Programmen als Durchführungsbedingung abzufragen. So wäre es beispielweise möglich bei Überschreitung des Schwellwertes Programme wie die Status Überprüfung von Licht oder Rollläden auszusetzen bis der Duty Cycle wieder gesunken ist. Aktuell habe ich bei mir ein entsprechendes Beispiel. Waschmaschine und Trockner hängen an einer Schaltsteckdose mit Leistungsmessung. Damit kann ich über einen MP3 Gong eine entsprechende Information ausgeben, wenn eine dieser beiden Maschinen fertig ist. Beim Trockner wiederholt sich diese Ansage aufgrund des Knitterschutzes eine Stunde lang alle 2 Minuten. Als wir mal außer Haus waren, hat diese vermeintlich kleine Aktion hat meinen Duty Cycle sehr schnell auf über 90% gesteigert. Ursache: Meldung von Steckdose an Zentrale. Von dort an MP3 Gong im Minutentakt. Ich habe daraufhin im entsprechenden Programm eine Abfrage des Duty Cycles eingebaut und wenn der über 50% liegt, wird diese Aktion nicht mehr ausgeführt. Eine weitere Option wäre gewesen das Programm bei Abwesenheit nicht zu starten.

  • LAN-Gateway

Die effektivste Möglichkeit den Duty Cycle zu reduzieren ist natürlich die Installation eines LAN-Gateways. Das hat zum einen den Vorteil, dass es bei großen Objekten oder schwierigen Funk-Bedingungen zu deutlich weniger Kommunikationsproblemen kommt. Ein noch viel wichtiger Faktor in Bezug auf den Duty Cycle ist jedoch die Tatsache, dass die Aktoren so auf die CCU und ein oder maximal drei LAN-Gateways aufgeteilt werden können. Somit kann der Funkverkehr der CCU reduziert und auf ein LAN-Gateway übertragen werden. Ich habe das bei mir auch gemacht und so die Duty Cycles beider Interface auf ungefähr den gleichen  Wert gebracht. Das kann man dynamisch jederzeit verändern und die Auswirkungen prüfen.

Passende Beiträge


3 Comments

  • Jens

    26. August 2017

    Hallo, was kann das sein wenn bei mir unter Script testen nichts angezeigt wird?
    Ich habe das Script kopiert und eingefügt.
    Nutzen tu ich RaspberryMatic in der neuesten Version.
    Gruss

    Reply
    • Werner

      26. August 2017

      Hallo Jens,
      ich habe gerade nochmal das Script aus dem Beitrag kopiert und ausgeführt. Ich nutze ebenfalls RaspberryMatic und es funktioniert wie beschrieben.
      Schreib mir eine Mail mit Screenshots. Vielleicht können wir dann gemeinsam die Ursache finden.
      Werner

      Reply
  • Mathias

    23. August 2017

    Danke für den hilfreichen Beitrag.
    Da ich durch meine BW den Dutycycle nicht in den Griff bekam, liegt er nun bei max 10 Prozent, egal was ich zuhause anstelle. Ok, wenn ich Geräre umkonfiguriere oder anlerne, kann er schon mal auf 100 Prozent steigen. Das ist aber meines erachtens aber systembedingt, weil die CCU dann viele Daten senden muß.

    Reply

Schreibe einen Kommentar