Max! Duty Cycle schnell voll, Homegear sendet dauernd an die Geräte?!

[Larx]

Ich bin auf etwas gestossen, was vielleicht meine unerklärlichen Kommunikationsaussetzer erklären könnte: Der duty cycle ist gem. Logfiles immer sehr schnell voll, ich kann nicht einmal ein Wochenprogramm an einen Thermostaten übertragen, ohne das ein Fehler kommt.

Ich weiß, dass Max! da heikel ist, aber mit dem Cube wäre mir so eine Einschränkung noch nie aufgefallen.

Beim Scannen der Logs ist mir aufgefallen, dass Homegear mindestens 10x pro Stunde, auch in der Nacht, etwas sendet:

09/16/19 02:32:47.639 Module MAX: CUL "MaxCUL": Info: Sending (MaxCUL, WOR: no): 0B9F0202FDAE3C11B4930000

Dann käme bspw. mein Programm, aktiv gesendet:

09/16/19 05:09:55.902 Module MAX: CUL "MaxCUL": Info: Sending (MaxCUL, WOR: yes): 195C0010FDAE3C0782B100004C42585B50C058F04D2079207920

und dann quasi umgehend

9/16/19 05:10:05.028 Module MAX: CUL "MaxCUL": Warning: CUL with id MaxCUL reached 1% limit. You need to wait, before sending is allowed again.

Was mache ich hier falsch? Warum ist der duty cycle so schnell voll? Ich habe keinerlei Skripts o.ä. die begründen würden, dass ständig gefunkt werden müsste.

EDIT: Was macht eigentlich Homegear, wenn der duty cycle voll ist? Später senden? Kann es sein, dass dann nach und nach uralte gequeuete Signale noch Stunden später abgearbeitet werden?

EDIT 2: OK, ein Blick in die Logs hilft weiter:
09/16/19 05:29:51.635 Module MAX: Info: Queue 1 is empty and there are no pending queues.

Es bleibt die Frage, wie es kommt, dass der duty cycle so wahnsinnig schnell erreicht ist.

[Larx]

Ich führe das Selbstgespräch mal fort:

Immer wieder, zu für mich völlig unerklärlichen Zeitpunkten, tritt der o.a. Fehler auf. Ich habe keine Skripte, die etwas an Max! senden sollten, und ich ändere gerade so gut wie nie was an den Thermostaten, weder per Software noch direkt, da sie auf “Auto” laufen.

Warum sendet Homegear trotzdem etwas? Bei OpenHAB ist es bspw. so, dass die Thermostate zyklisch abgefragt werden, um die aktuellen Temperaturen zu bekommen (der originale Cube macht das nicht). Macht das Homegear auch so?

Ich habe 9 Thermostate, ein Wandthermostat und viele Fensterkontakte. Kann es sein, dass das System hier an seine Grenzen stösst? (Mit Cube hat es funktioniert.)

Ich bin kurt davor, auf Homematic umzusteigen, weil das Max!-System zu viele kleine und große Macken hat, die durch meinen Umstieg vom Cube auf Homegear+CUL nicht weg sind, sondern nur anders gelagert sind. Macht dieser (teure) Gedankengang Sinn?

[Larx]

Ich habe es mal weiter beobachtet: Bei meinem Setup sendet der CUL ziemlich regelmäßig 22x pro Stunde folgendes:
Module MAX: CUL "MaxCUL": Info: Sending (MaxCUL, WOR: no): 0BBC0202FDAE3C0FFDE40000
Jede Nummer taucht 3x auf.

Theorie: Das sind Kontaktaufnahmen mit den Thermostaten (5 Stück, zusätzlich ein Wandthermostat, der 4 weitere ansteuert) wegen der aktuellen Temperatur.

Kann das sein? Und ist das der Grund, warum mein duty cycle permanent überfüllt ist? Und wenn ja, was dagegen machen?

@sathya?!?

[pmayer]

Kann das eventuell helfen: MAX: Homegear empfängt nichts mehr

Ich weiß, anderes Problem. Aber eventuell fixt die nightly es ja…

[Larx]

Ich probier mal einen nightly build…

[Micha]

Das gleiche Problem hab ich auch, auch mit den aktuellen nightlies. Ich hab es auf das Protokoll “geschoben” und mich ehrlich gesagt auch nicht weiter drum gekuemmert.

– Micha

[Larx]

Wie schon erwähnt, bei OpenHAB kann man im MaxCube-Binding einstellen, dass regelmäßig die Thermostate getriggert werden. Nur so übertragen sie die aktuelle Temperatur. Ich musste das ausschalten, weil es meinen (ungeflashten) Cube dadurch mit schöner Regelmäßigkeit gecrasht hat.
Ich weiß nicht, wie es die Ansteuerung über Homegear/CUL handhabt, wenn dort auch eine regelmäßige Abfrage der Ist-Temperatur durch Kontaktieren der Thermostate implementiert wäre, wäre das vielleicht eine Erklärung.

[Larx]

Kann bestätigen, bei den Nightlies ist es genauso…

[sathya]

Hallo @Larx,

erst einmal das grundsätzliche Problem:

1. Wake-on-Radio (WOR) ist eine nette Sache, wenn Geräte sofort reagieren sollen. Leider wird die sofortige Reaktion durch großen Dutycycle-Verbrauch und Strombedarf der Geräte erkauft. Letzteres vor allem, weil immer alle Geräte aufwachen, auch, wenn nur eines angesprochen wird. Bei MAX! lässt sich im Gegensatz zu HomeMatic WOR jedoch leider nicht deaktivieren.
2. Bei MAX! dauert das WOR-Signal (das Senden der Preamble) eine Sekunde. Der Dutycycle beträgt 1% einer Stunde, heißt 36 Sekunden. Das heißt, es können pro Stunde und kommunizierendes Gerät nur 36 Pakete gesendet werden. Das ist sehr wenig (bei HomeMatic sind es fast dreimal soviel und ohne WOR ein vielfaches soviel).

Jetzt zu Homegear: Homegear queued alle Pakete und sendet sie, sobald dies möglich ist. Bei Variablen überschreibt ein erneutes Setzen des Wertes das alte Paket. Bei Konfigurationsparametern werden alte Pakete nicht entfernt (das wäre nicht unmöglich, aber deutlich komplexer als bei den Variablen). Wenn jetzt aufgrund des Dutycyclelimits ein Paket nicht gesendet werden konnte, versucht Homegear dieses nach 15 bis 45 Minuten noch einmal zu senden (falls dies wieder fehlschlägt nach 10 Minuten noch einmal, dies habe ich korrigiert auf wieder 15 bis 45 Minuten).

Ich hoffe, die Info hilft weiter.

Viele Grüße

Sathya

[Larx]

Danke für die ausführliche Erklärung. Bei meiner Anzahl von Geräten heißt das, dass alleine das zyklische Abfragen den duty cycle so gut wie ausnutzt?!

Was mich halt wundert, ist, dass mir das mit Max!Cube nie so aufgefallen ist. Ich hatte dafür auch eine Android-App (MaxRemote?), die den duty cycle angezeigt hat. Zumindest laut dieser Anzeige gab es da nur selten Probleme.

[sathya]

Du könntest ein Log ab Homegearstart posten, dann kann ich mal schauen, was genau passiert.

[Larx]

Werde ich machen. Lustigerweise ist das Problem vorerst nicht mehr aufgetreten, seit ich am Wochenende die gesamte Installation 1:1 auf einen neuen RPi 4 kopiert habe. Ich kann da zwar keinen direkten Zusammenhang sehen, aber natürlich geben die Logs daher vorerst noch nix her.
(Am “alten” RPi waren in der homegear.err teilweise seitenlange Warnungen wegen der 1%-Regel, am neuen bislang noch gar nix.)

[Larx]

Hallo @sathya,

muss noch mal nachhaken, nachdem ich doch wieder von dem Problem getroffen werde:

Warum sendet Homegear denn eigentlich rund um die Uhr WOR-Signale an die angeschlossenen Geräte, auch ohne Benutzeraktivität? Bei meiner Anzahl an Geräte führt dies natürlich nach der von dir dargelegten Berechnungsmethode dazu, dass der duty cycle eigentlich permanent am Limit ist.

Solange keine aktive Änderung am System erforderlich ist (z.B. Temperatur-Einstellung über Homegear) ist aktives Senden des CUL e-doch eigentlich nur nötig, um die aktuelle Temperatur abzurufen (da die Max!-Geräte diese m.W. ansonsten nur unregelmäßig aktualisieren). Das macht das Original-System auch nicht.

Wäre es eine Möglichkeit, die WOR-Frequenz konfigurierbar zu machen bzw. an die Anzahl der vorhandenen Geräte anzupassen?

[sathya]

Hallo @Larx,

Warum sendet Homegear denn eigentlich rund um die Uhr WOR-Signale an die angeschlossenen Geräte

Tut es nur für Zeitpakete, wenn ein Gerät die Uhrzeit benötigt. Und zwar zwei Mal täglich. Ansonsten sollten nur gequeute Konfigurationsparameter gesendet werden, also vom Benutzer gesetzte Parameter. In diesem Fall (und nur in diesem Fall) werden gequeute Variablen auch mit eingereit, diese benötigen aber dann kein erneutes WOR.

Viele Grüße

Sathya

[Larx]

Sorry, hätte ich vielleicht hier noch anfügen sollen:

Das Problem war vielleicht ganz was anderes: Ich habe vor ein paar Wochen meine Konfiguration 1:1 von einem RPi3B mit MicroSD auf einen RPi4 mit USB3.0-SSD überspielt. CUL und Pi waren recht nahe zueinander positioniert (unverändert).
Nachdem ich irgendwo gelesen hatte, dass USB3.0 gerne Funk stört, habe ich den CUL weiter weg vom Pi montiert. Seitdem habe ich kein Problem mehr mit der 1%-Regel, auch wenn HomeGear weiterhin 22x pro Stunde irgendetwas sendet (siehe Log oben).
Die RSSI-Werte usw. waren aber auch bei der alten Konstellation völlig unverdächtig im grünen Bereich, die haben sich jetzt nicht verbessert?!

[sathya]

Hallo @Larx,

Seitdem habe ich kein Problem mehr mit der 1%-Regel, auch wenn HomeGear weiterhin 22x pro Stunde irgendetwas sendet (siehe Log oben).

0B9F0202FDAE3C11B4930000

das ist ein ACK-Paket. Da müsste vorher ein eingehendes Paket im Log sein.

Könntest du mir doch noch einmal ein Log einer Stunde schicken? Ich würde mir das gerne noch einmal ansehen. Von Homegear aus sollten nur zwei Mal am Tag Zeitpakete gesendet werden und nur, falls das Gerät eine Zeitanzeige hat.

Viele Grüße

Sathya

[Larx]

homegear.log (105,1 KB)

Hier ein Log-Ausschnitt von gestern abend. Ich habe da aktiv rein gar nix am Max-System rumgestellt, weil das 99% der Zeit auf Automatik läuft. OpenHAB sollte eigentlich von sich auch ja auch nicht rumpfuschen, ich habe keine Regeln o.ä. laufen.

Ggf. sind das auch alles nur ACK-Pakete? Wie gesagt, seit der CUL weiter vom RPi entfernt ist, führt das auch nicht mehr zum Duty-Cycle-Problem…

[sathya]

Hallo @Larx,

vielen Dank! Da sind drei Zeitpakete (0Fnn0003...), der Rest sind ACKs mit WOR: no, also alles in Ordnung. Im aktuellen Nightly sind noch ein paar Verbesserungen in der MAX!-Kommunikation implementiert.

Viele Grüße

Sathya