sleep in while-schleife keine Wirkung?

Begonnen von hmtec99, 02 Dezember 2023, 14:45:49

Vorheriges Thema - Nächstes Thema

hmtec99

Hallo Leute.

Nach Wakeup eines Displays (Nextion) wird der Inhalt einer Datei mit den aktuellen Variablenwerten an das Display gesendet. Da es hierbei ab und an
Probleme gibt, habe ich versucht das Ganze durch ein Sleep zu entzerren.

Dafür verwende ich folgenden Code (hier übertrieben mit 2s zum Test; eigentlich steht hier ein Wert von 0.1 oder weniger - siehe Kommentar)

use Storable;

my %state = %{retrieve('TD_statefile')};

    while(@array=each(%state))
    {
      Log 4, "$array[1]\n";
#   {fhem ("sleep 0.1;set $device $array[1];")};
  {fhem ("sleep 2;set $device $array[1]")};
    }

Problem ist nun, daß die Verzögerung anscheinend keine Auswirkung hat: Die Befehle (ca. 60) werden anscheinend (inkl. Antwort vom Device) innerhalb
von etwas mehr als einer Sekunde abgearbeitet.

Denkfehler/Codefehler meinerseits?

Gruß, Oli
 

hmtec99

Da fällt mir gerade noch was auf:

Ist das abschließende Semikolon beim letzten Befehl nötig oder funktioniert beides?

{fhem ("sleep 0.1;set $device $array[1];")};
{fhem ("sleep 2;set $device $array[1]")};

MadMax-FHEM

Zitat von: hmtec99 am 02 Dezember 2023, 14:45:49Denkfehler/Codefehler meinerseits?
Ja ;)

Also deine Schleife läuft "sofort" und "komplett" durch.
Bei jedem Durchlauf wird ein "verzögerter set" erzeugt aber eben alle quasi "zeitgleich"...

D.h. alles läuft eben um 1x Sleepwert verzögert.

Wenn du in fhem sowas willst, ist eine Möglichkeit eine Sub rekursiv mit Verzögerung aufrufen und dann immer das nächste Stückchen abarbeiten.
Oder die Devices in eine structure packen und dann mit delay arbeiten...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

Jamo

oder die sleep time mit jedem schleifendurchlauf zu inkrementieren...
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

frank

oder den kompletten "string" für einen "fhem" cmd in der schleife zusammenbauen und anschliessend ausführen.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

hmtec99

Bahnhof?  :o

Kann mir jemand meinen Code umbauen, damit es funktioniert?  ;D

Oder mir erklären, was ich anscheinend an der Funktionsweise von while nicht verstehe...

MadMax-FHEM

Zitat von: hmtec99 am 02 Dezember 2023, 18:35:05Oder mir erklären, was ich anscheinend an der Funktionsweise von while nicht verst
Habe ich doch ausführlich?!

Also:

Durchlauf 1: es wird ein Slepp + Befehl abgesetzt
Sofort Durchlauf 2: es wird ein Sleep + Befehl abgesetzt

Aber Sleep1+Befehl2 und Sleep2+Befehl2 usw. werden quasi "zur selben Zeit" erzeugt...

D.h. am Ende der Schleife, die quasi "sofort" durch ist hast du X Sleep+Befehl erzeugt, die aber alle (fast) gleichzeitig loslaufen...

Packe doch einfach mal Logausgaben in deinen Code, dann wirst du es sehen...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

MadMax-FHEM

Zitat von: hmtec99 am 02 Dezember 2023, 18:35:05Kann mir jemand meinen Code umbauen, damit es funktioniert? 
Welche Variante soll es werden? ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

hmtec99

Ist es nicht so?

while(@array=each(%state))  >> mache solange rum, bis kein Futter mehr im Array, und zwar:
    {
      Log 4, "$array[1]\n";  >> schreib was ins Log (falls Level >=4) und
#     {fhem ("sleep 0.1;set $device $array[1];")}; 
     {fhem ("sleep 2;set $device $array[1]")};  >> schlaf ein bißchen, führ anschließend EINEN Befehl aus und fang dann wieder von oben an!?
    }

hmtec99

#9
wenn ich dich richtig verstehe hat, vesetze ich fhem 2 sekunden in den schlaf und sende aber gleichzeitig den befehl ab?

häh??

Im Endeffekt möchte ich erreichen, daß jeder Durchlauf von while um eine Zeit x verzögert wird, das Zieldevice nicht überfordert wird... d.h. ballere nicht 60 Befehle quasi zeitgleich raus sondern mit jeweils minimaler Verzögerung...

Jamo

#10
Aber 'oben' wartet doch nicht, bis der 'eine' Befehl seinen 'sleep 2' fertig hat. Das 'sleep 2' ist nur der erste Teil des 'EINEN' Befehls, der dann sofort ausgefuehrt wird.

>>wenn ich dich richtig verstehe hat, vesetze ich fhem 2 sekunden in den schlaf und sende aber gleichzeitig den befehl ab?

Nein, es wird intern ein timer gestartet, der befehl wird dann erst mit 2 sekunden verspaetung gestartet.
Bullseye auf iNUC, Homematic + HMIP(UART/HMUSB), Debmatic, HUEBridge, Zigbee/Conbee III, FB7690, Alexa (fhem-lazy), Livetracking, LaCrosse JeeLink, LoRaWan / TTN / Chirpstack, Sonos, ESPresence

frober

Der Befehl wird am Fhem gesendet, dann läuft die Schleife weiter.
Fhem wartet parallel 2s und führt den Befehl aus. Während dessen kommen schon neue Befehle von der Schleife in Fhem an.
D.h. du hast das gleiche wie ohne sleep nur 2s später.

Nachtrag: da war Jamo schneller
Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

hmtec99

#12
d.h. das sleep müßte außerhalb von fhem {} stehen (davor)? sorry, I don't get it...

frober

Raspi 3b mit Raspbian Bullseye und relativ aktuellem Fhem,  FS20, LGW, PCA301, Zigbee, MQTT, MySensors mit RS485(CAN-Receiver) und RFM69, etc.,
einiges umgesetzt, vieles in Planung, smile

********************************************
...man wächst mit der Herausforderung...

hmtec99

Zitat von: frober am 02 Dezember 2023, 18:57:49Ja, aber in Perl blockiert es!!!!

das habe ich auch schon gelesen...  ;D