[gelöst] HMUARTLGW disconnected

[ronzo]

Per Zufall habe ich gerade folgendes gesehen:

Code Auswählen Erweitern

2020.11.05 09:37:27 1 : hmlangw03.lan:2000 reappeared (hmLanGw03)
2020.11.05 09:37:31 1 : HMUARTLGW hmLanGw03 did not respond for the 1. time, resending
2020.11.05 09:37:34 1 : HMUARTLGW hmLanGw03 did not respond for the 2. time, resending
2020.11.05 09:37:37 1 : HMUARTLGW hmLanGw03 did not respond for the 3. time, resending
2020.11.05 09:37:40 1 : HMUARTLGW hmLanGw03 did not respond after all, reopening

Es scheint auf den ersten Blick aber zu laufen:

Code Auswählen Erweitern

pi@hmlangw03:~ $ sudo systemctl status hmlangw
● hmlangw.service
   Loaded: loaded (/etc/systemd/system/hmlangw.service; enabled; vendor preset:
   Active: active (running) since Thu 2020-11-05 09:34:17 CET; 1min 6s ago
Main PID: 222 (socat)
   CGroup: /system.slice/hmlangw.service
           └─222 /usr/bin/socat TCP4-LISTEN:2000,fork,reuseaddr /dev/ttyAMA0,raw

Nov 05 09:34:17 hmlangw03 systemd[1]: Started hmlangw.service.

Wie debugge ich das?

(Für mich richt es ein kleines Bisschen nach Hardware, da es das erste Modul war, das ich zusammengelötet habe...)

[frank]

netzwerk problem?
zeig mal ein list vom hmuart.
wie ist der genau angebunden?

[ronzo]

Netzwerkproblem kann ich ausschließen. Ein

Code Auswählen Erweitern

telnet hmlangw03.lan 2000

funktioniert.

Hier ein List:

Code Auswählen Erweitern

nternals:
   CNT        0
   Clients    :CUL_HM:
   DEF        uart://hmlangw03.lan:2000
   DevState   0
   DevType    UART
   DeviceName hmlangw03.lan:2000
   FD         81
   FUUID      5ecec1bb-f33f-88ea-3f65-eeb40340d5d01319
   LastOpen   1604569840.73413
   NAME       hmLanGw03
   NOTIFYDEV  global
   NR         86
   NTFY_ORDER 50-hmLanGw03
   PARTIAL   
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   owner_CCU  VCCU
   .attraggr:
   .attrminint:
   Helper:
     DBLOG:
       state:
         DBLogging:
           TIME       1604569840.73433
           VALUE      CONNECTED
     Log:
       Resolve    1
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   PeerQueue:
     HASH(0x5615d31ab8f0)
     HASH(0x5615d2991938)
     HASH(0x5615d32e1560)
   Peers:
   READINGS:
     2020-10-30 11:11:13   D-HMIdAssigned  13D5A5
     2020-10-30 11:11:13   D-HMIdOriginal  646FAE
     2020-10-30 11:11:13   D-firmware      1.4.1
     2020-10-30 11:11:13   D-serialNr      OEQ2300319
     2020-11-05 09:34:30   D-type          HM-MOD-UART
     2020-11-05 10:50:40   cond            disconnected
     2020-10-30 11:11:57   load            0
     2020-11-05 09:34:30   loadLvl         suspended
     2020-11-05 10:50:40   state           opened
   helper:
Attributes:
   hmId       13D5B

Sehe aber auch:

Code Auswählen Erweitern

2020-11-05 10:52:51 CUL_HM VCCU hmLanGw01:ok,hmLanGw02:ok,hmLanGw03:disconnected
2020-11-05 10:52:51 HMUARTLGW hmLanGw03 CONNECTED
2020-11-05 10:52:52 HMUARTLGW hmLanGw03 cond: init

[Otto123]

FHEM zu dem Zeitpunkt blockiert?

Das passiert jetzt ständig?

[ronzo]

hmlangw01 und 02 funktionieren tadellos. Beim 03 sehe ich die Meldungen ständig, ja.

Wüsste nicht was in FHEM blockieren würde...

[Otto123]

Dann kannst Du als Erstes nur nach alten Methode "debuggen" - die "Räder" tauschen und schauen ob der "Platten" mitwandert 
Es gab ja hier die eine oder andere Meldung das Module kaputt gegangen sind.

[ronzo]

Du meinst das PCB-Rad? 

[Otto123]

genau - dort würd ich anfangen. Wenn gesteckt ist das doch einfach.

[ronzo]

Mach ich. Hatte ohnehin schon länger das Gefühl, dass das 03er nicht zuverlässig funktioniert...

[ronzo]

Radwechsel vollzogen. Fehler geblieben.

OS ist Raspbian Buster. Der hmlangw03 unterscheidet sich bei mir von den anderen LanGws nur durch die Tatsache, dass die Phoscon-Software deConz drauf ist.

[ronzo]

Als nächstes tausch ich mal den Pi selbst.

[ronzo]

Pi getauscht. Probleme verschwunden.

[MadMax-FHEM]

Bzgl. phoscon/deCONZ und HMUART gab's hier schon mal nen Thread...

Oder ist das beim neuen PI auch drauf?

Gruß, Joachim

[ronzo]

deCONZ macht keinerlei Probleme. Es dürfte tatsächlich das RPI-Board (ein 1er) was gehabt haben...

[Otto123]

gemeint war das hier https://forum.fhem.de/index.php/topic,116428.msg1107317.html#msg1107317