[gelöst] HM wired: nach Neustart RESPONSE TIMEOUT

M.Piet · 20 November 2018, 18:11:03

Hallo Zusammen,

ich habe schon länger ein HMW_IO_12_Sw14 und ein HMW_Sen_SC_12 in Betrieb. Angeschlossen an einem DIGITUS DA-70157.
Hat bereits unzählige Neustarts des PIs mit gemacht. Heute streiken beide seit einem Neustart und ich finde den Fehler nicht.

state:RESPONSE TIMEOUT

Eingerichtet wurde es streng nach Wiki.

Code Auswählen

Folgendes ist mit in den Logs aufgefallen, wiederholt sich alle paar Sekunden:
2018.11.20 17:31:45 3: hm485: Initialisierung von Modul 0001AAD0
2018.11.20 17:31:46 3: hm485: HM485_QueueStepFailed Call step
2018.11.20 17:31:46 3: HMW_Sen_SC_12_DR_OEQ0863464: RESPONSE TIMEOUT for 0001AAD0
2018.11.20 17:31:49 3: hm485: Initialisierung von Modul 0001482C
2018.11.20 17:31:49 3: hm485: HM485_QueueStepFailed Call step
2018.11.20 17:31:49 3: HMW_IO_12_Sw14_DR_NEQ0308160: RESPONSE TIMEOUT for 0001482C

Habe verbose auf 5 gesetzt und dann einen Discovery gestartet, Hoffe da ist was zu erkennen.
Discovery war um 18:01.
Das Log ist recht groß, habe es versucht entsprechend zu kürzen. Ist im Anhang.
Hat jemand eine Idee? Fehlt noch was an Infos?

Danke schon mal.

Thorsten Pferdekaemper · 20 November 2018, 18:23:46

Hi,
was soll das Discovery? Die Dinger waren doch schon eingerichtet, oder?
Starte nochmal durch und mache diesmal keinen Discovery.
Sind die zwei Devices die einzigen am Bus oder gibt es noch weitere, die funktionieren?
Gibt es noch andere USB-Geräte außer dem Digitus-Ding?
Gruß,
Thorsten

Thorsten Pferdekaemper · 20 November 2018, 18:26:58

Hi nochmal,
Du kannst übrigens auch einfach im HM485_LAN-Device verbose auf 5 setzen. Dann wird nur der ganze HMW-Kram detailliert geloggt.
Gruß,
Thorsten

M.Piet · 20 November 2018, 20:00:09

Hi Thorsten,

Ja die waren beide bis vor dem Neustart in Betrieb. Ich dachte mit dem Discovery würde man die Kommunikation im Log sehen, bzw. was schief läuft.
Es sind nur diese beiden Devices am Bus. Zusammen mit dem Abschlußwiderstand in einem Gehäuse.

Ja, es gibt noch ein weiteres USB-Device: von meinem 1wire. Das läuft aber auch nach dem Neustart einwandfrei.

Danke für den Tip, das wusste ich gar nicht: ich habe verbose entsprechend gesetzt und mal einen neustart gegen 19:54 gemacht.
Das Log ist im Anhang.

Danke und schönen Gruß

Thorsten Pferdekaemper · 20 November 2018, 20:15:38

Hi,
das sieht so aus, als ob der Bus überhaupt nicht funktioniert. Also entweder die Devices bekommen keinen Strom (mal die Stromversorgung nachmessen) oder irgendwas ist am Bus unterbrochen oder das USB-Device heißt halt nicht mehr so wie erwartet.
Kannst Du sagen, auf welchem USB-Device das 1Wire-Teil läuft?
Könntest Du auch mal an einem der HMW-Teile eine Taste drücken oder so und das ganze mitloggen?
Das ganze am besten auch noch mit dem Log für den Daemon. Siehe Doku zu den Attributen HM485d_logVerbose und HM485d_logfile von HM485_LAN.
Vielleicht stimmt auch was mit dem "Abschlusswiderstand" nicht. Was genau ist denn da drin?
Gruß,
Thorsten

M.Piet · 20 November 2018, 20:46:36

Das ist ja seltsam. Vor allem hat er bis zu dem Neustart noch Daten geleifert. Aber OK, zu deinen Fragen.
Alle Module haben alle Strom, am Bus ist auch kein Draht locker. Die "Data"-LED am Busabschluss blinkt, wenn an den Modulen was passiert.

Die Auflistung der USB-Geräte. Das wäre der Zweite dann.

Code Auswählen

Bus 001 Device 007: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (U                                      ART) IC
Bus 001 Device 006: ID 04fa:2490 Dallas Semiconductor DS1490F 2-in-1 Fob, 1-Wire adapter
Bus 001 Device 004: ID 05e3:0605 Genesys Logic, Inc. USB 2.0 Hub
Bus 001 Device 003: ID 0424:ec00 Standard Microsystems Corp. SMSC9512/9514 Fast Ethernet Adapter
Bus 001 Device 002: ID 0424:9514 Standard Microsystems Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ich habe um 20:37 ein paar Tasten gedrückt. Log im Anhang.

Mit dem Abschlußwiederstand habe ich mich falsch ausgedrückt. Es ist der Originale Busabschluss gemeint (siehe Anhang, ganz rechts im Bild)

ZitatDas ganze am besten auch noch mit dem Log für den Daemon. Siehe Doku zu den Attributen HM485d_logVerbose und HM485d_logfile von HM485_LAN.

Da weiß ich jetzt nicht genau was du meinst...?

Thorsten Pferdekaemper · 20 November 2018, 21:00:13

Zitat von: M.Piet am 20 November 2018, 20:46:36Die Auflistung der USB-Geräte. Das wäre der Zweite dann.

Ich meinte, ob Du weißt, welchen Device-Namen das Ding in FHEM benutzt. Meine Vermutung ist momentan, dass der Digitus (wahrscheinlich der erste Eintrag in Deiner Liste) tatsächlich nicht /dev/ttyUSB0 ist, sondern irgend was anderes.

Zitat
Ich habe um 20:37 ein paar Tasten gedrückt. Log im Anhang.

Da scheint tatsächlich nichts zu passieren. D.h. FHEM "sieht" auch das nicht.

Zitat
Da weiß ich jetzt nicht genau was du meinst...?

Schau Dir mal in der Commandref (lokal in Deinem System, nicht die im Internet) die Doku zu HM485_LAN an und dort die zwei genannten Attribute.

Gruß,
Thorsten

M.Piet · 20 November 2018, 21:34:14

Es ist der /dev/ttyUSB0
Wenn ich den DIGITUS abziehe, verschwindet er unter /dev/ , stecke ich ihn wieder dran, ist der ttyUSB0 wieder vorhanden.

In dem "HM485_LAN" ist er unter dem Attribut "HM485d_device" auch mit "/dev/ttyUSB0" angegeben.

...ist er vielleicht einfach nur kaputt? Wenn ich den DIGITUS an mein Notebook anschließe und mit putty die Schnittstelle seriell öffne. Müsste ich das was sehen? Falls ja: weißt du die Baudrate?

Ich habe HM485d_logVerbose auf 5 gesetzt.
HM485d_logfile habe ich auf "_temp_hm485d.log" gesetzt".
Sollte er nun nicht unter "/opt/fhem/log" das Log "_temp_hm485d.log" schreiben?

Thorsten Pferdekaemper · 20 November 2018, 21:47:53

Zitat von: M.Piet am 20 November 2018, 21:34:14
Es ist der /dev/ttyUSB0
Wenn ich den DIGITUS abziehe, verschwindet er unter /dev/ , stecke ich ihn wieder dran, ist der ttyUSB0 wieder vorhanden.

Ok, dann wäre das geklärt.

Zitat
...ist er vielleicht einfach nur kaputt? Wenn ich den DIGITUS an mein Notebook anschließe und mit putty die Schnittstelle seriell öffne. Müsste ich das was sehen? Falls ja: weißt du die Baudrate?

Hier sind die Daten:

Code Auswählen


		$po->baudrate(19200);
		$po->databits(8);
		$po->parity('even');
		$po->stopbits(1);

Zitat
Ich habe HM485d_logVerbose auf 5 gesetzt.
HM485d_logfile habe ich auf "_temp_hm485d.log" gesetzt".
Sollte er nun nicht unter "/opt/fhem/log" das Log "_temp_hm485d.log" schreiben?

Ich glaube, dass das relativ zum momentanen Verzeichnis ist, also wahrscheinlich /opt/fhem/_temp_hm485d.log.

Gruß,
Thorsten

Thorsten Pferdekaemper · 20 November 2018, 21:53:57

Hi,
noch was: Wenn man die HM485d-Attribute ändert, dann muss man mindestens den Daemon neu starten. Dazu gibt's im HM485_LAN ein set-Kommando.
Gruß,
Thorsten

M.Piet · 21 November 2018, 14:20:45

Hi Thorsten,

Ich habe den DIGITUS mal am Notebook geloggt. Dort kommen Daten raus wenn ich die HM-Komponenten neu starte und auch Tasten betätigt. Sieht zwar komisch aus, denke das ist aber OK (oder was meinst du?).

Code Auswählen

▒▒|▒▒i▒▒|▒▒i▒▒|▒▒i▒▒▒▒▒▒▒▒AOEQ0863464▒▒▒▒▒i▒ۚ▒▒▒▒i▒ۚ▒▒▒▒i▒ۚ▒▒▒▒▒▒~▒▒AOEQ0863464▒T▒▒▒▒iz▒▒▒▒iz▒▒▒▒iz▒▒▒▒▒▒|▒▒AOEQ0863464on▒▒~▒▒i▒)▒▒▒~▒▒i▒)▒▒▒~▒▒i▒)▒▒▒▒▒▒▒▒▒AOEQ0863464l"▒▒|▒▒i▒.▒▒|▒▒i▒.▒▒|▒▒i▒.▒▒▒▒▒▒▒▒AOEQ0863464▒f▒▒▒▒i▒ɼ▒▒▒▒i▒ɼ▒▒▒▒i▒ɼ▒▒▒▒▒▒~▒▒AOEQ0863464▒*▒▒H,i▒д▒▒H,i▒д▒▒H,i▒д▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒|H,i▒▒"▒▒|H,i▒▒"▒▒|H,i▒▒"▒▒H,i▒t▒▒H,i▒t▒▒H,i▒t▒▒H,i▒;~▒▒H,i▒;~▒▒H,i▒;~▒▒~H,i▒▒@▒▒~H,i▒▒@▒▒~H,i▒▒@▒▒▒▒▒▒▒
>|▒@P▒▒▒▒▒?▒▒▒▒8▒▒▒▒▒▒▒▒▒▒
▒▒▒
▒▒@▒▒▒▒▒7▒▒▒▒▒▒▒|H,i"▒▒|H,i"▒▒|H,i"▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒H,i▒▒▒H,i▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒|H,i▒▒|H,i▒▒|H,i▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒H,i▒▒▒H,i▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒|H,i▒▒|H,i▒▒|H,i▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒H,i▒▒▒H,i▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒|H,i▒▒|H,i▒▒|H,i▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒H,i▒▒▒H,i▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒|H,i▒▒|H,i▒▒|H,i▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒H,i▒▒▒H,i▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒|H,i▒▒|H,i▒▒|H,i▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒H,i▒▒▒▒▒▒▒ih>▒▒▒▒ih>▒▒▒▒ih>▒▒▒▒▒▒|▒▒AOEQ0863464▒▒~▒▒i▒;▒▒▒~▒▒i▒;▒▒▒~▒▒i▒;▒▒▒▒▒▒▒▒▒AOEQ0863464\▒▒|▒▒i▒D▒▒|▒▒i▒D▒▒|▒▒i▒D▒▒▒▒▒▒▒▒AOEQ0863464w▒▒▒▒▒i▒▒▒▒▒▒▒i▒▒▒▒▒▒▒i▒▒▒▒▒▒▒▒▒~▒▒AOEQ0863464t▒▒▒▒▒i^T▒▒▒▒i^T▒▒▒▒i^T▒▒▒▒▒▒|▒▒AOEQ0863464▒▒▒▒~▒▒▒▒▒▒▒▒▒▒AOEQ0863464▒▒▒▒|▒▒i▒D▒▒|▒▒i▒D▒▒|▒▒i▒D▒▒▒▒▒▒▒▒AOEQ0863464w▒▒▒▒▒i▒▒▒▒▒▒▒i▒▒▒▒▒▒▒i▒▒▒▒▒▒▒▒▒~▒▒AOEQ0863464t▒▒▒▒▒iz▒▒▒▒iz▒▒▒▒iz▒▒▒▒▒▒|▒▒AOEQ0863464on▒▒~▒▒i▒)▒▒▒~▒▒i▒)▒▒▒~▒▒i▒)▒▒▒▒▒▒▒▒▒AOEQ0863464l"▒▒|▒▒i▒▒|▒▒i▒▒|▒▒i▒▒▒▒▒▒▒▒AOEQ0863464▒▒▒▒▒i▒ۚ▒▒▒▒i▒ۚ▒▒▒▒i▒ۚ▒▒▒▒▒▒~▒▒AOEQ0863464▒T▒▒▒▒iz▒▒▒▒iz▒▒▒▒iz▒▒▒▒▒▒|▒▒AOEQ0863464on▒▒~▒▒i▒)▒▒▒~▒▒i▒)▒▒▒~▒▒i▒)▒▒▒▒▒▒▒▒▒AOEQ0863464l"▒▒H,i▒2▒▒H,i▒2▒▒H,i▒2▒▒~H,i▒[▒▒▒~H,i▒[▒▒▒~H,i▒[▒▒▒H,i▒д▒▒H,i▒д▒▒H,i▒д▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒~H,i▒I▒▒▒|H,i▒▒"▒▒|H,i▒▒"▒▒|H,i▒▒"▒▒H,i▒t▒▒H,i▒t▒▒H,i▒t▒▒H,i▒;~▒▒H,i▒;~▒▒H,i▒;~▒▒~H,i▒▒@▒▒~H,i▒▒@▒▒~H,i▒▒@

Das Log lag nicht im Verzeichnis Log, sondern wie du geschrieben hattest im Verzeichnis /opt/fhem (hätte ich auch selbst drauf kommen können...). Log ist im Anhang. Um 14:13 habe ich Tasten betätigt.
Wie ich das sehe, ist TX und RX vorhanden. Also scheint die Kommiunikation doch erstmal zu laufen.

Thorsten Pferdekaemper · 21 November 2018, 20:52:42

Hi,
ok, das Digitus-Teil schickt zumindest mal irgendwas, was zum Teil verständlich ist. Das HM485d-Log zeigt allerdings nur Rx-Zeugs, das von FHEM empfangen wird. D.h. das sind die Befehle, die FHEM an den Daemon schickt. Der Daemon schickt dann was auf den Bus raus, bekommt aber keine Antwort zurück.
Irgendwie habe ich immer noch im Verdacht, dass da was mit der Kommunikation über /dev/ttyUSB0 nicht klappt.
Hast Du mal das USB-Autodetect deaktiviert?

Code Auswählen


# Disable this to avoid looking for new USB devices on Startup
define initialUsbCheck notify global:INITIALIZED usb create

D.h. mal für initialUsbCheck "disable" setzen und nochmal durchstarten.

Gruß,
Thorsten

M.Piet · 21 November 2018, 21:06:04

Hi Thorsten,

Ich habe ihn auf "inactive" gesetzt. Ich denke das ist das was du meintest, oder?
( STATE inactive)

Code Auswählen

Internals:
   DEF        global:INITIALIZED usb create
   NAME       initialUsbCheck
   NOTIFYDEV  global
   NR         23
   NTFY_ORDER 50-initialUsbCheck
   REGEXP     global:INITIALIZED
   STATE      inactive
   TRIGGERTIME 1542829166.18328
   TYPE       notify
   READINGS:
     2018-11-21 20:58:04   state           inactive
Attributes:

Habe einen Neustart gemacht. Leider keine Änderung.1

Thorsten Pferdekaemper · 21 November 2018, 21:21:19

Hi,
ich meinte eigentlich das Attribut disable, aber so sollte es auch gehen. Sind die ganzen USB-Meldungen noch im Log beim Starten oder nicht?
Gruß,
Thorsten

M.Piet · 21 November 2018, 21:33:42

Uih....das entwickelt sich immer mehr zu einer schweren Geburt.....danke auf jeden Fall für deine Hilfe.

OK, um auf Nr. sicher zu gehen habe ich es noch mal auf deine Variante "Attribut disable" gemacht. Dann den Neustart.
In der fhem.log finde ich nur eine USB-Meldung:

Code Auswählen

2018.11.21 21:27:58 3: hm485: Start HM485d with command line: ./FHEM/lib/HM485/HM485d/HM485d.pl --hmwId 00000001 --serialNumber SGW0123456 --device /dev/ttyUSB0 --localPort 2000 --logfile _temp_hm485d.log --verbose 5

In dem Log vom Daemon finde ich nur diese eine:

Code Auswählen

2018.11.21 21:27:59.670 2: HM485d: SERIAL connected to device /dev/ttyUSB0
2018.11.21 21:27:59.671 1: HM485d: Server started ...
2018.11.21 21:28:08.049 4: Connection accepted from HM485d_127.0.0.1_49530
2018.11.21 21:28:08.050 4: HM485d: Tx: H00,01,HMW-SOFT-GW,0.2.2,SGW0123456

Da ich mir nicht sicher bin, ob du das meintest, habe ich Log die vom Daemon mal angefügt (vor dem Neustart bereinigt).