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:
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:
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
Hi,
Kannst Du das
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, ...
Auch mit verbose 5 steht da nicht mehr:
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
war der pi spannungsfrei beim ab- und anstecken?
sind die schnittstellen noch richtig wie im wiki konfiguriert?
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:
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
Zitat von: curt am 15 November 2019, 17:14:38
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
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?
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
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.
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
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.)
Ja, mach mal. Ich suche dann raus, was wichtig ist und kann das ja anonymisieren und online stellen, dann sehen wir weiter.
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
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.