FHEM Forum

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:

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

Mit

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.:

attr MQTT2_Server retainDelay 0.05

Patch Vorschlag:

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.

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

Beispiel:

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.

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

Zitatdirekt 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?

ZitatLeider 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 :)

ZitatPatch Vorschlag:

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

Zitatdirekt 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.

danke @rudolfkoenig.

ich habs mit +0.05 getestet, das ging.

hier noch der patchvorschlag für die doku:
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>


ZitatFaellt 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.

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  :P

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

Zitatwo steht das denn im wiki?

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

Zitatich 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 :P

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