MQTT2_SERVER timing Problem / retained Verzögerung per Attribut

[Guybrush]

bei einem batteriebetriebenen Home Buttons ist mir aufgefallen, dass retained Messages beim kurzen Wakeup nicht mehr rechtzeitig ankommen.

Ursache ist offenbar die feste Verzögerung im MQTT2_SERVER:

Code Auswählen Erweitern

InternalTimer($hash->{lastMsgTime}+1, sub(){

Mit

Code Auswählen Erweitern

InternalTimer($hash->{lastMsgTime}+0.05, sub(){

funktioniert es zuverlässig. Leider erschließt sich mir nicht die Verzögerung. Das find ich auch nirgends in den Protokoll Docs selbst.

Vorschlag: Verzögerung über ein optionales Attribut konfigurierbar machen, Default weiterhin 1, z. B.:

Code Auswählen Erweitern

attr MQTT2_Server retainDelay 0.05

Patch Vorschlag:

Code Auswählen Erweitern

diff --git a/FHEM/00_MQTT2_SERVER.pm b/FHEM/00_MQTT2_SERVER.pm
index XXXXXXX..XXXXXXX 100644
--- a/FHEM/00_MQTT2_SERVER.pm
+++ b/FHEM/00_MQTT2_SERVER.pm
@@ -2263,6 +2263,7 @@ sub MQTT2_SERVER_Initialize($) {
   rePublish:1,0
   rawEvents
+  retainDelay
   respectRetain:1,0
   sslVersion
   sslCertPrefix
@@ -3058,7 +3059,8 @@
   if(!$hash->{answerScheduled} && $shash->{retain}) {
     $hash->{answerScheduled} = 1;

-    InternalTimer($hash->{lastMsgTime}+1, sub(){
+    InternalTimer($hash->{lastMsgTime}+AttrNum($sname, "retainDelay", 1), sub(){
       return if(!$hash->{FD});
       delete($hash->{answerScheduled});
Damit bleibt das bisherige Verhalten unverändert und Geräte mit sehr kurzem Wake-Fenster können einen kleineren Wert nutzen.

[TomLee]

Kannst Du das nicht einfach mit einem userReadings (edit: oder notify) lösen und damit dein Kommando schicken?

Beispiel:

Code Auswählen Erweitern

attr Devicename userReadings disp_msg:temperature {my $text='MeinText';fhem("set MQTT2_Server publish {BASE_TOPIC}/{DEVICE_NAME}/cmd/disp_msg $text");return "$text"}
Der Button meldet sich mit der Temp und direkt wird das Kommando gesendet.
Verstehe es so, das der Befehl dann noch innerhalb des "Wach-Fenster" ankommt.

[Guybrush]

die idee ist gut, aber das problem ist eher die reihenfolge. der home buttons verbindet sich und schickt seine messages. direkt danach beendet der sich und geht wieder in deep sleep. retained messages werden hingegen schon direkt beim verbindungsaufbau geschickt. praktisch wäre es besser wenn der home buttons z.b. noch für ne sekunde online blieb, aber die haben das konsequent auf akku verbrauch getrimmt, was ansich ja ok ist. dafür ist ja eigentlich das retained flag auch da

[TomLee]

direkt danach beendet der sich und geht wieder in deep sleep.

Verstehe, dachte ich auch schon dran. Aber hast es mal probiert oder ist es nur eine Vermutung das er direkt nach dem Publish wieder schläft?

[rudolfkoenig]

Leider erschließt sich mir nicht die Verzögerung.

Ein Client kriegt nur die Nachrichten, die er abonniert hat, das gilt fuer retained auch.
Da ich nicht fuer jedes Client notieren wollte, welche retained Nachrichten schon gesendet wurden, habe ich angenommen, dass ein Client alle subscriptions innerhalb einer Sekunde nach dem ersten subscription abgesetzt hat.
Nicht ganz sauber, hat aber Vorteile

Patch Vorschlag:

Habs eingebaut.
Faellt auf, dass solche Vorschlaege nur selten an die Dokumentation denken.

direkt danach beendet der sich und geht wieder in deep sleep. retained messages werden hingegen schon direkt beim verbindungsaufbau geschickt.

retained messages werden nach dem ersten subcribe Nachricht geschickt, nicht nach dem connect, Erklaerung siehe oben.
Wenn das Geraet sich direkt nach dem connect und publish verabschieden wuerde, wuerde dein Patch nicht helfen.

[Guybrush]

danke @rudolfkoenig.

ich habs mit +0.05 getestet, das ging.

hier noch der patchvorschlag für die doku:

Code Auswählen Erweitern

diff --git a/FHEM/00_MQTT2_SERVER.pm b/FHEM/00_MQTT2_SERVER.pm
--- a/FHEM/00_MQTT2_SERVER.pm
+++ b/FHEM/00_MQTT2_SERVER.pm
@@ -XXXX,6 +XXXX,10 @@
  <li><a href="#MQTT2_SERVER-attr-respectRetain">respectRetain</a></li>
+  <li><a href="#MQTT2_SERVER-attr-retainDelay">retainDelay</a></li>
@@ -XXXX,6 +XXXX,12 @@
+  <a id="MQTT2_SERVER-attr-retainDelay"></a>
+  <li>retainDelay<br>
+    Delay in seconds before retained messages are sent after a subscription.
+    Default: 1.
+  </li><br>
+
@@ -XXXX,6 +XXXX,10 @@
  <li><a href="#MQTT2_SERVER-attr-respectRetain">respectRetain</a></li>
+  <li><a href="#MQTT2_SERVER-attr-retainDelay">retainDelay</a></li>
@@ -XXXX,6 +XXXX,12 @@
+  <a id="MQTT2_SERVER-attr-retainDelay"></a>
+  <li>retainDelay<br>
+    Verzögerung in Sekunden, bevor retained Nachrichten nach einem Subscribe
+    gesendet werden. Standard: 1.
+  </li><br>


[TomLee]

Faellt auf, dass solche Vorschlaege nur selten an die Dokumentation denken.

Agenten, lesen, was im Quellverzeichnis liegt, das Wiki nur wenn man sie drauf hinweist.

Ich hab gestern gelernt, dass eine AGENTS.md mit Regeln und Informationen für Mensch und Assistent hilfreich sein kann. Wäre hier vielleicht auch was.

[Guybrush]

wo steht das denn im wiki? ich halte das für zu hoch erwartet, wenn man davon ausgeht, dass jeder den inhalt des wikis kennt oder immer vorher reinguckt, bevor man hier was schreibt 

[rudolfkoenig]

Ich habe ja bei meinem Kommentar auch an das Commandref gedacht (und die Doku selbst dazugebaut).

[TomLee]

wo steht das denn im wiki?

https://wiki.fhem.de/wiki/How_to_write_a_patch

ich halte das für zu hoch erwartet, wenn man davon ausgeht, dass jeder den inhalt des wikis kennt oder immer vorher reinguckt, bevor man hier was schreibt

Darum ja meine indirekte Frage ob hier in FHEM so was wie eine zentrale "Richtliniendatei" auch denkbar wäre.