Zyklische Statusmeldung

[Roland M.]

Hallo!

Die Empfehlungen manifestieren sich in Form der "Defaulteinstellungen" der Geräte.

+1

Ich sehe keinen Grund, hier von den Defaultwerten abzuweichen.
Der Duty Cycle, der bei mir bei rund 100 Geräten in der Nacht (ohne Bewegungsmelder, Waschmaschine & Co) im niedrigen einstelligen Bereich liegt, spricht auch nicht dagegen.


Roland

[Aquaplex]

Ich sehe keinen Grund, hier von den Defaultwerten abzuweichen.
Der Duty Cycle, der bei mir bei rund 100 Geräten in der Nacht (ohne Bewegungsmelder, Waschmaschine & Co) im niedrigen einstelligen Bereich liegt, spricht auch nicht dagegen.

Ich habe 120 IP-Geräte und der Zentralen-DC liegt im Ruhezustand bei gut 20%. Darunter komme ich so gut wie nie, trotz bereits durchgeführter Optimierungsmaßnahmen. Ich habe also allgemein schon ein recht hohes Grundlast-Funkaufkommen. Je mehr Broadcast-Meldungen jetzt durch "zu häufige" Statusmeldungen der Geräte kommen, desto mehr ist der Funk allgemein doch "belastet", oder? Auch wenn der DC der CCU nicht direkt adressiert wird.

[MichaelN]

Solange alles funktioniert, gibt es ja keinen Grund zu optimieren. PSM sind sehr gesprächig, da kannst Du mit dem "Wert wird gesendet, wenn" Einstellung festlegen, wie fein die auflösen sollen. Wenn Du nur den Unterscheid zwischen 0 und 1000W zur Entscheidung brauchst, musst Du nicht jedesmal Daten senden lassen, wenn sich der Wert um 0,5 W ändert.

Und ungünstig gestaltete Programme können den DC treiben. Schau nach unter Status welche Programme häufig getriggert werden.

[Aquaplex]

Schau nach unter Status welche Programme häufig getriggert werden.

Ohne jetzt ins OffTopic abschweifen zu wollen: Dem Zeitstempel der Programme traue ich überhaupt nicht. Selbst einfachste Programme mit eindeutig definierten Triggern werden laut Zeitstempel unlogisch ausgeführt.

[MichaelN]

Selbst einfachste Programme mit eindeutig definierten Triggern werden laut Zeitstempel unlogisch ausgeführt.

Man sage bei der CCU niemals nie, aber das ist eher ein Hinweis darauf, das Du die etwas eigenwillige Logik der CCU nicht zu 100% verstanden hast.
Du könntest ja mal eins dieser einfachen Programme zeigen und erläutern warum der Zeitstempel unlogisch erscheint. Richtig ist, das ein aktualisierter Zeitstempel nicht bedeutet, das das Programm DANN auch zur Ausführung kam.

[Aquaplex]

Du könntest ja mal eins dieser einfachen Programme zeigen und erläutern warum der Zeitstempel unlogisch erscheint. Richtig ist, das ein aktualisierter Zeitstempel nicht bedeutet, das das Programm DANN auch zur Ausführung kam.

Ich erinnere mich an ein Programm, dass in der WENN-Prüfung ausschließlich (!) eine Systemvariable (Boolean) enthielt, deren Bedingung "auf Änderung" getriggert wurde. Es kam vor, dass der Zeitstempel des Programms (unter Status > Programme) neuer war als der Zeitstempel der Systemvariable (bzw. deren letzte Änderung). Das dürfte doch nicht sein, wenn keine weiteren Trigger im Programm enthalten sind. Oder irre ich?

Daher bin ich dem Zeitstempel eines Programms etwas skeptisch gegenüber. Noch ganz kurz abgeschweift: ich hatte auch mal alle Programme inaktiv gesetzt und der DC der CCU blieb trotzdem bei etwa 20%. Scheint also an meinen Geräten bzw. deren Kommunikation mit der Zentrale zu liegen. Daher hatte ich die Vermutung/Hoffnung/Idee, mit dem zykl. Statusmeldungen etwas optimieren zu können

[frd030]

Es kam vor, dass der Zeitstempel des Programms (unter Status > Programme) neuer war als der Zeitstempel der Systemvariable (bzw. deren letzte Änderung). Das dürfte doch nicht sein, wenn keine weiteren Trigger im Programm enthalten sind. Oder irre ich?

Das würde ich erstmal erwarten, dass das Programm nach der triggernden Variable läuft, nicht vorher!
Die Frage ist, wie lange es gedauert hat zwischen den Ereignissen und was die CCU dazwischen getan hat. Häufig sind Skripte mit system.exec an Verzögerungen schuld, die auf irgendwas warten und solange die CCU lahm legen.

Daher hatte ich die Vermutung/Hoffnung/Idee, mit dem zykl. Statusmeldungen etwas optimieren zu können

Statusmeldungen werden nicht quittiert, daher kein Einfluss. Was Einfluss haben kann, sind häufige Meldungen von irgendwelchen Messwerten, Schwellwerten, etc., deren Änderung wiederum zu Befehlen an Geräte führen, die aber an den Geräten nichts ändern (z.B. Einschalten von schon eingeschalteten Aktoren).
Alles Glaskugel, da niemand hier sehen kann, was Du alles sonst so eingestellt und programmiert hast.

Im Forum gibt es aber eigentlich genügend Tipps und Tricks, wie man einen DC auf ein erträgliches Maß bekommt.

[Xel66]

... neuer war als der Zeitstempel der Systemvariable (bzw. deren letzte Änderung). Das dürfte doch nicht sein, wenn keine weiteren Trigger im Programm enthalten sind. Oder irre ich?

Ja, Du irrst. Der Zeitstempel der "letzten Änderung" ist genau das, was dessen Name aussagt - der letzte Statuswechsel. Wird die Systemvariable zwischenzeitlich durch irgendwas auf den gleichen Zustand gesetzt, wird logischerweise der Zeitstempel der letzten Änderung nicht aktualisiert. Unabhängig dessen ist der CCU aber bekannt, dass die Systemvariable gesetzt (aber nicht verändert) wurde.

Enthält nun ein Programm diese Variable als Trigger, bekommt es diesen Vorgang des Erneuerns des Status mit, und führt eine Bedingungsprüfung durch (weshalb auch der Zeitstempel des Programms aktualisiert wurde). Eine Prüfung auf "bei Änderung" ist aber Teil der Bedingungsprüfung des Programms und wird nicht im Vorfeld durch die CCU ausgewertet. Das heißt, das DANN würde nur abgearbeitet, wenn sich die Systemvariable geändert hat (im Gegensatz zu "bei Aktualisierung"). In beiden Fällen wird aber der Zeitstempel des Programms aktualisiert, auch wenn kein DANN ausgeführt wurde.

Funfact: auch wenn z.B. ein Trigger auf "bei Änderung" steht, kann unter Umständen in Abhängigkeit der anderen angelegten Trigger eines Programms ein Verhalten wie "bei Aktualisierung" herauskommen (insbesondere, wenn der gleiche Trigger auch in SONST WENN eine Verwendung findet). Gerade in Programmen mit mehreren SONST WENN fällt man da schnell herein. Das hat damit zu tun, wie die CCU Programme triggert und die Bedingungsprüfung durchführt. Näheres dazu erklärt Dir der Einsteigerthread und das WebUI-Handbuch (Stichwort: "von oben nach unten"-Prüfung). Aber wegen zyklischer Statusmeldungen würde ich keine Ressourcen verschwenden. Viele laufen als Broadcast und schlagen daher nicht auf den Duty Cycle. Meistens handelt man sich damit nur Probleme an anderer Stelle ein.

Gruß Xel66

[Aquaplex]

Vielen Dank für die Tipps. Dann muss ich weiter suchen, warum der DC selbst mit komplett deaktivierten Programmen nie unter 20% fällt. Alle Aktoren mit Messfunktion sind deaktiviert. Die zyklischen Statusmeldungen haben keinen Einfluss, das ist jetzt klar. Außer 6 Thermostaten und einer Wetterstation sollten bei mir eigentlich nicht allzu viele "Messwerte" generiert werden

[Roland M.]

Hallo!

Dann muss ich weiter suchen, warum der DC selbst mit komplett deaktivierten Programmen nie unter 20% fällt.

Welche CCU bzw. welche Firmware verwendest du?
Da gab es ja einmal eine Version, mit der der DC falsch/anders/zu hoch angezeigt wurde.
Hat mich damals nicht so recht interessiert, weil ich noch mit der CCU2 unterwegs bin...


Roland