Blog Obsolet

HomeMatic – Defektes Gerät finden (Duty Cycle)

Duty Cycle

Letzte Aktualisierung am 1. Juli 2023

Dieser Beitrag ist obsolet, da es – z.B. mit dem ELV Funk-Analyser EQ3-RFA oder dem AskSin Analyzer – zwischenzeitlich pragmatischere Lösungen gibt. Er wird nicht mehr aktualisiert. Das beschriebene Verfahren funktioniert aber möglicherweise nach wie vor. Die Kommentare wurden geschlossen.

Ein defektes HomeMatic Gerät hatte kürzlich mein System so stark beeinflusst, dass sich die CCU regelmäßig ca. jede Stunde neu gestartet hat. Es war nicht ganz einfach, den Fehler zu lokalsieren. Nachfolgend – als Anregung für die eigene Fehlersuche bei ähnlich gelagerten Fällen – eine Zusammenfassung, wie ich letztendlich Erfolg hatte.


Hintergrund:

Mit Veröffentlichung der CCU2 Firmware in der Version 2.17 (ich glaube, diese Version war es) wurde eine gesetzliche Vorgabe umgesetzt, um die Sendezeit von Geräten im 868 MHz Bereich zu begrenzen.

Gemäß dieser Regelung beträgt die maximale Sendezeit jedes Gerätes – der Duty Cycle – 1 % einer Stunde, was 36 Sekunden entspricht. Wird die Sendedauer überschritten, darf das betreffende Gerät temporär nicht mehr senden. Dies gilt in HomeMatic nicht nur für die CCU sondern für jedes RF-Gerät. Aufgrund der zentralen Rolle ist der Duty Cycle bei CCU und LAN-Adaptern von besonderer Bedeutung, insbesondere, wenn Programme im Hinblick auf das Sendeaufkommen „ungünstig“ programmiert sind.

In älteren CCU2 Fimware Versionen fand die gesetzliche Vorgabe anscheinend keine wirkliche Berücksichtigung, wodurch der Duty Cycle in der Praxis eine eher untergeordnete Bedeutung hatte. In den neueren Versionen sollte man ihn aber im Auge behalten.

Dies kann z.B. dadurch geschehen, indem der Duty Cycle in eine Systemvariable geschrieben wird. Anleitungen dazu findet man im HomeMatic-Forum in Versionen mit TCL-Skript oder ohne TCL. Mit beiden Lösungen erhält man eine prozentuale Angabe über den „verbrauchten Duty Cycle“.

Mit Beginn meiner Aufzeichnung des Duty Cycles bemerkte ich, dass der Wert der CCU häufig bei ca. 50 % lag und damit ungewöhlich hoch war…

Duty Cycle

Ich hatte mir daher vorgenommen, gelegentlich mal auf die Suche zu gehen, welches Gerät möglicherweise dafür verantwortlich ist, dies aus Zeitgründen aber immer wieder verschoben. Der Wert des LAN-Adapters lag regelmäßig bei unter 10 %.

Nachdem das System trotz vergleichsweise hohem Duty Cycle über ein Jahr unauffällig funktionerte, starte sich die CCU eines nachts plötzlich jede Stunde neu. Auffällig war am nächsten Morgen, dass alle Geräte, die der CCU zugeordnet sind, nicht mehr ansprechbar waren, die dem LAN-Adapter zugeordneten Geräte jedoch schon.

Darauf hin lag ein Problem mit dem Duty Cycle der CCU nahe und ich sah mir dessen Verlauf in der besagten Nacht im CCU-Historian etwas genauer an…

Duty Cycle

Um ca. 2:00 Uhr stieg der Duty Cycle nach dem üblichen Absinken in der Nacht plözlich signifikant an. Die CCU hörte auf zu senden, weswegen logischerweise auch der Hardware-Watchdog keinen Impuls mehr bekam und die CCU nach einiger Zeit neu startete. Das Ganze wiederholte sich ca. jede Stunde.

Soweit so gut, nur welches Gerät war dafür verantwortlich?

Um dieser Frage näher zu kommen, kontrollierte ich den Funkverkehr im 868 MHz Bereich mit Hilfe eines RTL2832U DVB-T Sticks…

Duty Cycle

…und der „Software Defined Radio“-Software SDR#. Diesen Testempfänger hatte ich mir schon vor einigen Jahren nach einer Anregung im HomeMatic-Forum konfiguriert…

Ich nutze SDR# im HomeMatic-Funknetz für gewöhnlich in der Version 1.0.0467 im Build „sdr-nightly“ mit folgenden Einstellungen…

Duty Cycle

In der Auswertung zeigte sich im Wasserfalldiagramm das folgende – mir in dieser Ausprägung bis dato noch nicht untergekommene – Phänomen…

Duty Cycle

Irgendein Gerät musste für die vergleichsweise langen und häufigen Sendeimpulse der CCU verantwortlich sein, die offensichtlich intensiv versuchte, dieses Gerät per Broadcast aufzuwecken. Bekanntermaßen sind oftmals batteriebetriebene Geräte ursächlich für solches Verhalten.

Es erschien mir daher sinnvoll, zunächst alle batteriebetriebenen Geräte, die der CCU zugeordnet waren, nach und nach stromlos zu machen. Eine Änderung stellte sich jedoch nicht ein. Auch bei den netzbetriebenen Geräte hatte ich damit keinen Erfolg.

Also wurden alle Programme deaktiviert. Die Impulse kamen hin und wieder noch immer aber lange nicht mehr so häufig, ich kam einer Lösung etwas näher.

Nach und nach aktivierte ich alle Programme wieder und stellte fest, dass bei Aktivierung (und damit Ausführung) eines bestimmen Programms, mit dem eine Klappenanzeige HM-Dis-TD-T…

Duty Cycle

…angesteuert wird,…

Duty Cycle

…sich das ungewöhnliche Sendverhalten stets reproduzierte…

Duty Cycle

Die Systemvariable „UG Werkstatt Lueften“, die das Programm triggert, wird aktualisiert, wenn der Raumregler in der Werkstatt oder ein Temperatur-/ Feuchtesensor im Außenbereich aktualisierte Luftfeuchtewerte übermittelt.

Eine Kommunikationsstörung wurde für die Klappenanzeige interessanterweise nicht angezeigt.

Ich machte das Gerät noch einmal stromlos und legte die Batterien wieder ein, erneut ohne Erfolg.

Erst nach Ablernen des Gerätes und Löschen aus der CCU war das Sendeverhalten der CCU wieder „normal“…

Duty Cycle

Nach einem Neustart der Zentrale, pendelten sich die Duty Cycles von CCU und LAN-Adapter nach einiger Zeit auf die folgenden, für ein System mit ca. 150 RF Geräten sehr akzeptablen Werte ein…

Duty Cycle

Es scheint, als wäre die Klappenanzeige – obwohl sie anfangs noch funktioniert hat – auch vorher ursächlich für den mit ca. 50% recht hohen Duty Cycle der CCU gewesen.

Bitte beachten…

SMART WOHNEN in Stern’s Haus ist ein rein privates, nicht kommerzielles Projekt. Meine Hinweise, Anleitungen, Schaltungen und Software werden so angeboten, „wie sie sind“, Support kann ich nur im Rahmen meiner begrenzten Freizeit leisten, hierfür bitte ich um Verständnis.
Die Verwendung meiner Hinweise, Anleitungen, Schaltungen und Software erfolgt auf eigenes Risiko. Ich übernehme hierfür keinerlei Gewährleistung bzw. Haftung! Für die Einhaltung der einschlägigen technischen Vorschriften ist jeder Anwender selbst verantwortlich!
Creative Commons Lizenzvertrag
Copyright © Jens-Peter Stern | SMART WOHNEN in Stern’s Haus | sternshaus.de
WordPress Cookie Plugin von Real Cookie Banner