[Gelöst] HM-MOD-RPI-PCB funktioniert nicht mehr

Begonnen von ThorHoff, 15 Oktober 2021, 19:28:15

Vorheriges Thema - Nächstes Thema

ThorHoff

Hallo

villeicht kann mir jemand helfen; Auf einmal geht meine HMUART auf meinem RASPI 3b (GPIO) nicht mehr

Bekomme folgende Meldung


2021.10.15 19:09:47 1: HMUARTLGW myHmUART did not respond for the 1. time, resending
2021.10.15 19:09:50 1: HMUARTLGW myHmUART did not respond for the 2. time, resending
2021.10.15 19:09:53 1: HMUARTLGW myHmUART did not respond for the 3. time, resending
2021.10.15 19:09:56 1: HMUARTLGW myHmUART did not respond after all, reopening



Habe alles probiert - und aktuell auch alle USB -Geräte raus - . restart und reopen -  Auch den Raspi runtergefahren und Modul neu eingesteckt
Jetzt bin ich ratlos

Anbei der list


Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DevState   0
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FUUID      5ca8668a-f33f-5cbc-0916-7dd0f54fb4477048
   LastOpen   1634317783.48864
   NAME       myHmUART
   NOTIFYDEV  global
   NR         59
   NTFY_ORDER 50-myHmUART
   PARTIAL   
   STATE      closed
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     3
         time       1634317784.70545
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   PeerQueue:
     HASH(0x471fb20)
     HASH(0x4727928)
     HASH(0x4719b60)
     HASH(0x471a090)
     HASH(0x463a888)
     HASH(0x4714fd0)
     HASH(0x46fb280)
     HASH(0x47180d8)
     HASH(0x47276b8)
     HASH(0x470f638)
     HASH(0x4144a88)
     HASH(0x46fb400)
     HASH(0x47105b8)
     HASH(0x4716598)
     HASH(0x4712ab8)
     HASH(0x4714ad8)
     HASH(0x471cf28)
     HASH(0x46f65b8)
     HASH(0x4725318)
     HASH(0x471ede8)
     HASH(0x4724cd0)
     HASH(0x4725348)
     HASH(0x4719788)
     HASH(0x4719cb8)
     HASH(0x4723a18)
     HASH(0x471c5c0)
     HASH(0x471cca0)
     HASH(0x4727bb8)
   Peers:
     39F16D     pending
     44BE01     pending
     44BE63     pending
     46416C     pending
     4A6CC0     pending
     4C7A56     pending
     4F44FF     pending
     4F47B6     pending
     553EA2     pending
     555911     pending
     578A58     pending
     578B82     pending
     578BBE     pending
     58E90F     pending
     68D433     pending
     68D466     pending
   READINGS:
     2021-10-15 18:41:09   D-HMIdAssigned  6A5C29
     2021-10-15 18:41:09   D-HMIdOriginal  6A5C29
     2021-10-15 18:41:09   D-firmware      1.4.1
     2021-10-15 18:41:09   D-serialNr      PEQ0532381
     2021-10-15 19:09:06   D-type          HM-MOD-UART
     2021-10-15 19:09:56   cond            disconnected
     2021-10-15 18:42:06   load            0
     2021-10-15 19:09:06   loadLvl         suspended
     2021-10-15 19:12:01   state           closed
   helper:
Attributes:
   hmId       6A5C29
   room       raspi->Kommunikation
   verbose    5

Raspi3b+/ raspi 4b
Signalduino/conbee II/Duofern/HMIP-USB
FHEM/Somfy/Rademacher/HM/HMIP (piVCCU)/Zigbee

frank

debmatic, auf der selben maschine wie fhem, "krallt" sich ggf beim booten den hmuart.
pivccu auch?
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

ThorHoff

Ja, ich habe eine piVCCU laufen mit einem HMIP-USB-STICK auf dem selben RASPI , habe aber vor FHEM auf einem separaten RASPI umzuziehen
ebenso habe ich auch einen Conbee und Rademacher Stick

Der Raspi scheint die platine auch sauber zukennen. Die Prüfungen

ls -l /dev/ttyAMA0
ls -l /dev/serial*

liefern das korrekte Ergebnis

Ich habe inzwischen auch festgestellt, das bei das Device initialUsBCheck , warum auch immer, gelöscht war. Nun neu erzeugt.

Das Gehäuse vom RASPI drückt auch etwas auf die HMMODRPIMOD- Platine. Ich lasse gearde den Deckel mal ab

...und siehe da ...jetzt gehts wieder

Das mit dem 'krallen' erscheint mir noch die einleuchteste Erklärung

Kann man das irgendwo erkennen...im FHEM logfile konte ich das nicht rauslesen

Grüße

  Thorsten

und nun läuft es wieder....

Raspi3b+/ raspi 4b
Signalduino/conbee II/Duofern/HMIP-USB
FHEM/Somfy/Rademacher/HM/HMIP (piVCCU)/Zigbee