HMUARTLGW queue full und Device not initialized but asked to send data

XXL-Wing · 10 Dezember 2018, 19:01:59

Servus,

danke für die vielen Rückmeldungen

Ich habe die Erhöhung des verbose Levels nach dem stacktrace Aufruf eingefügt.

Seit der vorgeschlagenen Änderung mit dem @ack ist kein stacktrace mehr aufgetreten.
Soweit zur guten Nachricht.
Die schlechte ist dass seither das LAN CFG Modul öfter in kurzen Abständen offline geht, sich dann wieder für ein paar Stunden fängt. Kann Zufall sein aber die Häufigkeit entspricht etwa der Anzahl der stacktraces....

Code Auswählen


2018.12.10 16:48:57 1: HMLAN_Parse: HMLANWZ new condition disconnected
2018.12.10 16:48:57 1: 192.168.0.12:1000 disconnected, waiting to reappear (HMLANWZ)
2018.12.10 16:48:57 1: HMLAN_Parse: HMLANWZ new condition disconnected
2018.12.10 16:48:58 1: HMLAN_Parse: HMLANWZ new condition init
2018.12.10 16:48:58 1: 192.168.0.12:1000 reappeared (HMLANWZ)
2018.12.10 16:48:58 1: HMLAN_Parse: HMLANWZ new condition ok
2018.12.10 16:49:48 1: 192.168.0.12:1000 disconnected, waiting to reappear (HMLANWZ)
2018.12.10 16:49:48 1: HMLAN_Parse: HMLANWZ new condition disconnected
2018.12.10 16:49:48 1: HMLAN_Parse: HMLANWZ new condition init
2018.12.10 16:49:48 1: 192.168.0.12:1000 reappeared (HMLANWZ)
2018.12.10 16:49:48 1: HMLAN_Parse: HMLANWZ new condition ok
2018.12.10 16:50:13 1: 192.168.0.12:1000 disconnected, waiting to reappear (HMLANWZ)
2018.12.10 16:50:13 1: HMLAN_Parse: HMLANWZ new condition disconnected
2018.12.10 16:50:13 1: HMLAN_Parse: HMLANWZ new condition init
2018.12.10 16:50:13 1: 192.168.0.12:1000 reappeared (HMLANWZ)
2018.12.10 16:50:13 1: HMLAN_Parse: HMLANWZ new condition ok
2018.12.10 16:52:17 3: UWZ Unwetterzentrale: Run.1219 Done fetching data
2018.12.10 16:58:08 1: 192.168.0.12:1000 disconnected, waiting to reappear (HMLANWZ)
2018.12.10 16:58:08 1: HMLAN_Parse: HMLANWZ new condition disconnected
2018.12.10 16:58:08 1: HMLAN_Parse: HMLANWZ new condition init
2018.12.10 16:58:08 1: 192.168.0.12:1000 reappeared (HMLANWZ)
2018.12.10 16:58:08 1: HMLAN_Parse: HMLANWZ new condition ok

lG
Mike

frank · 10 Dezember 2018, 20:01:15

hat der hmlan fw0.965?

gritob · 11 Dezember 2018, 10:47:26

Hier ist ja einiges passiert wieder

Ich konnte mein Problem zwar nicht nicht lösen aber zumindest tritt es nicht mehr alle halbe Stunde bis Stunde auf sondern nur noch einzeln verteilt über den Tag. Hat es vielleicht doch was damit zu tun, dass sich die Thermostate immer mehr Konfigurationen gezogen haben? Ich werde aber mal die entsprechenden Zeilen Code ändern und dann mal weiter Info hier preisgeben, vielleicht wurde die Lösung ja schon gepostet.

gritob · 11 Dezember 2018, 11:00:21

Zitat von: mgernoth am 04 Dezember 2018, 20:16:21
Hallo,

Was ist 5C1747? Diese Konfigurationsmessage für dieses Geräts löst das Problem aus.

Was hier passiert ist, dass CUL_HM in einer Endlosschleife diese Message sendet. Die Meldungen von HMUARTLGW sind nur Symptom, nicht Ursache. Ich hatte das auch einmal bisher, konnte es aber nicht reproduzieren und damit auch nicht debuggen...

Kannst Du bitte mal ein List von 5C1747 posten?

Viele Grüße
Michael

sorry ganz übersehen. hier das list:

Code Auswählen

Internals:
   DEF        5C1747
   IODev      3051_PEQ0174459
   NAME       HM_5C1747
   NOTIFYDEV  global
   NR         2549
   NTFY_ORDER 50-HM_5C1747
   STATE      CMDs_pending
   TYPE       CUL_HM
   channel_01 HM_5C1747_Weather
   channel_02 HM_5C1747_Climate
   channel_03 HM_5C1747_WindowRec
   channel_06 HM_5C1747_remote
   channel_07 HM_5C1747_SwitchTr
   READINGS:
     2018-12-11 10:57:53   Activity        unknown
     2018-12-03 18:13:13   CommandAccepted yes
     2018-11-15 17:28:53   D-firmware      1.3
     2018-11-15 17:28:53   D-serialNr      OEQ0849210
     2018-11-23 13:22:14   PairedTo        0x45FF96
     2018-11-23 13:22:14   R-burstRx       on
     2018-11-23 13:22:14   R-cyclicInfoMsg on
     2018-11-23 13:22:14   R-cyclicInfoMsgDis 0
     2018-11-23 13:22:14   R-pairCentral   0x45FF96
     2018-11-23 13:22:14   RegL_00.        01:01 02:01 09:01 0A:45 0B:FF 0C:96 0F:00 11:00  12:16 16:00 18:00 19:00 1A:00
     2018-11-23 14:18:45   RegL_07.        
     2018-12-11 01:30:40   battery         ok
     2018-12-11 01:30:40   batteryLevel    2.9
     2018-12-11 01:30:40   desired-temp    21.0
     2018-12-11 01:30:40   measured-temp   20.4
     2018-12-03 18:28:34   state           CMDs_pending
   helper:
     HM_CMDNR   221
     mId        00AD
     regLst     ,0
     rxType     6
     expert:
       def        1
       det        0
       raw        1
       tpl        0
     io:
       newChn     +5C1747,00,00,00
       prefIO     
       rxt        0
       vccu       VCCU0
       p:
         5C1747
         00
         00
         00
     mRssi:
       mNo        
     prt:
       bErr       0
       sProc      0
     q:
       qReqConf   00
       qReqStat   
     role:
       dev        1
       prs        1
     shRegW:
       07         02
     tmpl:
Attributes:
   IODev      3051_PEQ0174459
   IOgrp      VCCU0
   actCycle   000:10
   actStatus  unknown
   autoReadReg 5_readMissing
   expert     2_raw
   firmware   1.3
   model      HM-TC-IT-WM-W-EU
   msgRepeat  1
   room       CUL_HM
   serialNr   OEQ0849210
   subType    thermostat
   webCmd     getConfig:clear msgEvents

gritob · 12 Dezember 2018, 09:48:06

Vor einer Stunde ist es wieder passiert. Hier mal mit der Änderung am Code:

Code Auswählen

2018.12.12 08:45:01 5: HMUARTLGW 4160_PEQ0533574 HMUARTLGW_Write: As1001B00145FF965B676F00050000000000
2018.12.12 08:45:01 1: HMUARTLGW 4160_PEQ0533574: Device not initialized (state: 0, disconnected) but asked to send data. Dropping: As1001B00145FF965B676F00050000000000
2018.12.12 08:45:01 1: stacktrace:
2018.12.12 08:45:01 1:     main::HMUARTLGW_Write               called by fhem.pl (1000)
2018.12.12 08:45:01 1:     main::IOWrite                       called by ./FHEM/10_CUL_HM.pm (7191)
2018.12.12 08:45:01 1:     main::CUL_HM_respPendTout           called by fhem.pl (3146)
2018.12.12 08:45:01 1:     main::HandleTimeout                 called by fhem.pl (649)

mgernoth · 12 Dezember 2018, 20:23:25

Hi,

Zitat von: gritob am 12 Dezember 2018, 09:48:06
Vor einer Stunde ist es wieder passiert. Hier mal mit der Änderung am Code:

Code Auswählen Erweitern
2018.12.12 08:45:01 5: HMUARTLGW 4160_PEQ0533574 HMUARTLGW_Write: As1001B00145FF965B676F00050000000000 2018.12.12 08:45:01 1: HMUARTLGW 4160_PEQ0533574: Device not initialized (state: 0, disconnected) but asked to send data. Dropping: As1001B00145FF965B676F00050000000000 2018.12.12 08:45:01 1: stacktrace: 2018.12.12 08:45:01 1: main::HMUARTLGW_Write called by fhem.pl (1000) 2018.12.12 08:45:01 1: main::IOWrite called by ./FHEM/10_CUL_HM.pm (7191) 2018.12.12 08:45:01 1: main::CUL_HM_respPendTout called by fhem.pl (3146) 2018.12.12 08:45:01 1: main::HandleTimeout called by fhem.pl (649)

Vielen Dank, dieser Backtrace sieht eher so aus, wie ich er erwartet hätte. Irgendwo wird ein Resend ständig wiederholt und führt zu dem Problem. "Eigentlich" dürfte das gar nicht passieren können...

Auf Anhieb sehe ich nichts falsches an dem Code, da gibts aber eine Menge Pfade, die zu diesem Zustand führen können...

Woher kommt die Uhrzeit des Systems? Gibt es hier evtl. sync-Vorgänge direkt vor dem Auftreten des Problems, welche das evtl. verursachen könnten?

EDIT: Wenn ich jetzt mal den vorherigen Backtrace ausser acht lasse (evtl. weil er indirekt ausgeloest wurde), dann sind die drei anderen in diesem Thread gemeldeten Pakete Configuration-Pakete an Burst-Devices und auch noch die erste Nachricht an das jeweilige Gerät(As xx 01 B0). Das sieht mir schon sehr nach einer Gemeinsamkeit aus und nicht nach Zufall:

Code Auswählen


As1001B00145FF965C174700050000000000
As1001B001F100004BD52401050000000001
As1001B00145FF965B676F00050000000000

@gritob: 5B676F ist auch ein WT? Kannst Du mal bei allen WT autoReadReg auf 4 runtersetzen?

Viele Grüße
Michael

gritob · 13 Dezember 2018, 17:13:42

5B676F ist auch ein WT korrekt! Habe mal autoReadReg für alle WT auf 4 geändert. Uhrzeit ist ne gute Frage. Bei mir läuft FHEM in einem Ubuntu 16.04.2 LTS in einer ESXI VM. Sind mit Sicherheit die Standard Zeitserver angeben, wie oft da ein sync passiert kann ich da aber nicht sagen.

Hier nochmal von heute morgen:

Code Auswählen

2018.12.13 07:55:01 5: HMUARTLGW 4151_PEQ0533636 HMUARTLGW_Write: As1001B00145FF965B124B00050000000000
2018.12.13 07:55:01 1: HMUARTLGW 4151_PEQ0533636: Device not initialized (state: 2, init) but asked to send data. Dropping: As1001B00145FF965B124B00050000000000
2018.12.13 07:55:01 1: stacktrace:
2018.12.13 07:55:01 1:     main::HMUARTLGW_Write               called by fhem.pl (1000)
2018.12.13 07:55:01 1:     main::IOWrite                       called by ./FHEM/10_CUL_HM.pm (7191)
2018.12.13 07:55:01 1:     main::CUL_HM_respPendTout           called by fhem.pl (3146)
2018.12.13 07:55:01 1:     main::HandleTimeout                 called by fhem.pl (649)

vielleicht auch noch interessant für euch:

Code Auswählen

2018.12.13 07:41:43 1: HMUARTLGW 4151_PEQ0533636: queue is full, dropping packet
2018.12.13 07:41:43 1: HMUARTLGW 4151_PEQ0533636: queue is full, dropping packet

das wird halt vorher gespammt, hatte ich aber schon erwähnt meine ich.

mgernoth · 13 Dezember 2018, 19:03:34

Hi,

Zitat von: gritob am 13 Dezember 2018, 17:13:42
Uhrzeit ist ne gute Frage. Bei mir läuft FHEM in einem Ubuntu 16.04.2 LTS in einer ESXI VM.

Hmm, VM könnte evtl. ein Problem sein, das ist aber sehr unwahrscheinlich. Manchmal synchronisieren die Hypervisor hart von aussen.

Zitat
Hier nochmal von heute morgen:

Hoffentlich bevor Du autoReadReg geändert hast?

Zitat
Code Auswählen Erweitern
2018.12.13 07:55:01 5: HMUARTLGW 4151_PEQ0533636 HMUARTLGW_Write: As1001B00145FF965B124B00050000000000

Ah, Du hast den Vorschlag von noansi umgesetzt

Ist das die einzige HMUARTLGW-Zeile zwischen den Backtraces?

Wenn ja dann ist es eindeutig nicht der Receive-Pfad der da noch dazwischenfunkt.

Zitat
vielleicht auch noch interessant für euch:

Code Auswählen Erweitern
2018.12.13 07:41:43 1: HMUARTLGW 4151_PEQ0533636: queue is full, dropping packet 2018.12.13 07:41:43 1: HMUARTLGW 4151_PEQ0533636: queue is full, dropping packet

das wird halt vorher gespammt, hatte ich aber schon erwähnt meine ich.

Ja, das ist die Vorstufe des gleichen Problems bis dann irgendwann das Modul aufgibt und die "not initialized" Meldung kommt.

Viele Grüße
Michael

gritob · 14 Dezember 2018, 11:36:44

ZitatHmm, VM könnte evtl. ein Problem sein, das ist aber sehr unwahrscheinlich. Manchmal synchronisieren die Hypervisor hart von aussen.

Die VM Konfiguration habe ich so 100+ Mal laufen wenn ich es abschätzen müsste. Unterschied ist hier jetzt nur, dass es hier sehr viele Wandthermostate gibt. Teilweise habe ich noch größere Systeme am laufen, die jedoch nur aus normalen Thermostaten bestehen und die laufen ohne Fehler. Ich konnte den Fehler jetzt auch nochmal bei einem kleineren System beobachten, da gibt es jedoch auch sehr viele Wandthermostate. Ich vermute wirklich, dass es irgendwie damit zusammenhängen muss. Vielleicht hilft das. Ich teste gerne alles und kann den Fehler denke ich sehr schnell reproduzieren, spätestens dann, wenn ich viele getConfigs mache, kann ich es bestimmt sogar erzwingen. Momentan hab ich so eine Bauernlösung am Laufen, dass mir FHEM in einem cronjob killt, wenn es in den Modus fährt und dann wieder hochfährt. Funktioniert zwar aber kann auch keine Dauerlösung sein

ZitatIst das die einzige HMUARTLGW-Zeile zwischen den Backtraces?

Leider ja, das was ich gepostet habe steht dann so quasi gefühlt mehrere 100 Male in der Datei. Ist immer ein anderer HMUART.

Hier nochmal nach der autoReadReg Änderung. Hab hier sogar eine Stelle gefunden wo es 2 betrifft:

Code Auswählen

2018.12.14 07:35:01 5: HMUARTLGW 4151_PEQ0533636 HMUARTLGW_Write: As1001B00145FF965B124B00050000000000
2018.12.14 07:35:01 1: HMUARTLGW 4151_PEQ0533636: Device not initialized (state: 0, disconnected) but asked to send data. Dropping: As1001B00145FF965B124B00050000000000
2018.12.14 07:35:01 1: stacktrace:
2018.12.14 07:35:01 1:     main::HMUARTLGW_Write               called by fhem.pl (1000)
2018.12.14 07:35:01 1:     main::IOWrite                       called by ./FHEM/10_CUL_HM.pm (7191)
2018.12.14 07:35:01 1:     main::CUL_HM_respPendTout           called by fhem.pl (3146)
2018.12.14 07:35:01 1:     main::HandleTimeout                 called by fhem.pl (649)
2018.12.14 07:35:01 5: HMUARTLGW 4160_PEQ0533574 HMUARTLGW_Write: As1001B00145FF965C171400050000000000
2018.12.14 07:35:01 1: HMUARTLGW 4160_PEQ0533574: Device not initialized (state: 3, init) but asked to send data. Dropping: As1001B00145FF965C171400050000000000
2018.12.14 07:35:01 1: stacktrace:
2018.12.14 07:35:01 1:     main::HMUARTLGW_Write               called by fhem.pl (1000)
2018.12.14 07:35:01 1:     main::IOWrite                       called by ./FHEM/10_CUL_HM.pm (7191)
2018.12.14 07:35:01 1:     main::CUL_HM_respPendTout           called by fhem.pl (3146)
2018.12.14 07:35:01 1:     main::HandleTimeout                 called by fhem.pl (649)

noansi · 14 Dezember 2018, 13:26:07

Hallo Michael,

disconnected in den Logs für HMUARTLGW gibt den Zustand von "cond" wieder, nicht aber den von "state", wie es in CUL_HM_respPendTout Zeile 7131 mit

Code Auswählen

    elsif (ReadingsVal($hash->{IODev}->{NAME},"state","") !~ m/^(opened|Initialized)$/){#IO errors
      CUL_HM_eventP($hash,"IOdly");
      CUL_HM_ProcessCmdStack($hash) if($rxt & 0x03);#burst/all
    }

abgefragt wird.

Kann es in dem Zustand bei HMUARTLGW sein, dass "state" auf opened oder Initialized steht, obwohl "cond" disconnected besagt?

Und sollte die Abfrage im CUL_HM code oben nicht eher in

Code Auswählen

    elsif (   (defined $hash->{IODev}->{XmitOpen} && $hash->{IODev}->{XmitOpen} < 1)
           || ReadingsVal($hash->{IODev}->{NAME},"state","") !~ m/^(opened|Initialized)$/ ){#IO errors

geändert werden?
Oder noch besser mit Überlastbehandlung.

Gruß, Ansgar.

noansi · 14 Dezember 2018, 21:42:27

Hallo Michael, hallo Martin,

der Pfad ab Zeile 7174 wird in den letzten Stacktraces in CUL_HM ausgeführt:

Code Auswählen

      else{# normal device resend
        if ($rxt & 0x02){# type = burst - need to set burst-Bit for retry
          if ($pHash->{mmcA}){#fillback multi-message command
            unshift @{$hash->{cmdStack}},$_ foreach (reverse@{$pHash->{mmcA}});
            delete $pHash->{mmcA};
            delete $pHash->{mmcS};
            
            my $cmd = shift @{$hash->{cmdStack}};
            $cmd = sprintf("As%02X01%s", length($cmd)/2, substr($cmd,2));
            $pHash->{rspWait}{cmd} = $cmd;
            CUL_HM_responseSetup($hash,$cmd);
          }

          my ($pre,$tp,$tail) = unpack 'A6A2A*',$pHash->{rspWait}{cmd};
          $pHash->{rspWait}{cmd} = sprintf("%s%02X%s",$pre,(hex($tp)|0x10),$tail);
        }
        IOWrite($hash, "", $pHash->{rspWait}{cmd});
        CUL_HM_eventP($hash,"SndB")          if(hex(substr($pHash->{rspWait}{cmd},6,2)) & 0x10);
        CUL_HM_statCnt($hash->{IODev}{NAME},"s",hex(substr($pHash->{rspWait}{cmd},6,2)));
        InternalTimer(gettimeofday()+rand(20)/10+4,"CUL_HM_respPendTout","respPend:$hash->{DEF}", 0);
      }

CUL_HM_responseSetup setzt $pHash->{rspWait}{reSent} erneut zurück.
Daher vermute ich mal, es sollte der aktuelle {reSent} Wert in {wuReSent} geschrieben werden.
Also folgender Ergänzungsvorschlag, um ständiges Wiederholen zu unterbinden:

Code Auswählen

      else{# normal device resend
        if ($rxt & 0x02){# type = burst - need to set burst-Bit for retry
          if ($pHash->{mmcA}){#fillback multi-message command
            unshift @{$hash->{cmdStack}},$_ foreach (reverse@{$pHash->{mmcA}});
            delete $pHash->{mmcA};
            delete $pHash->{mmcS};
            
            my $cmd = shift @{$hash->{cmdStack}};
            $cmd = sprintf("As%02X01%s", length($cmd)/2, substr($cmd,2));
            $pHash->{rspWait}{cmd} = $cmd;
            $pHash->{wuReSent} = $pHash->{rspWait}{reSent};# save 'invalid' count
            CUL_HM_responseSetup($hash,$cmd);
          }

          my ($pre,$tp,$tail) = unpack 'A6A2A*',$pHash->{rspWait}{cmd};
          $pHash->{rspWait}{cmd} = sprintf("%s%02X%s",$pre,(hex($tp)|0x10),$tail);
        }
        IOWrite($hash, "", $pHash->{rspWait}{cmd});
        CUL_HM_eventP($hash,"SndB")          if(hex(substr($pHash->{rspWait}{cmd},6,2)) & 0x10);
        CUL_HM_statCnt($hash->{IODev}{NAME},"s",hex(substr($pHash->{rspWait}{cmd},6,2)));
        InternalTimer(gettimeofday()+rand(20)/10+4,"CUL_HM_respPendTout","respPend:$hash->{DEF}", 0);
      }

Zur zur ständigen Wiederholung gehört aber auch, dass die Funkverbindung zum device schlecht sein müsste, oder es die Message nicht beantwortet?
Oder die message gar nicht gesendet wird und deswegen keine Antwort kommt.

Gruß, Ansgar.

XXL-Wing · 15 Dezember 2018, 09:19:57

Hallo,

Update von meiner Seite...
Die Logeinträge mit dauerhaften retries sind mit dem neuen ack im Code ausgeblieben, die permanenten disconnects des LAN Configdaapters sind aber geblieben...
Das zweite LAN-GW hat derartige Probleme nicht.
Netzwerkprobleme kann ich ausschließen, der Switch hat nix in den Management logs und auch andere Geräte am selben Switch haben stabile Verbindung...
Firmware Version des LAN-CFG ist
0.964

LG
Mike

frank · 15 Dezember 2018, 11:07:57

dann mach mal ein update auf 0.965.

gritob · 18 Dezember 2018, 11:55:05

Zitat von: noansi am 14 Dezember 2018, 21:42:27
Hallo Michael, hallo Martin,

der Pfad ab Zeile 7174 wird in den letzten Stacktraces in CUL_HM ausgeführt:
Code Auswählen Erweitern
else{# normal device resend if ($rxt & 0x02){# type = burst - need to set burst-Bit for retry if ($pHash->{mmcA}){#fillback multi-message command unshift @{$hash->{cmdStack}},$_ foreach (reverse@{$pHash->{mmcA}}); delete $pHash->{mmcA}; delete $pHash->{mmcS}; my $cmd = shift @{$hash->{cmdStack}}; $cmd = sprintf("As%02X01%s", length($cmd)/2, substr($cmd,2)); $pHash->{rspWait}{cmd} = $cmd; CUL_HM_responseSetup($hash,$cmd); } my ($pre,$tp,$tail) = unpack 'A6A2A*',$pHash->{rspWait}{cmd}; $pHash->{rspWait}{cmd} = sprintf("%s%02X%s",$pre,(hex($tp)|0x10),$tail); } IOWrite($hash, "", $pHash->{rspWait}{cmd}); CUL_HM_eventP($hash,"SndB") if(hex(substr($pHash->{rspWait}{cmd},6,2)) & 0x10); CUL_HM_statCnt($hash->{IODev}{NAME},"s",hex(substr($pHash->{rspWait}{cmd},6,2))); InternalTimer(gettimeofday()+rand(20)/10+4,"CUL_HM_respPendTout","respPend:$hash->{DEF}", 0); }

CUL_HM_responseSetup setzt $pHash->{rspWait}{reSent} erneut zurück.
Daher vermute ich mal, es sollte der aktuelle {reSent} Wert in {wuReSent} geschrieben werden.
Also folgender Ergänzungsvorschlag, um ständiges Wiederholen zu unterbinden:

Code Auswählen Erweitern
else{# normal device resend if ($rxt & 0x02){# type = burst - need to set burst-Bit for retry if ($pHash->{mmcA}){#fillback multi-message command unshift @{$hash->{cmdStack}},$_ foreach (reverse@{$pHash->{mmcA}}); delete $pHash->{mmcA}; delete $pHash->{mmcS}; my $cmd = shift @{$hash->{cmdStack}}; $cmd = sprintf("As%02X01%s", length($cmd)/2, substr($cmd,2)); $pHash->{rspWait}{cmd} = $cmd; $pHash->{wuReSent} = $pHash->{rspWait}{reSent};# save 'invalid' count CUL_HM_responseSetup($hash,$cmd); } my ($pre,$tp,$tail) = unpack 'A6A2A*',$pHash->{rspWait}{cmd}; $pHash->{rspWait}{cmd} = sprintf("%s%02X%s",$pre,(hex($tp)|0x10),$tail); } IOWrite($hash, "", $pHash->{rspWait}{cmd}); CUL_HM_eventP($hash,"SndB") if(hex(substr($pHash->{rspWait}{cmd},6,2)) & 0x10); CUL_HM_statCnt($hash->{IODev}{NAME},"s",hex(substr($pHash->{rspWait}{cmd},6,2))); InternalTimer(gettimeofday()+rand(20)/10+4,"CUL_HM_respPendTout","respPend:$hash->{DEF}", 0); }

Zur zur ständigen Wiederholung gehört aber auch, dass die Funkverbindung zum device schlecht sein müsste, oder es die Message nicht beantwortet?
Oder die message gar nicht gesendet wird und deswegen keine Antwort kommt.

Gruß, Ansgar.

vielleicht nochmal zur info. hab mal die zeile gestern hinzugefügt und bis jetzt ist es noch nicht wieder aufgetreten! ich werde weiterhin beobachten und mich melden.

nachtrag 19.12: bis jetzt immer noch nicht aufgetreten. ich gebe jetzt mal etwas last auf das system mit einigen befehlen um zu sehen, wie es sich dann verhält.

gritob · 28 Dezember 2018, 10:25:16

Nach 10 Tagen ist es immer noch wieder nicht aufgetreten

Anscheinend habt ihr es gelöst für mich!