Tagsüber hohe Duty Cycle Auslastung

[DidiTheE]

Interessanter Aspekt

Ich verwende eigentlich anstelle "bei Aktualisierung" immer "bei Änderung", da dürfte das Problem nicht auftreten, oder?

Werde aber nochmal alle in Frage kommenden Programm checken, eventuell ist es irgendwo falsch gesetzt (würde ja trotzdem funktionieren).

[Xel66]

Ich verwende eigentlich anstelle "bei Aktualisierung" immer "bei Änderung", da dürfte das Problem nicht auftreten, oder?

Kommt drauf an, wie nahe die definierten Grenzwerte an den Betriebswerten sind. Auch die Aktoreinstellung ist massiv ausschlaggebend. Mit schwankenden Parametern und zu engen Grenzen zur Datenübermittlung, kann der Aktor stetig gezwungen werden, seine Daten an die CCU zu senden (die bei IP diese wieder bestätigen muss). Da können Deine Programme gestaltet sein, wie sie wollen. Die im IP-Protokoll zwingende bidirektionale Kommunikation wegen der standardmäßigen Verschlüsselung zwingt die CCU die Pakete zu bestätigen. Zur Beherrschung dieses Problems gab es eigentlich die Entscheidungswerte. Hier wurde die Messwerüberwachung lokal im Aktor gemacht und bei Überschreitung der definierten Werte ein Entscheidungswert gesendet. Die Messwerte werden dann in größeren Zeittakten als Mittelwerte übertragen (IRC sogar als Broadcast). Aber da hat sich so einiges mit dem Generationswechsel geändert.

Gruß Xel66

[frd030]

Ich verwende eigentlich anstelle "bei Aktualisierung" immer "bei Änderung", da dürfte das Problem nicht auftreten, oder?
Werde aber nochmal alle in Frage kommenden Programm checken, eventuell ist es irgendwo falsch gesetzt (würde ja trotzdem funktionieren).

Doch, auch da kann sowas auftreten (siehe Xel66). Das Programm war ein (besonders plakatives) Beispiel.
Nochmal und etwas allgemeiner: eine der häufigsten Ursachen für erhöhten DC sind zu häufig übertragene Meßwerte. Auch 10s Abstände sind häufig schon zu oft - es ist kein Zufall, dass die Gerätedefaults für Meßwertübertragungen im Minutenbereich liegen! Die Kombination mit Programmen, die dann ebenso häufig getriggert werden und dann irgendwas schalten, was schon im gewünschten Zustand ist, macht es dann endgültig zum DC Desaster.

Beides führt zu hoher Kommunikationslast für die das System aufgrund der Beschränkung des DC nicht ausgelegt ist. Du hast bereits eine Meßsteckdose gefunden, die indirekt den DC nach oben treibt. Es ist aber nicht die Dose an sich, sondern die Einstellungen derselben und die Programme, die daran hängen.

Suchen, prüfen und abstellen der Ursachen sind nötig. Braucht es wirklich so häufig Meßwerte? Das Programm könnte auch abfragen, ob der Aktor schon im gewünschten Zustand ist und dann nichts tun, etc. pp.

[MichaelN]

Und dann gibt es noch Kombinationen von Bedingungen, die trotz "bei Änderung" wie "bei Aktualisierung" wirken.

Aber solche Problemfälle würde mein oben verlinktes Skript ja finden.