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.
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.
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
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
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ß
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
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.
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 hubIch 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...?
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
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?
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:
$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
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
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?).
▒▒|▒▒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.
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?
# 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
Hi Thorsten,
Ich habe ihn auf "inactive" gesetzt. Ich denke das ist das was du meintest, oder?
( STATE inactive)
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
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
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:
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:
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).
Hi,
tja, da weiß ich jetzt auch nicht weiter. Vielleicht mal ein Terminal-Programm direkt auf Linux starten und nachsehen, ob da was kommt. Ansonsten vielleicht noch den Daemon mal ganz alleine starten, also FHEM beenden und nur den Daemon laufen lassen und auf die Kommandozeile loggen.
Gruß,
Thorsten
Alles klar, danke dir. Ich werde weiter den Digitus noch mal an mein Noteboot stecken, und ihn mit Nullmodemkabel auf einen COM-Port verbinden. Dann mit Putty schauen, ob Daten in beide Richtungen fließen. Bisher hatte ich nur ankommende Daten geprüft. Vielleicht ist es doch ein Hardwareproblem. Seltsam, dass er bei einem Neustart des PIs den Dienst verweigert hat, ohne das was geändert wurde.
Danke für deine Hilfe. Ich werde hier berichten wenn es was neues gibt.
Kleines Update.
Ich habe gestern den PI gegen einen anderen getauscht und habe ein Win32 Diskmananger-Image von 02/2018 auf die SD geschrieben. Da es auch hier nicht geht, kann man quasi ein Softwareproblem innerhalb des PIs ausschließen.
Ich habe die komplette Verdrahtung der HM-Komponenten gemessen: alles gut.
Somit bleibt nur noch der Digitus übrig (außer es wäre ein Problem an den HM-Komponenten selbst).
Ich habe gestern Abend einen neuen bestellt, ich hoffe das ist es auch....
Hey Thorsten,
alles geht wieder....es war doch ein Hardwaredefekt. Ich habe den Digitus getauscht, und alles ging wieder in Betrieb....
Aber...ich danke dir für die Geduld und die vielen Antworten!!!!
Hi,
das ist einerseits erfreulich für mich, andererseits aber auch ärgerlich, zumindest für Dich.
...vielleicht sollte ich mir auch mal meinen Ersatz-Digitus raussuchen. Bisher war das Teil bockstabil.
Gruß,
Thorsten
Zitatandererseits aber auch ärgerlich, zumindest für Dich.
Du, für mich ist das nicht ärgerlich, im Gegenteil.
Ich freue mich das mir geholfen wurde, nur mit deiner Hilfe bin ich soweit gekommen um den Fehler einzugrenzen. Weiter habe ich dazu gelernt.
Und die größte Freunde: es geht wieder. Und das ohne das der WAF gelitten hat.