[Gelöst] und [Geklärt] Wechselwirkung Perl-sleep-Funktion <-> FHEM

[fhem_olsi]

Ich habe ein gravierendes Verständnisproblem mit der Auswirkung der Sleep-Funktion im Perl-Script unter FHEM:
Ich habe folgendes Test-Notify:
---------
olsi:.* {
  my $i = 0;;
  for ($i = 10; $i > 0; $i--) {
      Log 1, "Loop index = " . $i;;
      sleep (1);;
      fhem( "set LampePC TOGGLE" );;
  }
}
---------
Es soll(te) also 10 x im Abstand von einer Sekunde eine Lampe abwechselnd ein- und ausgeschaltet werden.
Tut es aber nicht!

Nach Aussage der Log-Datei scheint alles richtig abgearbeitet worden zu sein:
---------------------
2023.03.30 17:43:42 1: Loop index = 10
2023.03.30 17:43:43 3: MQTT2_DEVICE set LampePC TOGGLE
2023.03.30 17:43:43 1: Loop index = 9
2023.03.30 17:43:44 3: MQTT2_DEVICE set LampePC TOGGLE
2023.03.30 17:43:44 1: Loop index = 8
2023.03.30 17:43:45 3: MQTT2_DEVICE set LampePC TOGGLE
2023.03.30 17:43:45 1: Loop index = 7
2023.03.30 17:43:46 3: MQTT2_DEVICE set LampePC TOGGLE
2023.03.30 17:43:46 1: Loop index = 6
2023.03.30 17:43:47 3: MQTT2_DEVICE set LampePC TOGGLE
2023.03.30 17:43:47 1: Loop index = 5
2023.03.30 17:43:48 3: MQTT2_DEVICE set LampePC TOGGLE
2023.03.30 17:43:48 1: Loop index = 4
2023.03.30 17:43:49 3: MQTT2_DEVICE set LampePC TOGGLE
2023.03.30 17:43:49 1: Loop index = 3
2023.03.30 17:43:50 3: MQTT2_DEVICE set LampePC TOGGLE
2023.03.30 17:43:50 1: Loop index = 2
2023.03.30 17:43:51 3: MQTT2_DEVICE set LampePC TOGGLE
2023.03.30 17:43:51 1: Loop index = 1
2023.03.30 17:43:52 3: MQTT2_DEVICE set LampePC TOGGLE
---------------------
Aber in der Praxis geschieht folgendes: Das Perl-Script wird 10 Sekunden lang abgearbeitet, aber bei der Lampe passiert gar nichts. Danach wird die Lampe (rasend schnell ~ 10 Hz?) ein- und wieder ausgeschaltet.
Belegt wird dies auch durch das Protokoll im "Event monitor":
---------------------
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: ON
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: OFF
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: ON
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: OFF
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: ON
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: OFF
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: ON
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: OFF
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: ON
2023-03-30 17:43:52 MQTT2_DEVICE LampePC POWER: OFF
---------------------

Die Situation ist übrigens dieselbe, wenn ich anstatt der Perl-sleep-Funktion die entsprechende FHEM-Funktion gewählt hätte:
{ fhem( "set ....; sleep 1; set ..." ) }

Was habe ich da nicht verstanden?
Für eine Aufklärung wäre ich dankbar...

[Beta-User]

Vorab mal willkommen im FHEM-Forum!

Zum einen sollte man Perl-sleep-Anweisungen unbedingt vermeiden. FHEM tut in der Zeit nämlich sonst nichts (hier offenbar nur kurz den Code einreihen, den das IO dann anscheinend asynchron raushaut).

Bei FHEM-sleep findest du die Lösung in der commandref vermutlich unter "sleep". Man muss die ";" escapen, also für jede Runde verdoppeln.

Falls das Zieldevice das kann, ist vermutlich "blink" aus den SetExtensions für deinen Anwendungsfall interessant.

Ansonsten kannst du das über einen (rekursiven) InternalTimer-Aufruf (oder ein sich selbst wieder definierendes "at") lösen.

Hoffe, das halbwegs verständlich geschrieben zu haben.

Grüße, Beta-User

[Jamo]

Das Perl sleep ist blockierend, wie Beta-User schon geschrieben hat.
Du kannst so was mit einem FHEM sleep machen:

Code Auswählen Erweitern

olsi:.* {
  my $i = 0;;
  for ($i = 10; $i > 0; $i--) {
      Log 1, "Loop index = " . $i;
      fhem( "sleep $i;set LampePC TOGGLE" );
  }
}

[fhem_olsi]

@Beta-User
> Man muss die ";" escapen, also für jede Runde verdoppeln.
Bezieht sich diese Aussage auf meinen Perl-Code? Wenn ja, dann verstehe ich das nicht.

> Falls das Zieldevice das kann, ist vermutlich "blink" aus den SetExtensions für deinen Anwendungsfall interessant.
Mein Anwendungsfall war nicht das Blinken einer Lampe. Dieses war in diesem Fall nur ein Hilfsmittel zur Visualisierung der Zeitabläufe zum Thema "Wechselwirkung Perl-sleep-Funktion <-> FHEM".

Aber danke: Ich glaube, ich habe verstanden...

Ich fasse meine Erkenntnis 'mal so zusammen:

FHEM wartet "in Ruhe" das Abarbeiten des Perl-Scripts ab und sammelt dabei alle angefallenen FHEM-Aktionen (set-Befehle etc.) in einem Puffer. Dann, wenn das Perl-Script beendet ist, werden die FHEM-Aktionen in der angefallenen Reihenfolge schnellstmöglich oder nach durch entsprechende FHEM-Anweisungen vorgegebenen Zeit-Intervallen ausgeführt. Alle während der Abarbeitung angefallenen FHEM-Anweisungen werden quasi nachgeholt, auch solche, die durch andere Ereignisse (in anderen Scripts definiert) ausgelöst wurden.

Ist das ungefähr richtig zusammengefaßt?

Demnach wäre der Perl-Befehl "sleep" für die Nutzung von zeitgesteuerten FHEM-Aktionen völlig ungeeignet.

[Damian]

Ich fasse meine Erkenntnis 'mal so zusammen:

FHEM wartet "in Ruhe" das Abarbeiten des Perl-Scripts ab und sammelt dabei alle angefallenen FHEM-Aktionen (set-Befehle etc.) in einem Puffer. Dann, wenn das Perl-Script beendet ist, werden die FHEM-Aktionen in der angefallenen Reihenfolge schnellstmöglich oder nach durch entsprechende FHEM-Anweisungen vorgegebenen Zeit-Intervallen ausgeführt. Alle während der Abarbeitung angefallenen FHEM-Anweisungen werden quasi nachgeholt, auch solche, die durch andere Ereignisse (in anderen Scripts definiert) ausgelöst wurden.

Ist das ungefähr richtig zusammengefaßt?

Nein. Das wäre noch sehr optimistisch. FHEM wartet nicht "in Ruhe" und macht etwas anderes. FHEM ist im wesentlich ein einziger Prozess. Wenn du Perl-sleep benutzt steht dein FHEM solange, es wartet nicht, und macht auch nichts anderes in dieser Zeit.

Perl-sleep sollte man in FHEM niemals benutzen. Dafür gibt es, wie schon geschrieben, andere Funktionen - unglücklicherweise heißt die echte Warte-FHEM-Funktion in FHEM auch sleep.

[Beta-User]

@Beta-User
> Man muss die ";" escapen, also für jede Runde verdoppeln.
Bezieht sich diese Aussage auf meinen Perl-Code? Wenn ja, dann verstehe ich das nicht.

Nein, das bezieht sich auf FHEM-sleep, siehe die allgemeinen Ausführungen zu "Indirektionen" in https://commandref.fhem.de/commandref_DE.html#command

Ich fasse meine Erkenntnis 'mal so zusammen:

FHEM wartet "in Ruhe" das Abarbeiten des Perl-Scripts ab und sammelt dabei alle angefallenen FHEM-Aktionen (set-Befehle etc.) in einem Puffer. Dann, wenn das Perl-Script beendet ist, werden die FHEM-Aktionen in der angefallenen Reihenfolge schnellstmöglich oder nach durch entsprechende FHEM-Anweisungen vorgegebenen Zeit-Intervallen ausgeführt. Alle während der Abarbeitung angefallenen FHEM-Anweisungen werden quasi nachgeholt, auch solche, die durch andere Ereignisse (in anderen Scripts definiert) ausgelöst wurden.

Ist das ungefähr richtig zusammengefaßt?

Demnach wäre der Perl-Befehl "sleep" für die Nutzung von zeitgesteuerten FHEM-Aktionen völlig ungeeignet.

Nicht komplett korrekt.

Perl-sleep ist absolut zu vermeiden! Diese Schlussfolgerung ist jedenfalls für Einsteiger 100% richtig!

Ansonsten: FHEM "tickt" absolut linear. Wenn also das angesteuerte Modul eine "set-on"-Anweisung direkt umsetzt und auch direkt über das IO absetzt, würde das ggf. auch funktionieren. Hier scheint aber die Umsetzung irgendwie timer-basiert umgesetzt zu sein, so dass eben ZUERST deine (blockierende!) Perl-Schleife abgearbeitet wird, und dann erst die gepufferten Befehle abgearbeitet werden.
Aber was konkret rauskommt, hängt eben stark vom jeweiligen Modulcode ab. Wenn der (imo) "gut" ist, passiert alles timer-basiert und FHEM kann checken, welche nächste Aktion die höchste Prio hat...

Hoffe, das ist jetzt noch klarer?

(Doppel gemoppelt hält vielleicht besser)

[fhem_olsi]

Nein. Das wäre noch sehr optimistisch. FHEM wartet nicht "in Ruhe" und macht etwas anderes. FHEM ist im wesentlich ein einziger Prozess. Wenn du Perl-sleep benutzt steht dein FHEM solange, es wartet nicht, und macht auch nichts anderes in dieser Zeit.

"nichts anderes" scheint mir nicht richtig zu sein!
Es müssen im Hintergrund irgendwelche interrupt-gesteuerte Prozesse ablaufen, während das im Vordergrund laufende Perl-Script den FHEM-Haupt-Prozeß "blockiert". Denn Ereignisse und damit verbundene (andere) Scripte werden offensichtlich registriert (gespeichert) und nachgeholt, sobald das "blockierende" Script abgearbeit ist. Habe ich selbst getestet!

Aber ansonsten: Danke.

[Beta-User]

Es ist richtig!

Dass das OS in der Zeit nicht schläft, ist doch eigentlich selbstverständlich.

 Und dass dein Code "drumrum" irgendwas (unbewußt) in den Hintergrund (als timer) schickt, ist kein Widerspruch dazu, denn das passiert VOR bzw. NACH deinen Perl-sleeps. Wenn dann dein Code um ist, schaut FHEM wieder alle seine "Dateien" an, ob was relevantes dabei ist (=> Events) und arbeitet (u.a. deine) Timer ab...

[Damian]

Nein. Das wäre noch sehr optimistisch. FHEM wartet nicht "in Ruhe" und macht etwas anderes. FHEM ist im wesentlich ein einziger Prozess. Wenn du Perl-sleep benutzt steht dein FHEM solange, es wartet nicht, und macht auch nichts anderes in dieser Zeit.

"nichts anderes" scheint mir nicht richtig zu sein!
Es müssen im Hintergrund irgendwelche interrupt-gesteuerte Prozesse ablaufen, während das im Vordergrund laufende Perl-Script den FHEM-Haupt-Prozeß "blockiert". Denn Ereignisse und damit verbundene (andere) Scripte werden offensichtlich registriert (gespeichert) und nachgeholt, sobald das "blockierende" Script abgearbeit ist. Habe ich selbst getestet!

Aber ansonsten: Danke.

In FHEM gibt es so gut wie keine im Hintergrund laufenden Prozesse. Wenn etwas gepuffert wird, dann eher im Gerätetreiber. Wenn ein FHEM-"Script" durch Perl-sleep blockiert wird, dann läuft kein anderes FHEM-"Script" in dieser Zeit.

[Jamo]

Ich habe meinen Typo oben korrigiert,

Das Perl sleep ist blockierend, wie Beta-User schon geschrieben hat.
Du kannst so was mit einem FHEM sleep machen:

Der code sollte so aber so funktionieren.

[fhem_olsi]

@Jamo:
Hatte ich schon verstanden, ob fettgedruckt oder nicht; keine Sorge!

@Damian:

n FHEM gibt es so gut wie keine im Hintergrund laufenden Prozesse. Wenn etwas gepuffert wird, dann eher im Gerätetreiber. Wenn ein FHEM-"Script" durch Perl-sleep blockiert wird, dann läuft kein anderes FHEM-"Script" in dieser Zeit.

Das kann's einfach nicht sein!
Meine FHEM-Kommunikation läuft komplett - also nur - via MQTT; der Broker (Mosquitto auf demselben PC) "weiß" nichts von FHEM, läuft total asynchron. Da gibt es keinen weiteren "Gerätetreiber", der etwas speichert!!!
Vielleicht ist es das FHEM-Modul "MQTT2_DEVICE" selbst, das alle Infos via Subscribe abholt? Das interrupt-gesteuert läuft?

[Damian]

@Jamo:
Hatte ich schon verstanden, ob fettgedruckt oder nicht; keine Sorge!

@Damian:

n FHEM gibt es so gut wie keine im Hintergrund laufenden Prozesse. Wenn etwas gepuffert wird, dann eher im Gerätetreiber. Wenn ein FHEM-"Script" durch Perl-sleep blockiert wird, dann läuft kein anderes FHEM-"Script" in dieser Zeit.

Das kann's einfach nicht sein!
Meine FHEM-Kommunikation läuft komplett - also nur - via MQTT; der Broker (Mosquitto auf demselben PC) "weiß" nichts von FHEM, läuft total asynchron. Da gibt es keinen weiteren "Gerätetreiber", der etwas speichert!!!
Vielleicht ist es das FHEM-Modul "MQTT2_DEVICE" selbst, das alle Infos via Subscribe abholt? Das interrupt-gesteuert läuft?

Das mag ja alles sein. Dennoch macht es zu keinem Zeitpunkt Sinn die Hauptabarbeitungsschleife für alle FHEM-Module zu blockieren.

[fhem_olsi]

Das mag ja alles sein. Dennoch macht es zu keinem Zeitpunkt Sinn die Hauptabarbeitungsschleife für alle FHEM-Module zu blockieren.

Diese Erkenntnis hatte ich ja schon lange gewonnen; s.o.!
Mit ging's doch um das Verstehen der Wechselwirkungen; versteh' doch!

[Beta-User]

Das kann's einfach nicht sein!
Meine FHEM-Kommunikation läuft komplett - also nur - via MQTT; der Broker (Mosquitto auf demselben PC) "weiß" nichts von FHEM, läuft total asynchron. Da gibt es keinen weiteren "Gerätetreiber", der etwas speichert!!!
Vielleicht ist es das FHEM-Modul "MQTT2_DEVICE" selbst, das alle Infos via Subscribe abholt? Das interrupt-gesteuert läuft?

Nochmal: Was das OS oder andere Prozesse in der Zeit machen, ist in dem Zusammenhang hier völlig wurst.
FHEM reagiert nicht selbst auf "interrupts", das tut ggf. das OS, aber FHEM bekommt davon (bestenfalls) erst nach dem Perl-sleep mit. FHEM ist kein Microcontroller.

Und wenn was gepuffert wird, dann eher nicht im (FHEM-Sprech) Client-Modul (MQTT2_DEVICE), sondern in dem IO-Modul, das es verwendet (hier, da mosquitto: MQTT2_CLIENT).
(War mir aber auch nicht bewußt, dass Rudi das asynchron ausgelegt hat. Cool!)

[fhem_olsi]

Und wenn was gepuffert wird, dann eher nicht im (FHEM-Sprech) Client-Modul (MQTT2_DEVICE), sondern in dem IO-Modul, das es verwendet (hier, da mosquitto: MQTT2_CLIENT).

Einverstanden!

[Damian]

Und wenn was gepuffert wird, dann eher nicht im (FHEM-Sprech) Client-Modul (MQTT2_DEVICE), sondern in dem IO-Modul, das es verwendet (hier, da mosquitto: MQTT2_CLIENT).

Einverstanden!

Der Server kriegt auch nichts mit.

Beweis

Gesendet wird im 10 Sekundentakt.

Code Auswählen Erweitern

2023-04-02_11:02:13 MQTT2_DVES_C58DCB Sleep: 50
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Wifi_SSId: FRITZ!Box 7490 2.4
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Heap: 22
2023-04-02_11:02:13 MQTT2_DVES_C58DCB SleepMode: Dynamic
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Uptime: 0T00:03:21
2023-04-02_11:02:13 MQTT2_DVES_C58DCB UptimeSec: 201
2023-04-02_11:02:13 MQTT2_DVES_C58DCB MqttCount: 1
2023-04-02_11:02:13 MQTT2_DVES_C58DCB LoadAvg: 19
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Wifi_AP: 1
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Wifi_BSSId: B0:F2:08:20:F0:8E
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Wifi_Channel: 5
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Time: 2023-04-02T11:02:13
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Wifi_RSSI: 66
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Wifi_Mode: 11n
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Wifi_Signal: -67
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Wifi_LinkCount: 1
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Wifi_Downtime: 0T00:00:05
2023-04-02_11:02:13 MQTT2_DVES_C58DCB COUNTER_C3: 1322144
2023-04-02_11:02:13 MQTT2_DVES_C58DCB MT681_Total_out: 4573.109
2023-04-02_11:02:13 MQTT2_DVES_C58DCB Time: 2023-04-02T11:02:13
2023-04-02_11:02:13 MQTT2_DVES_C58DCB MT681_Power_cur: 1235
2023-04-02_11:02:13 MQTT2_DVES_C58DCB COUNTER_C2: 551144
2023-04-02_11:02:13 MQTT2_DVES_C58DCB COUNTER_C4: 52277
2023-04-02_11:02:13 MQTT2_DVES_C58DCB MT681_Delivery_cur: 0
2023-04-02_11:02:13 MQTT2_DVES_C58DCB MT681_Meter_id: XXXX
2023-04-02_11:02:13 MQTT2_DVES_C58DCB COUNTER_C1: 44069537
2023-04-02_11:02:13 MQTT2_DVES_C58DCB MT681_Total_in: 3543.831
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Time: 2023-04-02T11:02:23
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Wifi_RSSI: 66
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Wifi_Channel: 5
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Wifi_BSSId: B0:F2:08:20:F0:8E
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Wifi_Downtime: 0T00:00:05
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Wifi_LinkCount: 1
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Wifi_Signal: -67
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Wifi_Mode: 11n
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Heap: 22
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Sleep: 50
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Wifi_SSId: FRITZ!Box 7490 2.4
2023-04-02_11:02:23 MQTT2_DVES_C58DCB MqttCount: 1
2023-04-02_11:02:23 MQTT2_DVES_C58DCB LoadAvg: 19
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Wifi_AP: 1
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Uptime: 0T00:03:31
2023-04-02_11:02:23 MQTT2_DVES_C58DCB UptimeSec: 211
2023-04-02_11:02:23 MQTT2_DVES_C58DCB SleepMode: Dynamic
2023-04-02_11:02:23 MQTT2_DVES_C58DCB COUNTER_C1: 44069538
2023-04-02_11:02:23 MQTT2_DVES_C58DCB MT681_Total_in: 3543.834
2023-04-02_11:02:23 MQTT2_DVES_C58DCB MT681_Meter_id: XXXX
2023-04-02_11:02:23 MQTT2_DVES_C58DCB MT681_Delivery_cur: 0
2023-04-02_11:02:23 MQTT2_DVES_C58DCB COUNTER_C2: 551145
2023-04-02_11:02:23 MQTT2_DVES_C58DCB COUNTER_C4: 52277
2023-04-02_11:02:23 MQTT2_DVES_C58DCB MT681_Power_cur: 1257
2023-04-02_11:02:23 MQTT2_DVES_C58DCB Time: 2023-04-02T11:02:23
2023-04-02_11:02:23 MQTT2_DVES_C58DCB MT681_Total_out: 4573.109
2023-04-02_11:02:23 MQTT2_DVES_C58DCB COUNTER_C3: 1322144
2023-04-02_11:03:31 MQTT2_DVES_C58DCB LWT: Offline
2023-04-02_11:03:32 MQTT2_DVES_C58DCB LWT: Online
2023-04-02_11:03:32 MQTT2_DVES_C58DCB POWER:
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_82: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_17: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sho_1: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB swc_1: -1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB rl_1: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB t: tasmota_C58DCB
2023-04-02_11:03:32 MQTT2_DVES_C58DCB swc_6: -1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_30: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB rl_7: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB btn_6: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB md: Generic
2023-04-02_11:03:32 MQTT2_DVES_C58DCB ver: 1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB rl_3: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_117: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB rl_5: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sw: 9.5.0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_20: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sho_2: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB tp_2: stat
2023-04-02_11:03:32 MQTT2_DVES_C58DCB swc_2: -1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_11: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_68: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB rl_8: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB rl_6: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB swc_7: -1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_4: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB btn_1: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB tp_1: cmnd
2023-04-02_11:03:32 MQTT2_DVES_C58DCB onln: Online
2023-04-02_11:03:32 MQTT2_DVES_C58DCB swc_3: -1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB btn_2: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB state_4: HOLD
2023-04-02_11:03:32 MQTT2_DVES_C58DCB swc_8: -1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB btn_3: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB tp_3: tele
2023-04-02_11:03:32 MQTT2_DVES_C58DCB btn_5: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB state_3: TOGGLE
2023-04-02_11:03:32 MQTT2_DVES_C58DCB lt_st: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB hn: tasmota_C58DCB-3531
2023-04-02_11:03:32 MQTT2_DVES_C58DCB rl_4: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB state_2: ON
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_13: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB if: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB btn_4: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB swc_5: -1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB ofln: Offline
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sho_3: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB rl_2: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sho_4: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB lk: 1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB fn_1: Tasmota
2023-04-02_11:03:32 MQTT2_DVES_C58DCB dn: Tasmota
2023-04-02_11:03:32 MQTT2_DVES_C58DCB ty: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_73: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB ft: %prefix%/%topic%/
2023-04-02_11:03:32 MQTT2_DVES_C58DCB btn_7: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB mac: ECFABCC58DCB
2023-04-02_11:03:32 MQTT2_DVES_C58DCB btn_8: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB so_114: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB state_1: OFF
2023-04-02_11:03:32 MQTT2_DVES_C58DCB swc_4: -1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB ip: 192.168.178.141
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_MT681_Total_in: 3543.837
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_MT681_Total_out: 4573.110
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_COUNTER_C1: 44069543
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_COUNTER_C2: 551151
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_COUNTER_C4: 52277
2023-04-02_11:03:32 MQTT2_DVES_C58DCB ver: 1
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_COUNTER_C3: 1322144
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_MT681_Power_cur: -38
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_MT681_Delivery_cur: 0
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_Time: 2023-04-02T11:03:32
2023-04-02_11:03:32 MQTT2_DVES_C58DCB sn_MT681_Meter_id: XXXX
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Wifi_Downtime: 0T00:00:05
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Wifi_LinkCount: 1
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Wifi_Signal: -67
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Wifi_Mode: 11n
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Time: 2023-04-02T11:03:34
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Wifi_RSSI: 66
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Wifi_Channel: 5
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Wifi_BSSId: B0:F2:08:20:F0:8E
2023-04-02_11:03:34 MQTT2_DVES_C58DCB MqttCount: 2
2023-04-02_11:03:34 MQTT2_DVES_C58DCB LoadAvg: 30
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Wifi_AP: 1
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Uptime: 0T00:04:42
2023-04-02_11:03:34 MQTT2_DVES_C58DCB SleepMode: Dynamic
2023-04-02_11:03:34 MQTT2_DVES_C58DCB UptimeSec: 282
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Heap: 22
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Sleep: 50
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Wifi_SSId: FRITZ!Box 7490 2.4
2023-04-02_11:03:34 MQTT2_DVES_C58DCB MT681_Meter_id: XXXX
2023-04-02_11:03:34 MQTT2_DVES_C58DCB MT681_Total_in: 3543.837
2023-04-02_11:03:34 MQTT2_DVES_C58DCB COUNTER_C1: 44069543
2023-04-02_11:03:34 MQTT2_DVES_C58DCB MT681_Delivery_cur: 0
2023-04-02_11:03:34 MQTT2_DVES_C58DCB Time: 2023-04-02T11:03:34
2023-04-02_11:03:34 MQTT2_DVES_C58DCB MT681_Power_cur: -38
2023-04-02_11:03:34 MQTT2_DVES_C58DCB COUNTER_C2: 551152
2023-04-02_11:03:34 MQTT2_DVES_C58DCB COUNTER_C4: 52277
2023-04-02_11:03:34 MQTT2_DVES_C58DCB MT681_Total_out: 4573.110
2023-04-02_11:03:34 MQTT2_DVES_C58DCB COUNTER_C3: 1322144
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Wifi_SSId: FRITZ!Box 7490 2.4
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Sleep: 50
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Heap: 22
2023-04-02_11:03:44 MQTT2_DVES_C58DCB SleepMode: Dynamic
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Uptime: 0T00:04:52
2023-04-02_11:03:44 MQTT2_DVES_C58DCB UptimeSec: 292
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Wifi_AP: 1
2023-04-02_11:03:44 MQTT2_DVES_C58DCB LoadAvg: 19
2023-04-02_11:03:44 MQTT2_DVES_C58DCB MqttCount: 2
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Wifi_BSSId: B0:F2:08:20:F0:8E
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Wifi_Channel: 5
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Wifi_RSSI: 66
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Time: 2023-04-02T11:03:44
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Wifi_Mode: 11n
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Wifi_Signal: -67
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Wifi_Downtime: 0T00:00:05
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Wifi_LinkCount: 1
2023-04-02_11:03:44 MQTT2_DVES_C58DCB COUNTER_C1: 44069543
2023-04-02_11:03:44 MQTT2_DVES_C58DCB MT681_Total_in: 3543.837
2023-04-02_11:03:44 MQTT2_DVES_C58DCB MT681_Meter_id: XXXX
2023-04-02_11:03:44 MQTT2_DVES_C58DCB MT681_Delivery_cur: 0
2023-04-02_11:03:44 MQTT2_DVES_C58DCB COUNTER_C2: 551152
2023-04-02_11:03:44 MQTT2_DVES_C58DCB COUNTER_C4: 52277
2023-04-02_11:03:44 MQTT2_DVES_C58DCB MT681_Power_cur: -38
2023-04-02_11:03:44 MQTT2_DVES_C58DCB Time: 2023-04-02T11:03:44
2023-04-02_11:03:44 MQTT2_DVES_C58DCB MT681_Total_out: 4573.110
2023-04-02_11:03:44 MQTT2_DVES_C58DCB COUNTER_C3: 1322144

Da wird nichts nachgeholt. Jetzt kannst du mal raten, wann ich sleep 60 auf der Konsole abgesetzt hab'.

[fhem_olsi]

Also, ich habe das jetzt 'mal endgültig geklärt - jenenfalls für mich!

Testaufbau:
1) Rechner (in VirtualBox), der außer bei FHEM nichts mit MQTT zu tun hat.
2) "Frische" FHEM-Installation" d'raufkopiert.
3) Drei Devices gebastelt; eines davon benutzt MQTT (Zigbee Wall Switch).
4) Ein Notify dafür erstellt.
5) Ein at gebaut, das mit einem "Perl sleep command" im Perl-Script, FHEM für längere Zeit schlafen legt, also "blockiert", wie es hier ja immer heißt.
6) Jede Menge Log-Befehle benutzt, um ein ausführliches Bild zu erhalten.
7) Wireshark aktiviert zum Aufzeichnen des MQTT-Schnittstellenverkehrs zwisch FHEM-Rechner und dem PC, auf dem der MQTT-Broker (Mosquitto) läuft.
8 ) Dann - während sich FHEM schlafen gelegt hatte - einen (oder mehrere) Event(s) mit dem Wall Switch ausgelöst.
9) Log-Protokoll und Wireshark-Protokoll gesichtet und ausgewertet.

Der Befund ist klar:

Die Nachricht vom Broker (publish message) für das relevante Event lief während der FHEM-Schlafphase im Rechner ein.

Nach dem Fortsetzen der FHEM-Prozesse fragte FHEM den Boker nicht etwa per Subscribe nach den relevanten Information. Das wäre auch zu gefährlich, da sich der Zustand im Broker jederzeit, also völlig asynchron durch weitere einlaufende Daten ändern kann. Dennoch verarbeitet FHEM die während der Schlafphase eingegangene MQTT-Nachricht (danach) korrekt, holt sie in diesem Sinn also nach!

Also muß trotz der Perl-Sleep-Phase im Vordergrund von FHEM, in der scheinbar alles lahmgelegt ist (leicht nachvollziehbar durch versuchsweises Nutzen von FHEMWEB währenddessen) zumindest das MQTT-IO-Modul von FHEM noch arbeiten. Ich vermute aber, da wird es noch mehr IO-Module geben. Und die werden alle interrupt-gesteuert arbeiten, denn ein Polling im Mikro- oder Millisekundenbereich macht hier wegen der dann entstehenden hohen Prozessor-Last wenig Sinn, da ja wohl kurze Ansprechzeiten erzielt werden sollen.

Und: FHEM muß die während der Schlafphase empfangenen Nachrichten gespeichert haben, da die dafür definierten Aktionen nachgeholt werden. Von dieser Ausdrucksweisen kann mich keiner abbringen!

[Damian]

Wenn du es ganz genau wissen willst, dann kannst du dir den Sourcecode von MQTT2_SERVER anschauen. Die zuständige Routine dürfte MQTT2_SERVER_Read sein.

Und wenn du deine konkreten Fragen im Board Automatisierung stellst, wird dir der Autor (Rudi) sicherlich ganz genau sagen, was wann passiert.

[fhem_olsi]

Wir waren uns doch schon einig, daß nur das Modul "MQTT2_CLIENT" dafür infrage kommt.

Und hier wird man ab Zeile 313 (meine Version: FHEM v6.2) fündig:
sub MQTT2_SERVER_Read($@) {...

Also Socket Programming unter Perl -> interrupt-gesteuerte Prozesse!

Und hier findet man ab Zeile 348 auch Infos zu den Puffer n, die übrigens nur 1024 Bytes groß sind...

[Prof. Dr. Peter Henning]

Starke Worte...

pah

[fhem_olsi]

Starke Worte...

?.?.?

[Beta-User]

Starke Worte...

?.?.?

Wir finden es alle klasse, dass uns endlich jemand erklärt, wie FHEM tickt...

Willkommen im FHEM-Forum!

[fhem_olsi]

Für den Fall, daß das ironisch gemeint sein sollte:

Ich bin nur auf die Hinweise und Anregungen eingegangen, die auf meine Anfrage(n) hin hier gemacht wurden. Und dazu gehörten auch Deine.

Und ich verspüre eine leichte Arroganz...

[Prof. Dr. Peter Henning]

Es ist immerhin gut, dass man seine leichte Arroganz spürt. Dafür ein großes Lob, das ist nämlich der Ansatz zur Selbstverbesserung.

LG

pah

[fhem_olsi]

Nach nunmehr 5 Beiträgen ohne (sachlichen) Inhalt - jetzt 6 -  sollten wir das hier und jetzt beenden; das führt zu nichts...

[Beta-User]

Nach den hier im Forum üblichen Gepflogenheiten könntest du einfach ein [gelöst] oder [geklärt] im Thread-Titel (erster Beitrag) ergänzen, um zu signalisieren, dass das der Fall ist.

Ansonsten: Ja, ich komme aus Ironien. Das liegt am Sarkastischen Meer.

[fhem_olsi]

Nach den hier im Forum üblichen Gepflogenheiten

Danke für den Hinweis; ich hatte nicht ohne Grund im Anfänger-Forum angefragt.

könntest du einfach ein [gelöst] oder [geklärt] im Thread-Titel (erster Beitrag) ergänzen, um zu signalisieren, dass das der Fall ist.

Werde ich machen...

Übrigens: Für Ironie bin ich grundsätzlich zu haben, aber in einem derart "technischen" Forum würde ich das möglichst vermeiden.

[Beta-User]

Nach den hier im Forum üblichen Gepflogenheiten

Danke für den Hinweis; ich hatte nicht ohne Grund im Anfänger-Forum angefragt.

Die betreffenden Hinweise findest du in den angepinnten Threads - im Anfänger-Bereich hier... Sehe also (ironiefrei) keinen Widerspruch.