Duty Cycle läuft Amok

[JoMass]

Auch in RedMatic kanst jeden Flow einzeln deaktivieren (Flow Reiter anklicken, und dann im aufpoppenden Fenster links unten Aktiviert/Inaktiv wählen)

zudem gibts mit dem Debug node doch super Analyse Möglichkeiten ...

[Hütte]

@rucksmann007

Ich habe mir diesen nano-CUL geholt und bin dann nach Baxxy's Anleitung Punkt für Punkt vorgegangen. Ich hatte auch keinen Bock darauf gehabt, mich mit den ganzen Zusammenlöten abzugeben. Und mit der Anleitung von Baxxy (Danke noch mal für die Anleitung) habe ich auch meinen ersten Arduino überhaupt geflasht. Dafür, dass ich erst einmal alles nötige installieren musste (IDE und Treiber) und es das erste Mal war, hat das Ganze etwa eine halbe Stunde gedauert. Und zusammen mit dem AskSinAnalyser XS hat das ganze dann auch sofort funktioniert. Habe da auch schon Potential gefunden, um den DC zu senken. Da sind gerade viele IP-Geräte in ihren Grundeinstellungen einfach sehr geschwätzig, ihren Status mitzteilen, auch wenn sich am Gerät der Status nicht geändert hat. Denn warum muss ein Thermostat alle ein bis 2 Minuten seine aktuelle Temperatur senden, wenn sie sich eh nicht geändert hat. Und bei einer großen Anzahl von Geräten kommt dann schon einiges zusammen. Nur mit testweisen Anpassungen an ein paar Geräten ist bei mir der DC um 5% gesunken. Und da ist noch mehr Potential.

[Xel66]

Habe da auch schon Potential gefunden, um den DC zu senken. ...
...Denn warum muss ein Thermostat alle ein bis 2 Minuten seine aktuelle Temperatur senden, wenn sie sich eh nicht geändert hat.

Die Thermostate senden ihren Broadcast (kann man auch im Analyzer sehen), weil sie sich bei der Gelegenheit auch neue Einstellungen von der CCU holen würden, denn wake on radio ist standardmäßig nicht aktiviert. Das geschieht erst, wenn Gruppen gebildet würden oder ein TFK zur Erkennung der Fensteröffnung verknüpft würde. Und wie ich schon schrieb sind das Broadcasts (also nicht durch die CCU quittierpfllchtige Funkpakete). Diese haben keinen Einfluss auf den Duty Cycle der CCU. Sie belasten maximal den DC des einzelnen Gerätes. Den kann man im Normalfall aber bei einem Einzelgerät kaum ausnutzen. Das passiert maximal, wenn sich der Aktor/Sensor zum bubbling idiot entwickelt (Fehlerfall oder zur Neige gehende Batterien). Es gibt dort also keinerlei Potenzial zur Duty Cycle-Senkung. Triggerst Du allerdings Programme auf die Aktualisierung dieser Daten und sendest dann Befehle aus (die wiederum quittierpflichtig sind), dann würde das Auswirkungen auf den DC haben. Die Ursache liegt dann aber nicht in den Geräteeinstellungen, sondern in Deiner Programmierung.

Gruß Xel66

[Hütte]

@Xel66,

Ich habe bei mir 14 HmIP-BWTH (für Fußbodenheizung) im Einsatz und bei denen werden über ein Programm nur das Heizungsprofile gewechselt, wenn eine SV zwischen Anwesenheit und Abwesenheit wechselt. Ansonsten laufen die autark innerhalb des aktiven Profiles. Da sie über 220V laufen sind sie also immer auf Empfang und senden auch kein Broadcast, denn das hätte ich auch im Analyzer gesehen.

Und das Umschalten der Profile geschieht maximal zwei Mal in der Woche - durch die "Zwangshaft" im Home-Office zur Zeit also gar nicht. Es gibt teilweise DV mit TFK's in Räumen mit HmIP-TFK's und bei Räumen mit klassischen HM-TFK's wird der "Fenster-Offen-Modus" über Programme gelöst. Aber die Fenster werden nicht alle paar Minuten auf- und zugemacht. Also kann es daran wohl nicht liegen, dass der DC um 5% gesunken ist, nachdem ich die Parameter angepasst habe - der Rest hat sich nicht geändert, auch nicht, was die Häufigkeit des Auslösens anderer Events wie BWM, Temperatur- oder Lichtsensoren betrifft. Da konnte ich mir in den letzten Monaten im Home-Office einen ganz guten Überblick verschaffen.

Also zumindest bei mir zeichnet es sich ab, dass diese Fußbodenheizungsthermostate ziemlich viel Traffic erzeugen, zumal im AskSinAnalyser zu sehen ist, dass jedes Mal, nachdem das Thermostat sich bei der Zentrale gemeldet hat, auch von dort Datentelegramme zurück an das Thermostat gesendet wurden. Ist ja auch logisch, da bei HmIP die Übertragung grundsätzlich verschlüsselt und eine Empfangsbestätigung erforderlich ist. Das sind jedes Mal 4 Telegramme, die da ausgetauscht werden. Und da kommt dann schon was zusammen.

Aber ich kann dir bestätigen, dass meine beiden HMIP-eTRV-Thermostate bei weitem nicht so "geschwätzig" sind und nach einem Broadcast von denen auch keine Rückmeldung der Zentrale erfolgt - also auch kein weiterer Traffic im Funkverkehr.

[Xel66]

Da sie über 220V laufen sind sie also immer auf Empfang und senden auch kein Broadcast, denn das hätte ich auch im Analyzer gesehen.

Nun gut, ich habe kein HMIP-Thermostat. Alles noch klassisches HM. Bei mir kommen alle Statusmeldungen als Broadcast und sind sowohl in der Spalte "An" als Broadcast gekennzeichnet und auch in der Spalte "Flags" stehen die Kürzel "BCAST", "RPTN" und "WKMEUP". Mehr ist nicht zu entnehmen. Und das bei allen meinen Thermostaten. Dann wäre ja IP ein Rückschritt in Sachen Duty Cycle. Wobei das dann noch abhängig von der Größe des Payload ist. Thermostate sind aber leider bezüglich der übermittelten Informationen nicht gerade sparsam.

Aber ich kann dir bestätigen, dass meine beiden HMIP-eTRV-Thermostate bei weitem nicht so "geschwätzig" sind und nach einem Broadcast von denen auch keine Rückmeldung der Zentrale erfolgt - also auch kein weiterer Traffic im Funkverkehr.

Das widerspricht aber irgendwie der ersten Theorie, bei der Du die Kommunikation auf den AES-Key zurückführst. Die eTRV benutzen das gleiche Kommunikationsprotokoll. Demzufolge müsste dann da auch eine Quittung von der CCU zu sehen sein. Zumindest so meine Theorie. Ich vermute eher ein Programm, welches auf die Statusmeldungen der Thermostate reagiert und so die CCU zur Kommunikation bewegt.

Gruß Xel66

[Hütte]

Das widerspricht aber irgendwie der ersten Theorie, bei der Du die Kommunikation auf den AES-Key zurückführst. Die eTRV benutzen das gleiche Kommunikationsprotokoll. Demzufolge müsste dann da auch eine Quittung von der CCU zu sehen sein. Zumindest so meine Theorie. Ich vermute eher ein Programm, welches auf die Statusmeldungen der Thermostate reagiert und so die CCU zur Kommunikation bewegt.

Leider zeigt der AskSinAnalyzer XS bei HmIP-Geräten im Moment noch nicht die Flags an. Daher kann man nicht so richtig sehen, was da für Daten gesendet werden. Aber vielleicht gibt es da bald Abhilfe. Aber bei den HmIP-eTRV sehe ich im Analyzer nur eingehende Pakete an die Zentrale und keine ausgehenden Pakete zurück an das Thermostat.

Und ich habe definitiv keine weiteren Programme, außer zum Umschalten der Profile, die Aktionen an den Thermostaten ausführen oder auf Statusmeldungen der Thermostate reagieren, auch nicht bei den HmIP-eTRV.

Aber Dank des Analyzers kann man die "Vielschwätzer" ausfindig machen und durch Anpassung der Geräteparameter Abhilfe schaffen. Denn solange, zum Beispiel, die Helligkeitswerte eine internen BWM nicht dazu genutzt werden, um Geräte zu steuern, kann man die Zeitdauer der Übermittlung der Werte in den Geräteeinstellungen auf deren Maximalwert ehöhen.

Ich habe gerade im Analyzer auch festgestellt, dass der, bei allen HmIP-Geräten voreingestellte, Parameter "Routing Aktiv" dazu führen kann, dass der Funkverkehr nicht direkt zur Zentrale erfolgt (obwohl sie direkt erreichbar ist), sondern über einen als Router arbeitenden Aktor, wie dem HmIP-PSM. Und das nur, weil der ein paar Meter dichter dran ist, aber eigentlich weiter von der Zentrale - bei teilweise schlechteren Funkverhältnissen - entfernt ist. Hier sollte man doch tatsächlich die Standard-Parameter der Geräte prüfen und testen, inwieweit dieses "Routing Aktiv" tatsächlich hilft oder eher zu Kommunikationsproblemen führt.

Besser wäre es wohl, dass dieses Flag per Default ausgeschaltet ist und man es manuell aktiv aktivieren muss. Aber das ist wohl dem HmIP-AP und dessen Zusammenarbeit mit der HmIP-App geschuldet, da man dort nur begrenzte Möglichkeiten hat, die Geräteparameter einzustellen. Und das Routing-Flag gehört dort definitiv nicht dazu. Schließlich soll die App, zusammen mit dem Access-Point so einfach wie möglich funktionieren, ohne dass der Nutzer sich Gedanken machen muss, welche Geräterparameter eigentlich besser wären.

Aber zum Glück haben wir hier in RaspberryMatic oder auf einer CCU2/CCU3 wesentlich mehr Optionen für ein Fein-Tuning des Systems.

[Xel66]

Und das nur, weil der ein paar Meter dichter dran ist, aber eigentlich weiter von der Zentrale - bei teilweise schlechteren Funkverhältnissen - entfernt ist.

Die Entfernung zwischen Zentrale und Aktor ist die eine Sache. Aber HF ist da komisch. Da kann eine Verbindung über Reflektionen und mit weniger Feldstärke stabiler sein, als die vermeintliche Direktverbindung (weil vielleicht ein Störer dazwischen sitzt). Insofern kann man das nicht so pauschal sagen. Ich denke mal schon, dass sich da einige Leute Gedanken drum gemacht haben und Zentrale und Aktor die Verbindungsqualität selbst bewerten. Wichtig ist der Signal-Rausch-Abstand und nicht unbedingt nur die Feldstärke.

Gruß Xel66