Schaltsteckdosen unter Windows mut CUL warten immer 3s timeout

Begonnen von joffi, 19 September 2019, 16:06:04

Vorheriges Thema - Nächstes Thema

joffi

Hallo ich betreibe FHEM unter Windows 10. Bei meinem nanoCUL funktioniert das schalten zwar problemlos, allerdings habe ich immer app-Laufzeiten >3000ms.
in der cul.pm wird ein timeout von 3000ms definiert um auf die Antwort zu warten:my $to = 3;                                         # 3 seconds timeout
  $mculdata = $hash->{PARTIAL} if(defined($hash->{PARTIAL}));

  $to = $ohash->{RA_Timeout} if($ohash->{RA_Timeout});  # ...or less
  for(;;) {

    if($^O =~ m/Win/ && $hash->{USBDev}) {
      $hash->{USBDev}->read_const_time($to*1000); # set timeout (ms)
      # Read anstatt input sonst funzt read_const_time nicht.
      $buf = $hash->{USBDev}->read(999);
      return ("Timeout reading answer for get $arg", undef)
        if(length($buf) == 0);

    } else {

Ist das normal? Ich habe das Gefühl, dass FHEM für diese 3s immer blockiert ist. Ausprobiert habe ich es mit der aktuellen aculfw und auch mit der aktuellen culfw. Bei beiden zeigt sich das gleiche Verhalten. Weiß jemand Rat?

KölnSolar

Eine cul.pm gibt es nicht.(oder etwa unter Windows ?  :-\)
Ein CUL wartet eigentlich nie auf eine Antwort, weil die implementierten einfachen Protokolle nur unidirektional sind. Etwa bei Windows ?  :-\ Und in welchem Kontext steht Dein Source-Extrakt ?

Grüße Markus
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

joffi

Hi, der Code Auszug ist aus 00_CUL.pm!
und wenn ich mir die Variable $buf logge sehe ich nach 3s die Antwort der Schaltsteckdose. Und danach wird der Schaltzustand in FHEM geändert.
Ist meiner Meinung nach bidirektional.

KölnSolar

Aha, aus der 00_CUL.pm. Die steuert eher nicht das Sendeverhalten.

Den Ausschnitt, den Du gepostet hast, ist nur für Befehle vom CUL-device, also sowas wie get CUL CCCONF. Sendebefehle eines devices über den CUL haben mit der 00_CUL.pm wenig zu tun. Das passiert auf OS-Ebene. Mehr oder weniger einfach nur Daten an den CUL(die culfw) schicken und fertig. Da wird nicht gewartet. Es wird also nur unidirektional gesendet.
RPi3/2 buster/stretch-SamsungAV_E/N-RFXTRX-IT-RSL-NC5462-Oregon-CUL433-GT-TMBBQ-01e-CUL868-FS20-EMGZ-1W(GPIO)-DS18B20-CO2-USBRS232-USBRS422-Betty_Boop-EchoDot-OBIS(Easymeter-Q3/EMH-KW8)-PCA301(S'duino)-Deebot(mqtt2)-zigbee2mqtt

joffi

Hi,
und was liest die 00_CUL.PM denn da vom USBDev? Wenn ich den Timeout $to auf 2s verringere geht es um eine s schneller (d.h. FHEM Statusänderung geht schneller) und in der Variable $buf steht der so wie ich es sehe ob der schaltbefehl ausgeführt wurde.
2019.09.19 20:53:34 3: myCUL IT_set: Brst_st1 off
2019.09.19 20:53:34 5: SW: is0000F0FFFFF0
2019.09.19 20:53:37 5: CUL/RAW (ReadAnswer): is0000F0FFFFF0
Hier sieht man dass CUL/ RAW(ReadAnswer) genau nach 3 sec kommt.