[gelöst] HM-MOD-UART defekt? Umzug PRi 3 RPi 4

curt · 15 November 2019, 17:14:38

Hallo,
ich habe ein von einem freundlichen Menschen aus dem Forum zusammengebautes HM-MOD-UART, hat immer gut funktioniert. In Vorbereitung eines Umzugs von PRi3+ auf RPi4 zog ich das mal von GPIO ab und steckte es wieder auf (stromlos).

Nun pendelt cond zwischen init und disconnected. Und ich habe keine Ahnung ob das Modul defekt ist oder etwas anderes ihm nicht passt. Was tun?

verbose 5:

Code Auswählen


2019-11-15_17:12:18 myHmUART cond: init
2019-11-15_17:12:30 myHmUART cond: disconnected
2019-11-15_17:12:30 myHmUART CONNECTED
2019-11-15_17:12:31 myHmUART cond: init
2019-11-15_17:12:43 myHmUART cond: disconnected
2019-11-15_17:12:43 myHmUART CONNECTED
2019-11-15_17:12:44 myHmUART cond: init
2019-11-15_17:12:56 myHmUART cond: disconnected
2019-11-15_17:12:56 myHmUART CONNECTED

list:

Code Auswählen


Internals:
   CNT        1
   Clients    :CUL_HM:
   DEF        /dev/ttyAMA0
   DevState   1
   DevType    UART
   DeviceName /dev/ttyAMA0@115200
   FD         88
   FUUID      5c52091f-f33f-769b-5a27-24964d4bf50037a4
   LastOpen   1573834350.49479
   NAME       myHmUART
   NOTIFYDEV  global
   NR         46
   NTFY_ORDER 50-myHmUART
   PARTIAL    
   STATE      opened
   TYPE       HMUARTLGW
   XmitOpen   0
   model      HM-MOD-UART
   owner_CCU  VCCU
   .attraggr:
   .attrminint:
   Helper:
     AckPending:
       1:
         cmd        00
         dst        0
         frame      FD00030001009E03
         resend     3
         time       1573834351.49668
     LastSendLen:
       3
     Log:
       IDs:
   MatchList:
     1:CUL_HM   ^A......................
   PeerQueue:
     HASH(0x602e678)
     HASH(0x6038a78)
     HASH(0x604eb40)
     HASH(0x604ede0)
     HASH(0x605cee0)
     HASH(0x604ea50)
     HASH(0x602f778)
     HASH(0x605dd08)
     HASH(0x605da08)
     HASH(0x60609c0)
     HASH(0x6060d80)
     HASH(0x6038538)
     HASH(0x602f508)
     HASH(0x604e828)
     HASH(0x5d516d0)
     HASH(0x5d43740)
     HASH(0x5d86270)
     HASH(0x41e90b0)
     HASH(0x5d44288)
     HASH(0x3b14b60)
     HASH(0x3b14770)
     HASH(0x39667c8)
     HASH(0x41ddd38)
     HASH(0x41dddf8)
     HASH(0x3a1a5e0)
     HASH(0x28a0b28)
     HASH(0x2954e68)
     HASH(0x28ae620)
   Peers:
     30D87D     pending
     32FB4C     pending
     32FB89     pending
     3301C1     pending
     3301CB     pending
     3301D3     pending
     559286     pending
     578BD4     pending
     594BCA     pending
     5953AA     pending
     5A5754     pending
     5A6710     pending
     5A6737     pending
     649FC4     pending
   READINGS:
     2019-11-08 00:00:15   D-HMIdAssigned  FF1312
     2019-11-08 00:00:15   D-HMIdOriginal  670D64
     2019-11-08 00:00:15   D-firmware      1.4.1
     2019-11-08 00:00:15   D-serialNr      PEQ0173073
     2019-11-15 17:05:59   D-type          HM-MOD-UART
     2019-11-15 17:12:31   cond            init
     2019-11-10 20:33:05   load            1
     2019-11-15 17:05:59   loadLvl         suspended
     2019-11-15 17:12:30   state           opened
   helper:
Attributes:
   hmId       FF1312
   readingsSupervision 600,,load
   room       99 System

RaspiLED · 15 November 2019, 19:46:01

Hi,
Kannst Du das

Code Auswählen


attr <Dev> verbose 4

Oder 5 setzen und das log nicht mal zeigen?

Gruß Arnd

Signalduino (Nano, ESP, ...), CUL (Busware, Nano, Maple, ...), Homematic (HM-MOD-UART-RPI, ESP, Maple, ...), LaCrosseGateway (LGW, ESP, ...), 1-wire, ESPEasy, Bravia, Yamaha, ...

curt · 15 November 2019, 20:09:14

Auch mit verbose 5 steht da nicht mehr:

Code Auswählen


2019-11-15_20:06:16 myHmUART cond: disconnected
2019-11-15_20:06:16 myHmUART CONNECTED
2019-11-15_20:06:17 myHmUART cond: init
2019-11-15_20:06:29 myHmUART cond: disconnected
2019-11-15_20:06:29 myHmUART CONNECTED
2019-11-15_20:06:30 myHmUART cond: init
2019-11-15_20:06:42 myHmUART cond: disconnected
2019-11-15_20:06:42 myHmUART CONNECTED
2019-11-15_20:06:43 myHmUART cond: init
2019-11-15_20:06:55 myHmUART cond: disconnected
2019-11-15_20:06:55 myHmUART CONNECTED
2019-11-15_20:06:56 myHmUART cond: init
2019-11-15_20:07:08 myHmUART cond: disconnected
2019-11-15_20:07:08 myHmUART CONNECTED
2019-11-15_20:07:09 myHmUART cond: init
2019-11-15_20:07:21 myHmUART cond: disconnected
2019-11-15_20:07:21 myHmUART CONNECTED
2019-11-15_20:07:22 myHmUART cond: init
2019-11-15_20:07:34 myHmUART cond: disconnected
2019-11-15_20:07:34 myHmUART CONNECTED
2019-11-15_20:07:35 myHmUART cond: init
2019-11-15_20:07:47 myHmUART cond: disconnected
2019-11-15_20:07:47 myHmUART CONNECTED
2019-11-15_20:07:48 myHmUART cond: init
2019-11-15_20:08:00 myHmUART cond: disconnected
2019-11-15_20:08:00 myHmUART CONNECTED
2019-11-15_20:08:01 myHmUART cond: init

frank · 15 November 2019, 20:15:16

war der pi spannungsfrei beim ab- und anstecken?
sind die schnittstellen noch richtig wie im wiki konfiguriert?

curt · 15 November 2019, 20:19:34

Zitat von: frank am 15 November 2019, 20:15:16
war der pi spannungsfrei beim ab- und anstecken?

Ja.

Zitat von: frank am 15 November 2019, 20:15:16
sind die schnittstellen noch richtig wie im wiki konfiguriert?

Ich habe nichts geändert. Gab es denn Änderungen in Updates in letzter Zeit? Bitte welcher Wiki-Artikel konkret?

P.S: Ich sehe im allgemeinen Log:

Code Auswählen


2019.11.15 20:20:21 1 : HMUARTLGW myHmUART did not respond for the 1. time, resending
2019.11.15 20:20:21 5 : HMUARTLGW myHmUART send: (8): fd00030001009e03
2019.11.15 20:20:21 5 : SW: fd00030001009e03

andies · 16 November 2019, 07:38:54

Zitat von: curt am 15 November 2019, 17:14:38

Code Auswählen Erweitern
DEF /dev/ttyAMA0

das könnte es sein, https://wiki.fhem.de/wiki/HM-MOD-RPI-PCB_HomeMatic_Funkmodul_f%C3%BCr_Raspberry_Pi#Anbindung_mit_USB-Adapter

Gesendet von iPad mit Tapatalk Pro

curt · 16 November 2019, 07:57:25

Ich habe Deine Antwort nicht wirklich verstanden. Das liegt an mir, Hardware war nie so mein Ding, ich kann nicht basteln.

Also meinen HM-MOD-UART bekam ich vollständig zusammengebaut von einem freundlichen Kollegen dieses Forums. Er steckt auf GPIO und sieht auch genau so aus wie in dem von Dir verlinkten Beitrag.

Das Problem war schon beim RPi3, also am RPi4 kann das nicht liegen. Und wenn ich etwas umstecke (und sei es nur USB) ist der RPi immer stromlos - das kann es auch nicht sein ... dann eher noch "Fettfinger".

Ein Softwareproblem kann ich nicht völlig ausschließen: Tatsächlich fahre ich vor solchen Aktionen immer ein Betriebssystem-Update und ein FHEM-Update. Und da schaue ich tatsächlich nicht nach ob alle Hardware danach noch funktioniert.

Meine ursprüngliche Frage war ja: Kann ich irgendwie testen, ob das Modul überhaupt noch lebt?

andies · 16 November 2019, 08:06:06

ich hatte überlesen, dass das am GPIO steckt.

Das wird jetzt nicht einfach. Ich würde erstmal davon ausgehen, dass die GPIO nicht durchgebrannt sind (einmal falsch stecken plus Strom reicht da aber!). Wenn das Gerät auch nicht defekt sein sollte, kann es zuerst nur ein Treiberproblem sein. Ich weiss nicht, wie der Stick mittels GPIO angesprochen wird - ist das seriell? Da gab es mW Änderungen bei der Firmware, da musste man beim booten was einstellen. Aber da bin ich nicht firm drin.

Gesendet von iPad mit Tapatalk Pro

curt · 16 November 2019, 08:10:49

Ich bin mir völlig sicher, dass ich nicht falsch steckte. Das liegt schon daran, dass ich wegen meiner Untalentiertheit bei Hardware da höchsten Respekt habe. Andererseits kann ich natürlich nicht ausschließen, dass ich da irgendwo mit den Fingern rankam.

Im Grunde brauche ich eine Idee, wie ich erstmal testen kann, ob das Ding überhaupt noch lebt.

Oder jemand, der mir so ein fertig zusammengebautes Ding (ich kann das wirklich nicht selbst) verkauft: Damit wüssten wir dann, ob die Hardware hin ist - oder ob es ein ganz anderes Problem gibt.

andies · 16 November 2019, 08:13:53

kannst du den rpi beim booten beobachten? kannst du den boot-log posten? da würde ich jetzt weitersuchen. Wenn diese firmware für den fehler verantwortlich ist, müsste das dort zu finden sein.

(also die sachen unter /var/log)

Gesendet von iPad mit Tapatalk Pro

curt · 16 November 2019, 08:30:54

Klar weiß ich, was syslog und messages ist. Ich weiß aber nicht, wonach genau ich da suchen sollte.

Öffentlich posten möchte ich beide Dateien nicht - wäre PN an Dich ok?
(Das wird aber vielleicht erst heute abend.)

andies · 16 November 2019, 09:12:30

Ja, mach mal. Ich suche dann raus, was wichtig ist und kann das ja anonymisieren und online stellen, dann sehen wir weiter.

deimos · 16 November 2019, 09:33:11

Hi,

wie sieht deine /boot/config.txt aus? Wenn das dort nicht richtig konfiguriert ist, wird das Device /dev/ttyAMA0 nicht auf die GPIOs geleitet.

Viele Grüße
Alex

curt · 17 November 2019, 00:10:42

Waaaaaaaaa

Also auf RPi-3 war schon Buster, allerdings als Upgrade von Stretch. Um das (ohne Neuinstallation) auf RPi-4 zu nutzen, muss man die Boot-Partion vergrößern sowie die Inhalte einer Buster-Neuinstallation dort (nur /boot) hintun.

Bei der Gelegenheit kommt eine neue config.txt ins Spiel ... und die Tatsache, dass ich mich nicht erinnerte, dass da was zu ändern ist.

https://wiki.fhem.de/wiki/Raspberry_Pi#Verwendung_UART_f.C3.BCr_Zusatzmodule eingearbeitet - und sofort geht alles wieder. Sehr schön.

Ich bedanke mich sehr herzlich bei allen, die mithalfen und Hilfe anboten!

P.S: Es muss IMHO weiter pi3-miniuart-bt heißen (nicht pi4-miniuart-bt!). Warum das so ist - überblicke ich nicht.

PP.S: Subject angepasst.