Credits werden durch häufige Zeitsynchronisierung sinnlos verbraucht

[traveltheworld]

@Reiner:

bzgl. der Broadcasts und deren Verteilung über den Tag: die "Broadcast time to .." Nachricht kommt bei zwei verschiedenen Ereignissen:

a) stündlicher Broadcast: wenn das MAX-Modul in FHEM entscheidet, dass die TimeInformation an Thermostate verteilt werden sollen. Das macht das Modul eh schon per modulo. So wie ich es im Code sehe, fix kodiert auf 6 Stunden verteilt. D.h. jedes Thermostat bekommt 4x täglich die aktuelle Zeit.

b) bei expliziter Anfrage (was unser Problem hier ist): bei mir kommen von 11 Thermostaten die Anfragen von genau denen, die mit dem Wandthermostat verbunden sind (plus dem Wandthermostat selbst). Bei mir ist es auch so, dass die Anfragen mehrfach stündlich kommen, und dann jedesmal exakt dreimal mit exakt 5s Abstand voneinander.
Seltsam ist, dass in einem zweiten MAX-Setup von mir dieses Verhalten nicht zu beobachten ist. Einzigen Unterschied, den ich sehe, ist, dass in dem fehlerfreien Setup keine Thermostat+, sondern die älteren Thermostate verbaut sind. Keine Ahnung, ob das einen Unterschied macht.

Eine Frage an dich: inwiefern hilft es, nur einen ACK zu senden? Zählt dieser nicht zur 1%-Regelung, oder ist einfach die Anzahl der notwendigen Credits für diesen viel geringer?

Noch eine Frage/Idee zur Diskussion: würde es evtl. helfen, die Zeitrequests erstmal zu puffern und nur zu beantworten, wenn innerhalb von z.B. 1min kein weiterer identischer Request kommt?

[Reinerlein]

Hi traveltheworld,

das mit dem Ack ist nur eine Idee, und der Gedanke dahinter ist tatsächlich der, dass dafür hoffentlich weniger Credits verbraucht werden würden
Des Weiteren: Brauchen die Geräte wirklich viermal am Tag eine Zeitsynchronisation? Laufen die wirklich so schnell signifikant auseinander?
Sonst würde doch einmal täglich reichen. Wie geschrieben, verbrauchen die drei (bzw. einmal vier) Geräte, die da jede Stunde versorgt werden, zwischen 600 und 900 Credits. Die müssen ja auch erstmal mühsam wieder angespart werden...

Bei mir sind in jedem Raum Wandthermostate (9 Stk.) und Heizungssteller (10 Stk.), die natürlich jeweils miteinander gepeert sind. In einem Raum befinden sich dann zwei Steller...

Das mit dem Puffern der Zeitrequests würde sich mit meiner Idee erledigen, bei der man nur dann mit einer TimeInformation antwortet, wenn die übertragene Zeit nicht korrekt ist (sagen wir mal: mehr als zwei/drei Sekunden Abstand hat).
Bei deiner Variante hat man auch erstmal das Problem, dass die Geräte eine Antwort erwarten, und die Funkanzeige vor sich hin blinkt... Das wollte ich mit der Idee des ACKs in den Griff bekommen...

Grüße
Reiner

[Reinerlein]

Hallo zusammen,

kann mir denn jemand helfen, wie ich ein passendes Ack-Paket für die TimeInformation erzeuge?
Ich bekomme das nicht irgendwie hin.

Danke schon mal...

Grüße
Reiner

[traveltheworld]

Hi Reiner,

bist du sicher, dass ein ACK helfen wird?
Wenn ich mir die eingehenden ACKs zu verschiedenen Befehlen anschaue, sind die eigentlich immer 14 Bytes lang, manchmal 11 Bytes.
Die Timeinformation Messagelänge ist 15 Bytes..

evtl. schau ich auch nicht richtig zu später Stunde..?

[Reinerlein]

Hi traveltheworld.

hmm, das wäre ja blöd... Dann hilft ja doch nur unterdrücken (bei nahezu korrekter Zeit), und diesen stündlichen, unaufgeforderten Versand weiter ausdünnen.
Und natürlich damit leben, dass die Teile eine Weile blinken. Die hören ja anscheinend irgendwann auf, ich habe nur noch nicht beobachtet wann...

OK, ich schaue mal, was sich machen läßt...

Grüße
Reiner

[traveltheworld]

Nun, allein der Header hat schon 10 Bytes, plus dann halt noch die payload mit den eigentlichen Daten.

http://culfw.de/commandref.html#cmd_Z

Send out an MORITZ message. <hex> is a hex string of the following form: llnnccttssssssddddddpp...
ll - length
nn - msg counter
cc - control byte
tt - msg type
ss - sender address (3byte)
dd - destination address (3byte - 000000 for broadcast)
pp - payload...

[traveltheworld]

Hat sich bei dir inzwischen etwas ergeben?

ich habe noch etwas getestet: ich habe zwei MAX-Setups, völlig unabhängig voneinander. Bei dem einen habe ich massiv das hier thematisierte Problem, in dem anderen gar nicht.
Dort, wo ich das Problem nicht habe, hatte ich erst nur die HT im Einsatz (kein HT+), jetzt habe ich allerdings einen defekten HT durch einen HT+ ausgetauscht, und zack, nach wie vor kein Problem. Daran kann es also nicht liegen.

Vermutung: kann es evtl. daran liegen, wie die Geräte miteinander gepairt / associated sind?
In der fehlerfreien Installation schaut es wie folgt aus:
- WTs und HTs sind alle direkt mit FHEM gepaired
- WTs und HTs sind beidseitig associated
- HTs und FKs sind einseitig associated (HT associate FK, d.h. HT empfängt Befehle von FK)

In der Installation mit dem seltsamen TimeInformation Verhalten hätte ich gedacht, habe ich das genauso aufgesetzt, bin mir aber nicht mehr sicher.
Wie hast du das aufgesetzt?

[Reinerlein]

Hi,

also ich habe alle Geräte miteinander assoziiert.
HT <-> WT
FK <-> HT
FK <-> WT
jeweils in die eine und die andere Richtung.

Das soll auch laut Beschreibung so, da sonst nicht auf die jeweilige Antworten (ACKs) gewartet wird (und sonst auch keine Wiederholungssendung durchgeführt wird).
Nur Fhem ist nur mitlauscher

Im Anhang mal meine CUL_MAX. Bei mir läuft das stabil. Ich habe keine nennenswerten Verluste an Credits mehr, und die Geräte blinken auch nicht wild rum...

Ich habe dort:
- Die Push-Aktualisierung der Zeit auf 10 Slots erweitert (bei mir also nur noch 2 Geräte pro Slot)
- Wenn eine Uhrzeit-Anforderung kommt, wird der mitgelieferte Zeitstempel auf eine Abweichung größer 10 Sekunden geprüft, und nur dann beantwortet
- Das Logging dazu entsprechend erweitert (Ausgabe erfolgt auf Verbose-Level 1)
- Im Log sieht man auch, dass die Geräte untereinander Zeitinformationen austauschen (auch auf Level 1)

Einmalig sollte man die Slot-Informationen in den Devices zurücksetzen, damit sie einen neuen zugeordnet bekommen. Sonst hast du zwar 10 Slots, aber es werden nur die alten 6 verwendet. Das sollte man auch machen, wenn man seine Installation nachträglich signifikant erweitert:

Code: [Auswählen]

deletereading TYPE=MAX:FILTER=r:TimeInformationHour=.* TimeInformationHour
Das löscht in allen Max-Geräten, die dieses Reading gesetzt haben, ebendieses Reading weg...

Grüße
Reinerlein

[traveltheworld]

Hallo Reinerlein,

Danke für die schnelle Antwort.
Deine Modifikation werde ich möglichst bald austesten und Dir dann auch Feedback geben.
Verstehe ich richtig, dass du im Falle von einer Zeitabweichung <=10s ein ACK schickst, ansonsten die gewünschte Zeitinformation (auch wenn beide Nachrichten ca. gleich lang sind), und das den wesentlichen Unterschied in der Kommunikation macht?

In der fehlerfreien Installation sehe ich auch, dass die Geräte untereinander die Informationen austauschen (vom WT zum HT), allerdings auf Debug Level 5

Der Punkt mit dem ACK an den FK ist valide, denn es kommt tatsächlich manchmal (wenn auch sehr selten) vor, dass ein Öffnen/Schließen nicht erkannt wird.

LG

[Reinerlein]

Hi,

ich sende keine ACKs, da wir ja festgestellt haben, dass die genauso groß sind
Ich ignoriere einfach die Anfrage, wenn die Zeitabweichung geringer als 10s ist.

Das mit dem Debug-Level habe ich absichtlich gemacht, damit ich nicht alle 5er Infos sehen muss, ich es aber immer noch abschalten kann...

Grüße
Reinerlein

[traveltheworld]

Guten Morgen,

okay, d.h. wir sind nach wie vor bei der Symptombekämpfung..
Wie oft beantwortest du nun tatsächlich einen Zeitupdate-Request? D.h. wie oft kommt es vor, dass die Zeit >10s abweicht? Driften die Zeiten in den Thermostaten so schnell ab?
Genau das (nur ohne die 10s-Abweichung-Bedingung) hatte ich auch schon getestet, aber ich wundere mich nun, wieso bei dir die Funksymbole nicht blinken ohne Antwort..

LG

[traveltheworld]

die modifizierte CUL_MAX ist leer.. da ist wohl was schiefgegangen.

[Reinerlein]

Hi,

ich habe die Datei mal neu angehangen...

Eine Aktualisierung kommt vor, teilweise auch zweimal hintereinander, aber nicht so oft, das es meine Credits kaputt macht... Komisch ist das aber schon, die Mikroprozessoren scheinen teilweise eine echt signifikante Abweichung zu besitzen...

Die blinken sicherlich mal kurz, aber nicht ständig... auf jeden Fall ist irgendwann alles wieder normal...

Es wäre ja auch interessant zu wissen, ob man diese Zeitinformation nicht auch einfach als Broadcast an alle gleichzeitig senden kann. Das müsste ja nicht unbedingt als Unicast über die (Broadcast-)Funkschnittstelle laufen.
Wenn ich mir das Protokoll hätte ausdenken müssen, hätte ich sowas auf jeden Fall eingebaut
Ich kann ja mal versuchen, was passiert, wenn man das einfach an alle sendet...

Grüße
Reinerlein

[Edi77]

Hallo,

Habe ähnliche Probleme mit 2 CUL's vielleicht kann mal jemand was dazu schreiben https://forum.fhem.de/index.php/topic,82600.msg757064.html#msg757064

[Reinerlein]

Hi Edi77,

du kannst einfach mal die Moduldatei von mir ausprobieren. Die zentrale Änderung sind zusätzliche Logausgaben auf Level 1 und die Verhinderung von Timeinformations-Antworten bei einer Abweichung kleiner 10 Sekunden...
Außerdem werden die regelmäßigen Zeitaktualisierungen auf 10 Slots verteilt (dazu nicht vergessen das Reading "TimeInformationHour" zu löschen).

Das macht also nix kaputt. Wenn es hilft, dann sollten wir das mal Richtung offizielles Release bringen. Vielleicht konfigurierbar...

Grüße
Reinerlein

P.S.: Als Crack würde ich mich aber bei weitem nicht bezeichnen wollen