Tagsüber hohe Duty Cycle Auslastung

[DidiTheE]

Ich zeichne die aktuellen Werte von DutyCycle und Carrier Sense im Historian auf und beobachte tagsüber regelmäßig hohe Auslastungen beim DutyCycle.
Die Werte gehen bis auf 70-80% hoch, beruhigen sich abends dann aber wieder und sind nachts im Bereich von 10%.
Das System läuft aber trotzdem "normal" und die Reaktionszeiten sind im grünen Bereich.

Auffallend ist, dass die Werte bei Abwesenheit (d.h. niemand zuhause) deutlich tiefer sind und sich unter 20% bewegen.
Ich vermute deshalb, dass einer der Bewegungsmelder HM-Sen-MDIR-WM55 (insgesamt 4) oder HmIP-SPI (1x) die Ursache ist.

Mit dem Radio Analyzer EQ3-RFA konnte ich den "Störer" aber bisher nicht einzugrenzen.

• Welche Möglichkeiten gibt es in der CCU herauszufinden, welches Gerät übermäßig Bandbreite beansprucht?

• Gibt es speziell bei den Bewegungsmeldern HM-Sen-MDIR-WM55 und HmIP-SPI Parameter, die zu optimieren sind?

[Xel66]

Nein, die BWM sind es eher nicht, es sei denn, Du hast kurze Zeiten eingestellt. Es sind eher unnötige Steuerungsvorgänge, die ausgelöst werden (Aktor wird ein/ausgeschaltet obwohl er bereits ein/ausgeschaltet sind. In solchen Programmen ist es immer sinnvoll, den Status zu prüfen, bevor ein Schaltbefehl generiert wird.

Gruß Xel66

[Roland M.]

Hallo!

Es sind eher unnötige Steuerungsvorgänge, die ausgelöst werden (Aktor wird ein/ausgeschaltet obwohl er bereits ein/ausgeschaltet sind.

An so etwas denke auch ich.
Ich würde da einmal auf ein Beschattungsprogramm tippen, das "auf Aktualisierung" alle drei Minuten (Sendeintervall von Temperatursensoren u.ä.) Rolladen/Jalousien/Markisen/whatever ansteuert.


Roland

[alchy]

Wir ein Aktor bei dir mit Sonnenenergie gespeist?

>> mögliche Gründe für DutyCycle (unvollständig) <<

Alchy

[manfredh]

Ich halte es schon für möglich, dass die Bewegungsmelder die (Haupt)Übeltäter sind. Es sei denn, sie stehen auf einem Sendeabstand von 8 oder 16 Minuten.

Du kannst doch mal testweise per Programm die BWM für ein bestimmstes Zeitfenster auf Inaktiv setzen, dann siehst du es im Diagramm.

Allerdings musst du dich dann darauf einstellen, dass die CCU Kommunikationsstörung erkennt. Bei "inaktiv" verweigern sie (zumindest meine SMI) jegliche Sendeaktivität.

[Xel66]

Ich halte es schon für möglich, dass die Bewegungsmelder die (Haupt)Übeltäter sind. Bei mir heben Bewegungsmelder auch den Grundpegel etwas, aber das sind einstellige Prozentpunkte. Ich habe in allen Räumen BWM installiert (und auch welche im Außenbereich). Allerdings laufen die in der Grundkonfiguration 240 Sekunden.

Dann muss man sie schon auf einen kurzen Sendeabstand konfigurieren. Da es aber nur tagsüber zu sein scheint, und den Gesamtpegel um einen realativ konstanten Betrag anhebt, erscheinen mir zyklisch durchgeführte Programmläufe (ggf. getriggert durch "bei Aktualisierung") wahrscheinlicher. Man muss die Zeiträume der Erhöhungen eben gegen die persönlichen (durch Bewegungsmelder getriggerte Programmläufe aka Anwesenheiten), aber auch klimatischen (ggf. außentemperaturgetriggerte Beschattungsszenarien etc.) Ereignisse abgleichen.

Es ist ja deutlich sichtbar, dass an den Tagen die Zeiträume unterschiedlich lang aber relativ stark begrenzt sind. Hier gilt es, Korrelationen zu den Gegebenheiten herzustellen und eine Ursache abzuleiten. Da ja anscheinend Historian im Einsatz ist, kann man ja schön z.B. die Außentemperatur oder die Bewegungserkennungsereignisse im Diagramm auch nachgehend überlagern und so dem Trigger auf die Spur kommen.

Gruß Xel66

[DidiTheE]

Vielen Dank für die guten Inputs. Ich werde versuchen, damit die Ursache mal weiter einzugrenzen.

Wir ein Aktor bei dir mit Sonnenenergie gespeist?

>> mögliche Gründe für DutyCycle (unvollständig) <<

Alchy

Ich verwende zwar keine Aktoren mit Sonnenenergie, aber zwei Helligkeitssensoren, die zur Steuerung von Jalousien eingesetzt werden -> ich schau mir die Programme nochmal genauer an.

Ausserdem hat mich der von Alchy verlinkte Beitrag auf eine andere mögliche Ursache gebracht: Messsteckdosen. Ich verwende mehrer HMIP-PSM und einen HM-ES-PMSw1. Letzterem traue ich nicht so recht. Er ist tagsüber eingeschaltet und die Messwerte des Verbrauchers schwanken recht stark. Werde den testweise mal ausser Betrieb nehmen.

[MichaelN]

Mit diesem Skript kannst Du bequem die häufigsten getriggerten Programme auswerten. Das sollten dann die interessantesten Kadidtane für den DC sein:

viewtopic.php?f=31&t=68913#p673252

[DidiTheE]

Danke für das Skript. Hat mir einige Programme gezeigt, die ich eventuell anders lösen sollte. Aber soweit ich das sehe, verursacht keines davon den Anstieg des Duty Cycle.

...
Ausserdem hat mich der von Alchy verlinkte Beitrag auf eine andere mögliche Ursache gebracht: Messsteckdosen. Ich verwende mehrer HMIP-PSM und einen HM-ES-PMSw1. Letzterem traue ich nicht so recht. Er ist tagsüber eingeschaltet und die Messwerte des Verbrauchers schwanken recht stark. Werde den testweise mal ausser Betrieb nehmen.

Die Datenerfassung der Messsteckdosen haben jedoch einen massiven Einfluss auf den Duty Cycle. Ich habe den HM-ES-PMSw1 testweise ausser Betrieb genommen und siehe da, die Werte des Duty Cycle bleiben unter 30%. Ich lass das jetzt mal ein paar Tage so laufen und werde dann nochmals die Gegenprobe machen.

[frd030]

Die Datenerfassung der Messsteckdosen haben jedoch einen massiven Einfluss auf den Duty Cycle.

Es ist nicht die Datenerfassung an sich, sondern häufig zu kurze Messintervalle, bspw. im Sekundentakt, führt auch zu vielen Quittungen, gerade im alten HM-Protokoll.

Diese häufigen Meßwerte werden dann "idealerweise" in Programmen nach diesem Muster verwendet:

Code: Alles auswählen

WENN Messwert > Schwellwert (bei Aktualisierung)
DANN Schalte Aktor ein

Ein solches Programm wird also im Zweifel im Sekundentakt getriggert und schaltet dann jedesmal einen Aktor ein, der schon eingeschaltet sein dürfte.
Jedesmal beim Einschalten ist das ein (überflüssiger) Sendevorgang der CCU, und schwupps, geht der Duty Cycle nach oben!