Zyklische Statusmeldungen - Sendezeiten völlig unverständlich

[hel400]

Hallo zusammen,

es geht um die "Zyklischen Statusmeldungen" von IP-Geräten --> hier am Beispiel eines Temperatur-Außensensors HmIP-STHO

So sieht die Konfig-Seite aus - bitte hier die ersten 3 Parameter für die "Zyklischen Statusmeldungen" zu beachten:

Und hier die Protokolleinträge - man beachte hier (nur als Beispiel) diese Riesenlücke zwischen 15:34 und 16:27 Uhr.
Dabei ist die Tempearatur auch um über 1 Grad zurückgegangen - warum meldet das der Sensor nicht früher??

Gibt's da eine plausible Erklärung dafür?

[HM-Villa]

Ja, die erhält man, wenn man aus das Fragezeichen drückt.

[hel400]

Ja, die erhält man, wenn man aus das Fragezeichen drückt.

Ja vielen Dank, das ist ja ganz neu ......

Also, wenn man das "Fragezeichen" genau liest, so lautet die Formel (gerundet auf ganze Minuten):
Für Nachrichten, wenn sich der Status ändert: Zwischen 2 und 3 Minuten
Für Nachrichten, wenn sich der Status nicht ändert: Zwischen 62 und 95 Minuten

Wenn man sich nun aber die rot markierten Nachrichten im Protokoll ansieht:
Zwischen 15:34 und 16:27 sind ca. 53 Minuten (passt in KEINE der beiden Abstände!!), außerdem hat sich der Status geändert, hätte also um spätestens 15:37 Uhr die nächste Meldung kommen müssen.

So gesehen ist eigentlich KEIN einziger Zeitabstand erklärbar, passt in keine der beiden Zeitdefinitionen...???

[Baxxy]

Ja, die Teile halten sich da irgendwie nicht (immer) an die Beschreibung.
Was aber immer passt ist x/0/0. Da kommen die Meldungen sauber im 2-3Min Raster.
Batterielaufzeit wird aber sinken.

[frd030]

Zudem nimmst Du an, dass sich das Grad Unterschied am Anfang der Periode ergeben hat? Warum?
Vielleicht hat das Ding sich einfach gemeldet, weil sich die Temperatur nach 53 min. geändert hat?

[hel400]

Zudem nimmst Du an, dass sich das Grad Unterschied am Anfang der Periode ergeben hat? Warum?
Vielleicht hat das Ding sich einfach gemeldet, weil sich die Temperatur nach 53 min. geändert hat?

Nun, die Temperatur im rot markierten Beispiel ist ja von 3,10 auf 2,0 runtergegangen - aber eben NICHT als plötzlicher Sprung, sondern langsam im Laufe einer Stunde. Da hätte es vorher längst 3,0 - 2,8 - 2,5 usw..usw melden sollen, aber sicher nicht ein plötzlicher Sprung.
Und wie gesagt - die Zeiten passen in keines der beiden Raster, einfach (scheinbar) völlig wirr

[Xel66]

Ich denke eher, dieser Sensor leidet an der gleichen Krankheit wie die HmIP-Wandthermostate bezüglich der zyklischen Statusmeldungen. Da ist ein Bug in der Funktion, die die Messwerte übermittelt. Vielleicht ist die Hysterese zu groß programmiert, vielleicht sind auch die Zykluszeiten kaputt (ich tippe auf letzteres, denn nicht mal in der Gruppierung wird da im normalen 3-Minuten-Raster kommuniziert).

Da wir in die Firmware nicht reinschauen können hilft vermutlich nur, die Zykluszeit so weit wie möglich auf 0/0 runterzuschrauben. Ich glaube eher nicht, dass da die Batterielaufzeit gegenüber den klassischen Sensoren so viel schlechter wird, denn die kommunizieren im 3-Minuten-Raster. Mein klassischer Außentemperatursensor hat Batteriestandzeiten weit über zwei Jahre. Und Wettertelegramme werden (laut meinem AskSin-Analyzer) zumeist gebroadcastet, so dass die verschlüsselte Kommunikation eher eine untergeordnete Rolle bezüglich des Batterieverbrauchs spielen dürfte. Allerdings habe ich keinen HmIP-STHO sondern nur HmIP-Wandthermostate, bei denen die gleiche Kommunikationsschwäche aufgefallen ist. Das älteste ist jetzt über ein Jahr alt und hat noch den ersten Batteriesatz.

Gruß Xel66