Anzahl der auszulassenden Statusmeldungen

[dtp]

Hallo,

ich habe mal eine Frage zu folgendem Hinweis im WebUI-Handbuch:

Im Grunde genommen ist das ja verstanden. Das Basiszeitfenster für die zyklische Statusmeldung ist 2 bis 3 Minuten (per Zufallsgenerator bestimmt).

Trägt man bei der Anzahl der auszulassenden Statusmeldungen (nennen wir es A) eine 0 ein, so wird keine Statusmeldung ausgelassen. Trägt man eine 1 ein, so wird nur noch alle 4 bis 6 Minuten eine Statusmeldung übertragen. Trägt man eine 255 ein, dann nur noch alle 512 bis 768 Minuten.

Also (A + 1) * (2 bis 3 min)

Aber jetzt kommt mein Verständnisproblem.

Trägt man bei der Anzahl der auszulassenden, unveränderlichen Statusmeldungen (nennen wir es B) ein 0 ein, so wird in Abhängigkeit vom vorherigen Wert unter "Anzahl der auszulassenden Statusmeldungen (A)" eine gegenüber der vorherigen Statusmeldung unveränderte Statusmeldung die nächsten 2 bis 3 Minuten unterdrückt.

Also (A + 1) * (B + 1) * (2 bis 3 min)

Kurzum, mit den Standardwerten von A = 1 und B = 20 wird eine Statusmeldung, wenn sie sich gegenüber der vorherigen geändert hat, alle 4 bis 6 Minuten gesendet und wenn sie sich nicht gegenüber der vorherigen geändert hat, nur alle 84 bis 126 Minuten.

Speichert jetzt jede entsprechend einstellbare Komponente so lange die letzte Statusmeldung und vergleicht alle neuen Statusmeldungen bis zum Ablauf der beiden Zeitfenster mit dieser gespeicherten Statusmeldung? Und was passiert bei Komponenten, die mehrere Werte als Statusmeldung übertragen, wie z.B. der Wettersensor? Werden da die Einzelwerte (Wind, Helligkeit, Temperatur, Luftfeuchtigkeit etc.) als einzelne Statusmeldungen oder als eine Statusmeldung in einem Paket übertragen? Muss ja schon einzeln sein, sonst gäbe es ja quasi nie den Fall, dass sich die Statusmeldungen nicht ändern.

Helft mir doch bitte mal auf die Sprünge, damit ich hier die für mich optimalen Werte hinsichtlich Genauigkeit auf der einen Seite und Duty Cycle auf der anderen einstellen kann.

[Sammy]

Alles richtig verstanden.
Umsetzungen kann es mehrere Varianten geben. Je nach Gerät.
Wenn man beispielsweise zusammenhängende Statuswerte hat (wie z.B. Temperatur und Luftfeuchtigkeit), dann sollten die natürlich gemeinsam in einer Statusmeldung übertragen werden, genau wie der Realzustand mit seinen 3 zugehörigen virtuellen Kanälen eines Aktorkanals. Bei einem 4-fach Schaltaktor wären aber die anderen 3 Schaltkanäle uninteressant, wenn sich nur am Real- oder einem Virt-Kanal von Aktorkanal 1 was ändert.
Also packt man sinnvollerweise zusammengehörigen Status in 1 Telegramm.
Bei den analogen Sensoren gibt es ja auch kleine unwesentliche Änderungen, die nicht gemeldet werden müssen (hier ist die Schwelle glaub ich oft bei ca. 10% oder so). Die zuletzt übertragenen Einzelwerte kann man ja leicht speichern und mit den aktuellen Werten einer potentiellen neuen Sendung vergleichen. Sind die Sendebedingungen dann erfüllt, wird tatsächlich gesendet.
Bei der Gruppierung von mehreren Status in 1 Telegramm ist es sicher auch interesant, ob Statusmeldungen bidirektiional versendet werden (und der Sensor also weiß, dass der zuletzt gesendete Wert in der Zentrale bekannt ist und daher nicht unbedingt gesendet werden muss) oder ob unidirektional gesendet wird und daher grundsätzlich alle Werte gesendet werden müssen, damit gültige Statuspaare oder mehrfache Kombinationen bei der Zentrale vorliegen.

[dtp]

Danke für deine Erläuterungen, Sammy.

Die Standardvorgaben von eQ-3 sind ja bei den meisten HMIP-Sensoren A = 1 und B = 20. Hatte mal beides bei meinen Sensoren auf 0 gesetzt, was den DC zeitweise etwas anstiegen ließ.

Was ich aber irgendwie nicht ganz verstehe, sind die vom Wettersensor gelieferten Werte. Hier mal am Beispiel der Winddaten in der unteren Grafik.

Links der grünen Trennlinie waren die beiden Werte auf A = 1 und B = 20 gesetzt; rechts davon auf A = 0 und B = 0. Ich frage mich, warum der Wettersensor linksseitig so wenig Windrichtungswerte überträgt, wo sich A doch nur um 1 unterscheidet und sich die Windrichtung nun wirklich permanent ändert, wenn kein allzu starker Wind weht oder Windstille ist. Bei der Windstärke im oberen Diagramm sind die Auswirkungen der unterschiedlichen Einstellungen deutlich geringer.

[schwera3]

Hallo zusammen,
wenn ich bei meinen Heizkörperthermostaten die auszulassende Statusmeldungen auf 20 stelle, meckert die CCU mit "Kommunikationsstörung". Woran liegt das?

Gruß


Ralf

[Daimler]

Hi - und willkommen im Forum.

ist bei meinen HM-CC-RT-DN mit FW 1.4 genauso.
Hatte zuletzt noch versucht, den Wert auf den Standardwert von 20 zu setzen, um den DC ein wenig zu senken -> alle nur noch SMs.
Bin dann wieder auf 0 und habe Ruhe.
Bei den HM-TC-IT-WM-W-EU habe ich es auf 50 stehen - keine Probleme.

Warum das so ist, weiß wohl nur EQ3

[schwera3]

So ein Mist, warum kann ich es dann überhaupt verstellen...... Naja, vielen Dank für Deine Antwort.

[Xel66]

... um den DC ein wenig zu senken ...

Das Meiste was die senden sind Broadcasts. Also nicht quittierpflichtige Statusinformationen. Diese wirken sich auf den Duty Cycle überhaupt nicht aus, weil die Empfänger sie nicht quittieren müssen. Der einzige (eher hypotetische) Effekt, denn solche "Einsparung" haben könnte, wäre Batterielaufzeit. Da aber die Stellmotoren und deren Betrieb die größten Verbraucher sind, sind durch diese Maßnahme eher homöopathische Wirkungen zu erwarten.

Gruß Xel66

[alchy]

wenn ich bei meinen Heizkörperthermostaten die auszulassende Statusmeldungen auf 20 stelle, meckert die CCU mit "Kommunikationsstörung". Woran liegt das?

Daran, das sich bei einigen Geräten dann ein Timing Problem einstellt.
Bei den RF Geräten ist der Timeout festgelegt und vor allem auch auslesbar. Bei den IP Geräten wird es komplizierter.

Hat das Gerät z.B. einen Timeout von 88200 Sekunden wird eine Kommunikationsservicemeldung ausgelöst, wenn sich das Teil nicht ~ innerhalb eines Tages meldet.
Stellt man die Statusmeldungen auf aus (oder hoch genug) und wird z.B. das Fenster innerhalb eines Tages nicht bedient, passiert das dann entsprechend. Warum man Einstellungen so wählen kann, das solche Fehler möglich sind, wäre eine Frage, welche nur EQ-3 beantworten kann.

Auf Grund der versuchten Reduzierung des DutyCycle die Statusmeldungen zu verändern ist kaum zielführend. Grundsätzlich bieten die Standardvorgaben meist schon den besten Kompromiss.


Alchy

[Daimler]

Hi,

ihr habt nat. recht - nicht DC sondern Batterie schonen war der Hintergrund meiner Taten.

Ändert aber nichts daran, dass man hier etwas einstellen kann, was unweigerlich zu Kommunikations-Fehlermeldungen führt.
Und das ist ein Bug - ob nun in der CCU- oder der HKT-Firmware.

@Ralf
Welche FW hast du denn auf dem / den HM-CC-RT-DN?

Vielleicht kann ja mal jemand, der die 1.5.3er installiert hat testen, ob es sich damit genauso verhält.
Ich bin aus bekannten Gründen wieder zurück auf die 1.4 gewechselt.

[jp112sdl]

Ich verstehe das Problem nicht.

Bei Fensterkontakten kann man die zykl. Meldung auch abschalten.
Öffnet/schließt man nun tagelang kein Fenster, dann bekommt man die "nervige" Servicemeldung angezeigt.
Was für ein schlimmer Bug! Das kann doch nicht sein! Was bietet uns eQ-3 da nur an???

Oder vielleicht doch gar nicht so schlimm?

Stellt man die Statusmeldungen auf aus (oder hoch genug) und wird z.B. das Fenster innerhalb eines Tages nicht bedient, passiert das dann entsprechend. Warum man Einstellungen so wählen kann, das solche Fehler möglich sind, wäre eine Frage, welche nur EQ-3 beantworten kann.

Wenn man weiß, dass man ohnehin jeden Tag 1x das Fenster bedient, dann kann man das getrost deaktivieren. Denn warum soll nun noch zusätzlich eine "ich lebe noch" Statusmeldung gesendet werden?
Ansonsten lässt an die zyklische Meldung halt an - um auch bei Nicht-Bedienung mitzubekommen, wenn das Gerät spinnt.