HomeBrewWired - Diskussion zum Tutorial

Begonnen von Thorsten Pferdekaemper, 01 Dezember 2016, 22:03:19

Vorheriges Thema - Nächstes Thema

a_quadrat

Hier der Log mit einem Kommando:

10:27:58 3: HM_485: Serial-Number: SGW0123456
2019.06.26 10:27:58 3: HM_485: Initialize the interface
2019.06.26 10:27:58.597 4: HM485d: Rx: FD3E30312C303030300D0A
2019.06.26 10:28:18.601 4: HM485d: Rx: FD02024B
2019.06.26 10:28:18.602 4: HM485d: Tx: FD03026100
2019.06.26 10:28:21.949 4: HM485d: Rx: FD0F0353C8420000171C000000017800C8
2019.06.26 10:28:21.952 5: SW: fd420000171c00000001057800c82f6e
2019.06.26 10:28:21.954 3: HM485d: Tx: (3:1) I[2](0,F,B)(1C) 00000001 -> 42000017 [5] 78(x) 00C8 {2F6E}
2019.06.26 10:28:22.157 5: SW: fd420000171c00000001057800c82f6e
2019.06.26 10:28:22.160 3: HM485d: Tx: (3:2) I[2](0,F,B)(1C) 00000001 -> 42000017 [5] 78(x) 00C8 {2F6E}
2019.06.26 10:28:22.363 5: SW: fd420000171c00000001057800c82f6e
2019.06.26 10:28:22.365 3: HM485d: Tx: (3:3) I[2](0,F,B)(1C) 00000001 -> 42000017 [5] 78(x) 00C8 {2F6E}
2019.06.26 10:28:22.566 4: HM485d: Tx: FD0403613439
2019.06.26 10:28:22 3: HBW_TUTORIAL_HBW7296279: RESPONSE TIMEOUT for 42000017
2019.06.26 10:28:34.293 4: HM485d: Rx: FD0F0453C8420000171E00000001780000
2019.06.26 10:28:34.296 5: SW: fd420000171e0000000105780000e2de
2019.06.26 10:28:34.298 3: HM485d: Tx: (4:1) I[3](0,F,B)(1E) 00000001 -> 42000017 [5] 78(x) 0000 {E2DE}
2019.06.26 10:28:34.501 5: SW: fd420000171e0000000105780000e2de
2019.06.26 10:28:34.504 3: HM485d: Tx: (4:2) I[3](0,F,B)(1E) 00000001 -> 42000017 [5] 78(x) 0000 {E2DE}
2019.06.26 10:28:34.707 5: SW: fd420000171e0000000105780000e2de
2019.06.26 10:28:34.709 3: HM485d: Tx: (4:3) I[3](0,F,B)(1E) 00000001 -> 42000017 [5] 78(x) 0000 {E2DE}
2019.06.26 10:28:34.910 4: HM485d: Tx: FD0404613439
2019.06.26 10:28:34 3: HBW_TUTORIAL_HBW7296279: RESPONSE TIMEOUT for 42000017



VG Andreas

Thorsten Pferdekaemper

Hi,
also das ist jetzt ziemlich eindeutig. Der Daemon schickt das Kommando raus, aber es kommt keine Antwort vom Device zurück. (Das mit dem 3439, was mich vorher gewundert hat, ist ein kleiner Bug, der aber für das hier keine Rolle spielt.)
Jetzt müssen wir mal sehen, wie wir herausfinden, wo die Kommunikation unterbrochen ist.
Da Du gesagt hast, dass das Kommando beim Arduino ankommt (also da schaltet was), muss es bis zum Arduino schon mal klappen. Kannst Du bestätigen, dass da was schaltet?

Falls ja, dann muss es auf dem Weg zurück liegen. Kannst Du mal ein Bild von Deiner Schaltung machen? Ist das wirklich genau so, wie im Tutorial angegeben?

Gruß,
   Thorsten 
FUIP

a_quadrat

Ja, die Befehle kommen beim Arduino an - die Schaltbefehle werden ausgeführt. Aber vom Arduino müsste die Kommunikation eigentlich auch funktionieren, ansonsten würden sich die Geräte doch gar nicht anlegen. Oder?
Die Schaltung ist genau wie im Tutorial, bis auf den 485 Treiber, da habe ich folgenden eingesetzt.

VG Andreas

Thorsten Pferdekaemper

Hi,
naja, wenn das Gerät mal angelegt ist und Du nur raw-Befehle verwendest, dann tut's auch so...
Funktioniert denn ein "set ... getConfig"?
Was passiert, wenn Du das Gerät in FHEM löschst und danach einmal den Arduino "durchstartest"?
Gruß,
   Thorsten
FUIP

a_quadrat

Also, bei getConfig kommt nichts,
aber wenn ich das Device lösche, den HM485_Lan restarte und dann den Arduino resete, dann wird das Gerät neu angelegt.

VG Andreas


Thorsten Pferdekaemper

Hi,
ok, da wär dann vielleicht mal ein Log von diesem Vorgang interessant.
Allerdings habe ich inzwischen noch einen anderen Tipp bekommen zu Deinem Transceiver-Baustein. Kann es sein, dass das Ding Abschlusswiderstände drauf hat? Könntest Du mal alle Widerstände jeweils zwischen A,B und GND (und ggf. +5V) messen? Möglicherweise ist das Ding nur für Standard-RS485 geeignet, aber nicht wirklich für HMW/HBW. Bitte mal für beide Transceiver, also den am Arduino und den auf der FHEM-Seite, messen.
Gruß,
   Thorsten
FUIP

a_quadrat

Hi,

ich habe zwischen A und B 120 ohm und zwischen A bzw. B zu GND 10,7 kohm und zwischen A bzw B zu Vcc ca 20 kohm.

Ich habe auch mal das RS485 Modul durch einen Max 487 CPA ersetzt, mit dem gleichen Ergebnis, außer das sich die Geräte nach dem löschen nicht mehr anlegen lassen.

VG Andreas

Thorsten Pferdekaemper

Zitat von: a_quadrat am 26 Juni 2019, 21:11:44
ich habe zwischen A und B 120 ohm
Das ist schlecht, der muss weg. Du hast Glück, wenn noch nichts wirklich kaputt gegangen ist. (Siehe hier: https://wiki.fhem.de/wiki/HomeMatic_Wired#Der_sogenannte_Busabschluss)
0 kohm.

Zitat
Ich habe auch mal das RS485 Modul durch einen Max 487 CPA ersetzt, mit dem gleichen Ergebnis, außer das sich die Geräte nach dem löschen nicht mehr anlegen lassen.
...und wie sehen die Widerstände bei dem Teil aus, das an der FHEM-Seite hängt?

Gruß,
   Thorsten
FUIP

a_quadrat

Am Interface messe ich 2,2 kOhm, den 120 Ohm Widerstand habe ich entfernt, leider immer noch keine Verbesserung.

VG Andreas

Thorsten Pferdekaemper

Hi,
jetzt kann es natürlich sein, dass tatsächlich was kaputt gegangen ist...
Könntest Du nochmal ein Log vom Daemon machen, und zwar beim "Hochfahren" des Arduino? ...also ich will sehen, ob da irgendwas auf der FHEM-Seite ankommt.
...und dann vielleicht tatsächlich mal ein Bild der Schaltung (auf beiden Seiten). Vielleicht ist da doch was falsch gelaufen.
Gruß,
   Thorsten
FUIP

a_quadrat

Hi,

was mich nur wundert, dass der Arduino, zum Anlegen der Geräte, was sendet. Oder? Vielleicht kommt heute Nachmittag das HMW Gerät, dann probiere ich damit nochmal.

Muss ich für den Deamon Log noch was aktivieren? Es ist doch die Datei var/log/deamon.log?

VG Andreas

Thorsten Pferdekaemper

Zitat von: a_quadrat am 27 Juni 2019, 09:42:36
was mich nur wundert, dass der Arduino, zum Anlegen der Geräte, was sendet. Oder?
Naja, er sendet halt irgendwas, je nachdem wie der Sketch genau aussieht. Egal was das Teil sendet, sollte FHEM bemerken, dass das Ding neu ist und es per Autocreate anlegen.

Zitat
Muss ich für den Deamon Log noch was aktivieren? Es ist doch die Datei var/log/deamon.log?
Nochmal so wie hier schon beschrieben: https://forum.fhem.de/index.php/topic,61781.msg952698.html#msg952698
...das, was Du dann gemacht hast, war schon richtig.

Gruß,
   Thorsten
FUIP

a_quadrat

Ich habe den HM485_Lan neu gestartet und das Gerät meldet sich korrekt an, dann einen Befehl abgeschickt und es geht auf Response Timeout. Hier der Log dazu, den Rest muss ich heute Abend machen. Ich habe Momentan physisch keinen Zugriff.

2019.06.27 13:02:50.924 2: HM485d: SERIAL connected to device /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A50285BI-if00-port0
2019.06.27 13:02:50.925 1: HM485d: Server started ...
2019.06.27 13:02:51 3: HM_485: Warte auf Initialisierung Gateway
2019.06.27 13:02:54 3: Opening HM_485 device localhost:2000
2019.06.27 13:02:54.589 4: Connection accepted from HM485d_127.0.0.1_36082
2019.06.27 13:02:54 3: HM_485: connected to device localhost:2000
2019.06.27 13:02:54.590 4: HM485d: Tx: H00,01,HMW-SOFT-GW,0.2.2,SGW0123456

2019.06.27 13:02:54 3: HM_485 device opened
2019.06.27 13:02:54 3: HM_485: Lan Device Information
2019.06.27 13:02:54 3: HM_485: Protocol-Version: 01
2019.06.27 13:02:54 3: HM_485: Interface-Type: HMW-SOFT-GW
2019.06.27 13:02:54 3: HM_485: Firmware-Version: 0.2.2
2019.06.27 13:02:54 3: HM_485: Serial-Number: SGW0123456
2019.06.27 13:02:54 3: HM_485: Initialize the interface
2019.06.27 13:02:54.603 4: HM485d: Rx: FD3E30312C303030300D0A
2019.06.27 13:02:56 3: HM_485: Initialisierung von Modul 42000017
2019.06.27 13:02:56.717 4: HM485d: Rx: FD0D0253C8420000171A0000000168
2019.06.27 13:02:56.720 5: SW: fd420000171a000000010368b5ec
2019.06.27 13:02:56.722 3: HM485d: Tx: (2:1) I[1](0,F,B)(1A) 00000001 -> 42000017 [3] 68(h)  {B5EC}
2019.06.27 13:02:56.785 3: HM485d: Rx: Response: (2) I[0](1,F,B)(38) 42000017 -> 00000001 [4] AB(�) 01 {0176}
2019.06.27 13:02:56.787 5: SW: fd42000017190000000102a23c
2019.06.27 13:02:56.790 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000017 [2] {A23C}
2019.06.27 13:02:56.790 4: HM485d: Tx: FD05027238AB01
2019.06.27 13:02:56.798 4: HM485d: Rx: FD0D0353C8420000171C000000016E
2019.06.27 13:02:56.801 5: SW: fd420000171c00000001036e3166
2019.06.27 13:02:56.808 3: HM485d: Tx: (3:1) I[2](0,F,B)(1C) 00000001 -> 42000017 [3] 6E(n)  {3166}
2019.06.27 13:02:56.858 3: HM485d: Rx: Response: (3) I[0](2,F,B)(58) 42000017 -> 00000001 [12] 48(H) 425737323936323739 {CB26}
2019.06.27 13:02:56.860 5: SW: fd42000017190000000102a23c
2019.06.27 13:02:56.862 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000017 [2] {A23C}
2019.06.27 13:02:56.863 4: HM485d: Tx: FD0D03725848425737323936323739
2019.06.27 13:02:56.871 4: HM485d: Rx: FD0D0453C8420000171E0000000176
2019.06.27 13:02:56.874 5: SW: fd420000171e0000000103760d28
2019.06.27 13:02:56.878 3: HM485d: Tx: (4:1) I[3](0,F,B)(1E) 00000001 -> 42000017 [3] 76(v)  {0D28}
2019.06.27 13:02:56.951 3: HM485d: Rx: Response: (4) I[0](3,F,B)(78) 42000017 -> 00000001 [4] 01() 00 {D8F0}
2019.06.27 13:02:56.953 5: SW: fd42000017190000000102a23c
2019.06.27 13:02:56.955 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000017 [2] {A23C}
2019.06.27 13:02:56.956 4: HM485d: Tx: FD050472780100
2019.06.27 13:02:56 3: HBW_TUTORIAL_HBW7296279: Request config for device 42000017
2019.06.27 13:02:56 3: HBW_TUTORIAL_HBW7296279: Lese Eeprom 42000017
2019.06.27 13:02:56.971 4: HM485d: Rx: FD100553C842000017180000000152000010
2019.06.27 13:02:56.974 5: SW: fd42000017180000000106520000100728
2019.06.27 13:02:56.976 3: HM485d: Tx: (5:1) I[0](0,F,B)(18) 00000001 -> 42000017 [6] 52(R) 000010 {0728}
2019.06.27 13:02:57.074 3: HM485d: Rx: Response: (5) I[0](0,F,B)(18) 42000017 -> 00000001 [18] FF(�) FF00000001FFFF0500C800C800FFFF {7AE8}
2019.06.27 13:02:57.076 5: SW: fd42000017190000000102a23c
2019.06.27 13:02:57.078 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000017 [2] {A23C}
2019.06.27 13:02:57.079 4: HM485d: Tx: FD13057218FFFF00000001FFFF0500C800C800FFFF
2019.06.27 13:02:57.101 4: HM485d: Rx: FD0E0653C8420000171A000000015300
2019.06.27 13:02:57.104 5: SW: fd420000171a00000001045300829e
2019.06.27 13:02:57.106 3: HM485d: Tx: (6:1) I[1](0,F,B)(1A) 00000001 -> 42000017 [4] 53(S) 00 {829E}
2019.06.27 13:02:57.165 3: HM485d: Rx: Response: (6) I[0](1,F,B)(38) 42000017 -> 00000001 [5] 69(i) 0000 {0CD0}
2019.06.27 13:02:57.167 5: SW: fd42000017190000000102a23c
2019.06.27 13:02:57.169 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 42000017 [2] {A23C}
2019.06.27 13:02:57.170 4: HM485d: Tx: FD06067238690000
2019.06.27 13:03:15.164 4: HM485d: Rx: FD0F0753C8420000171C00000001730000
2019.06.27 13:03:15.167 5: SW: fd420000171c0000000105730000c9bc
2019.06.27 13:03:15.169 3: HM485d: Tx: (7:1) I[2](0,F,B)(1C) 00000001 -> 42000017 [5] 73(s) 0000 {C9BC}
2019.06.27 13:03:15.372 5: SW: fd420000171c0000000105730000c9bc
2019.06.27 13:03:15.374 3: HM485d: Tx: (7:2) I[2](0,F,B)(1C) 00000001 -> 42000017 [5] 73(s) 0000 {C9BC}
2019.06.27 13:03:15.577 5: SW: fd420000171c0000000105730000c9bc
2019.06.27 13:03:15.580 3: HM485d: Tx: (7:3) I[2](0,F,B)(1C) 00000001 -> 42000017 [5] 73(s) 0000 {C9BC}
2019.06.27 13:03:15.781 4: HM485d: Tx: FD0407613439
2019.06.27 13:03:15 3: HBW_TUTORIAL_HBW7296279: RESPONSE TIMEOUT for 42000017


VG Andreas

a_quadrat

Hi,

ich habe jetzt das HMW Gerät angeschlossen und es kommt zu den gleichen Fehlern. Es kann eigentlich nur noch am Interface oder Raspi liegen. Kann es sein, dass eventuell noch eine Bibliothek fehlt?

VG Andreas

Thorsten Pferdekaemper

Hi,
ich wüsste nicht, was das für eine Bibliothek sein soll. Es ist auch etwas seltsam, dass es beim HBW-Device erst beim set-Befehl passiert. Da ist eher meine Vermutung, dass mit dem Sketch was nicht stimmt. Von der Kommunikation her ist eher der config-Teil fehleranfällig, da dabei viel mehr passiert.
Was genau passiert bei dem HMW-Gerät. Wird das auch ordentlich angelegt und dann passiert erst das Problem? Könntest Du hier auch mal dasselbe Log machen?
Gruß,
   Thorsten
FUIP