Homematic wired

Thorsten Pferdekaemper · 22 Juni 2015, 21:53:29

Hi,
ich habe gerade die 141er Version ins git hochgeladen.
Gruß,
Thorsten

stephan-221 · 23 Juni 2015, 16:56:40

Hallo Ralf,

Zitat von: Ralf9 am 21 Juni 2015, 22:49:12
Hast Du es schon mal mit einer älteren Version von gevoo versucht, z.B. mit der 137 ?

mit 137 sieht es genauso aus.

Ich habe mal die Logs mitgeschrieben, aber man sieht nichts. Heute morgen habe ich ein paar Ausgänge schalten wollen und da merkt HM erst, dass das Modul nicht reagiert.

Code Auswählen

2015.06.22 22:15:11.115 3: HM485d: port 2000 opened
2015.06.22 22:15:11.117 3: HM485d: server waiting for client connection on port 2000
2015.06.22 22:15:11.119 3: Opening SERIAL device /dev/ttyRS485
2015.06.22 22:15:11.481 3: SERIAL device opened
2015.06.22 22:15:11.492 3: HM485d: SERIALbaudrate=19200, databits=8, parity=even, stopbits=1, handshake=none
2015.06.22 22:15:11.495 2: HM485d: SERIAL connected to device /dev/ttyRS485
2015.06.22 22:15:11.498 1: HM485d: Server started ...
2015.06.22 22:16:17.562 3: HM485d: Tx: (2:1) I[2](0,F,B)(1C) 00000001 -> 0000DBA7 [6] 73(s) 0003FF {EFF2}
2015.06.22 22:16:17.581 3: HM485d: Rx: Response: (2) I[3](2,F,B)(5E) 0000DBA7 -> 00000001 [6] 69(i) 0003FF {C960}
2015.06.22 22:16:17.589 3: HM485d: Tx: ACK(3,B)(79) 00000001 -> 0000DBA7 [2] {DA3C}
2015.06.22 22:16:19.137 3: HM485d: Tx: (3:1) I[3](0,F,B)(1E) 00000001 -> 0000DBA7 [6] 73(s) 0103FF {84DC}
2015.06.22 22:16:19.164 3: HM485d: Rx: Response: (3) I[0](3,F,B)(78) 0000DBA7 -> 00000001 [6] 69(i) 0103FF {B0D0}
2015.06.22 22:16:19.171 3: HM485d: Tx: ACK(0,B)(19) 00000001 -> 0000DBA7 [2] {E774}
2015.06.22 22:16:55.427 3: HM485d: Tx: (5:1) I[0](0,F,B)(18) 00000001 -> 0000DBA7 [6] 73(s) 0203FF {39AE}
2015.06.22 22:16:55.449 3: HM485d: Rx: Response: (5) I[1](0,F,B)(1A) 0000DBA7 -> 00000001 [6] 69(i) 0203FF {CE22}
2015.06.22 22:16:55.456 3: HM485d: Tx: ACK(1,B)(39) 00000001 -> 0000DBA7 [2] {03B2}
2015.06.22 22:16:56.292 3: HM485d: Tx: (6:1) I[1](0,F,B)(1A) 00000001 -> 0000DBA7 [6] 73(s) 0303FF {5280}
2015.06.22 22:16:56.311 3: HM485d: Rx: Response: (6) I[2](1,F,B)(3C) 0000DBA7 -> 00000001 [6] 69(i) 0303FF {B792}
2015.06.22 22:16:56.319 3: HM485d: Tx: ACK(2,B)(59) 00000001 -> 0000DBA7 [2] {3EFA}
2015.06.22 22:16:57.333 3: HM485d: Tx: (7:1) I[2](0,F,B)(1C) 00000001 -> 0000DBA7 [6] 73(s) 030000 {EE1E}
2015.06.22 22:16:57.351 3: HM485d: Rx: Response: (7) I[3](2,F,B)(5E) 0000DBA7 -> 00000001 [6] 69(i) 030000 {C88C}
2015.06.22 22:16:57.359 3: HM485d: Tx: ACK(3,B)(79) 00000001 -> 0000DBA7 [2] {DA3C}
2015.06.23 06:39:46.132 3: HM485d: Tx: (240:1) I[3](0,F,B)(1E) 00000001 -> 0000DBA7 [6] 73(s) 0303FF {A090}
2015.06.23 06:39:46.340 3: HM485d: Tx: (240:2) I[3](0,F,B)(1E) 00000001 -> 0000DBA7 [6] 73(s) 0303FF {A090}
2015.06.23 06:39:46.549 3: HM485d: Tx: (240:3) I[3](0,F,B)(1E) 00000001 -> 0000DBA7 [6] 73(s) 0303FF {A090}
2015.06.23 06:39:48.865 3: HM485d: Tx: (241:1) I[0](0,F,B)(18) 00000001 -> 0000DBA7 [6] 73(s) 020000 {0E28}
2015.06.23 06:39:49.073 3: HM485d: Tx: (241:2) I[0](0,F,B)(18) 00000001 -> 0000DBA7 [6] 73(s) 020000 {0E28}
2015.06.23 06:39:49.282 3: HM485d: Tx: (241:3) I[0](0,F,B)(18) 00000001 -> 0000DBA7 [6] 73(s) 020000 {0E28}
2015.06.23 06:39:50.378 3: HM485d: Tx: (242:1) I[1](0,F,B)(1A) 00000001 -> 0000DBA7 [6] 73(s) 000000 {536C}
2015.06.23 06:39:50.586 3: HM485d: Tx: (242:2) I[1](0,F,B)(1A) 00000001 -> 0000DBA7 [6] 73(s) 000000 {536C}
2015.06.23 06:39:50.795 3: HM485d: Tx: (242:3) I[1](0,F,B)(1A) 00000001 -> 0000DBA7 [6] 73(s) 000000 {536C}
2015.06.23 16:53:46.667 0: HM485d: Server stopped ...

Viele Grüße
Stephan

Ralf9 · 23 Juni 2015, 18:48:50

Zitat von: stephan-221 am 23 Juni 2015, 16:56:40
Hallo Ralf,

mit 137 sieht es genauso aus.

Ich habe mal die Logs mitgeschrieben, aber man sieht nichts. Heute morgen habe ich ein paar Ausgänge schalten wollen und da merkt HM erst, dass das Modul nicht reagiert.

Die 137 hat den Vorteil, daß die vielen störenden 52(R) weg sind. Damit dürfte die Fehlereingrenzung etwas einfacher sein.
Hast Du schon mit Deinem zweiten Adapter versucht zu schauen was auf dem Bus läuft?

Um 22:16:57 sieht es noch sauber aus. Es wird der Ausgang 4 ausgeschaltet und die Antwort wird mit einem ACK quitiert.

Code Auswählen


2015.06.22 22:16:57.333 3: HM485d: Tx: (7:1) I[2](0,F,B)(1C) 00000001 -> 0000DBA7 [6] 73(s) 030000 {EE1E}
2015.06.22 22:16:57.351 3: HM485d: Rx: Response: (7) I[3](2,F,B)(5E) 0000DBA7 -> 00000001 [6] 69(i) 030000 {C88C}
2015.06.22 22:16:57.359 3: HM485d: Tx: ACK(3,B)(79) 00000001 -> 0000DBA7 [2] {DA3C}

Ist dies der komplette log? Was ich seltsam finde, ist daß es abends mit "Tx: (7:1)" aufhört und dann morgens mit "Tx: (240:1)" weitergeht.
@Dirk liest Du hier auch mit?

Gruß Ralf

stephan-221 · 23 Juni 2015, 20:46:29

Hallo Ralf,

ja das war der komplette Log. Hat mich auch etwas gewundert.

Ich habe jetzt den Abhorchposten in Betrieb.

Ich habe einmal nur FHEM neugestartet und sehe noch keinen Unterschied.
Anliegend 10min Mitschnitt vom RS485 Bus.

Das zweite File ist nach einem Restart.
Da werden die Daten der Module abgezogen und anschließend alles auf ACK. Ich habe dann noch mehrere Kanäle geschaltet.

Was mir aufgefallen ist:
Das Auslesen der EEPROMS funktioniert im Fehlerfall wesentlich langsamer als im zweiten Fall.

Das Log geht noch weiter.
Werde später bzw. morgen reinschauen und das komplette File posten, sobald ich wieder Timeouts bekomme.

Viele Grüße
Stephan

stephan-221 · 24 Juni 2015, 06:42:11

Und jetzt der komplette Log bis nichts mehr geht.

Wieder sehr kurz.

Viele Grüße
Stephan

Ralf9 · 24 Juni 2015, 09:45:23

Zitat von: stephan-221 am 24 Juni 2015, 06:42:11
Und jetzt der komplette Log bis nichts mehr geht.

Wieder sehr kurz.

Hallo Stephan,

auf dem Bus sieht es gut aus.

Hier ist es noch ok, der HM485d bestätigt die Antwort mit einem ACK.

Code Auswählen


2015.06.23 22:25:32.543 3: HM485d: Rx:  I[1](0,F,B)(1A) 00000001 -> 0000DBA7 [6] 73(s) 0503FF {3E54}
2015.06.23 22:25:32.545 3: HM485d: Rx:  I[2](1,F,B)(3C) 0000DBA7 -> 00000001 [6] 69(i) 0503FF {DB46}
2015.06.23 22:25:32.563 3: HM485d: Rx: ACK(2,B)(59) 00000001 -> 0000DBA7 [2] {3EFA}

Und hier scheint die Antwort vom Modul nicht beim HM485d ankommen. Da die Antwort nicht durch den HM485d mit einem ACK bestätigt wird, wiederholt das Modul die Antwort zweimal.
Als Fehlerursache dürfte der USB-RS485 Adapter oder der HM485d in Frage kommen. Du kannst ja mal den Adapter tauschen.

Code Auswählen


2015.06.24 06:29:55.032 3: HM485d: Rx:  I[2](0,F,B)(1C) 00000001 -> 0000DBA7 [6] 73(s) 010000 {CA52}
2015.06.24 06:29:55.055 3: HM485d: Rx:  I[3](2,F,B)(5E) 0000DBA7 -> 00000001 [6] 69(i) 010000 {ECC0}
2015.06.24 06:29:55.065 3: HM485d: Rx: dup frame:  I[3](2,F,B)(5E) 0000DBA7 -> 00000001 [6] 69(i) 010000 {ECC0}
2015.06.24 06:29:55.112 3: HM485d: Rx: dup frame:  I[3](2,F,B)(5E) 0000DBA7 -> 00000001 [6] 69(i) 010000 {ECC0}

Gruß Ralf

stephan-221 · 24 Juni 2015, 10:00:08

Hallo Ralf,

ich werde den hm485d heute Abend auf den RS485 Lan Wandler umschalten. Der hat zwei RS485 Ports, und diese sind verbunden.
so kann ich dann auch noch mitlesen.

Viele Grüße
Stephan

Ralf9 · 24 Juni 2015, 19:05:59

Zitat von: Ralf9 am 24 Juni 2015, 09:45:23
Als Fehlerursache dürfte der USB-RS485 Adapter oder der HM485d in Frage kommen

Ich habe gerade gesehen, daß am 14.05.2015 an der DevIo.pm was geändert wurde. Falls seither ein fhem update gemacht wurde, könnte dies auch eine mögliche Fehlerursache sein.

http://sourceforge.net/p/fhem/code/8815/log/?path=/trunk/fhem/FHEM/DevIo.pm
http://forum.fhem.de/index.php/topic,36215

Gruß Ralf

hglaser · 24 Juni 2015, 20:10:45

Hallo Stephan

Ich hatte mal ein ähnlich gelagertes Problem. http://forum.fhem.de/index.php/topic,10607.msg291773.html#msg291773 Es ist jetzt nur geraten, aber da ja ziemlich viele 0x73 Befehle in deinem log aufscheinen und sonst ja nicht besonders viel rauszulesen ist, kann ich auch nur das.
Ich habe damals das Protokoll etwas umgeschrieben.

Versuche es einmal mit den beiden angehängten Dateien.

lg Harald

stephan-221 · 24 Juni 2015, 20:33:34

Danke Ralf und Honk,

seit 16 Uhr läuft hmw via Lan/RS485 Wandler und nicht via USB.
Ich bin gespannt ob das bis morgen hält.

Wenn ich den Thread für die Änderungen an der devIO.pm richtig verstehe, dann geht es da um Disconnects via USB (primär für den CUL). Das kann ja theoretisch zeitgleich irgendwie vorkommen, dass die Verbindung USB-RS485 Wandler abbricht. Ist die Frage, ob hier auch devio.pm reinspielt.

Wenn das wirklich ein USB Problem ist, dann sollte es ja jetzt stabiler laufen.

Die Modifikationen von Honk werde ich beim nächsten Timeout einspielen.

Viele Grüße
Stephan

stephan-221 · 25 Juni 2015, 08:07:40

Hallo Ihr,

Aktuell läuft alles weiterhin.

Damit liegt es entweder am USB-RS485 Wandler, USB Hub, oder am USB im Raspberry bzw. FHEM-USB.
Bei letzteren Fällen, dürften aber mehr Leute Probleme haben.

Ich aktualisiere heute auf die 141er Version und beobachte damit weiter.

Viele Grüße
Stephan

RoBra81 · 28 Juni 2015, 20:57:18

Zitat von: gevoo am 20 Juni 2015, 08:11:04
Hallo Ronny,

nur komisch, daß die log 5 Nachrichten aus dem HM485 nicht mitkommen. Hast Du
Code Auswählen Erweitern
attr global verbose 5
gesetzt?

Gruß gevoo

Hallo gevoo,

ich bin jetzt endlich mal dazu gekommen, nochmal ein Log zu schreiben. Ich hatte das Gerät (HMW_IO_12_Sw14_DR_KEQ0048375), den Kanal (OG.tr.BM.Treppe) und den HM485_LAN (OG.ze.SE.HomematicWired) auf Verbose 5. Der Beginn des Logs ist bei 2015.06.28 20:52:41.929: Der Kanal stand auf Analog und ich habe den Bewegungsmelder ausgelöst - das Reading hat sich verändert und im Log erscheinen Einträge. Um 2015.06.28 20:54:30 habe ich den Kanal auf Digital umgestellt und anschließend (nach 2015.06.28 20:55:11.006) den Bewegungsmelder erneut ausgelöst - keine Änderung des Readings und keine Einträge im Log...

Anbei das Log...

Vielen Dank
Ronny

Ralf9 · 28 Juni 2015, 22:15:27

Zitat von: RoBra81 am 28 Juni 2015, 20:57:18
Um 2015.06.28 20:54:30 habe ich den Kanal auf Digital umgestellt und anschließend (nach 2015.06.28 20:55:11.006) den Bewegungsmelder erneut ausgelöst - keine Änderung des Readings und keine Einträge im Log...

Hallo Ronny,

das kann so nicht funktionieren.
Wie sieht die Schaltung aus mit der Du den Ausgang vom Bewegungsmelder mit dem Eingang 26 verbindest?

Der DIGITAL_ANALOG_INPUT 26 hat einen Eingangsbereich von 0–10 V und 10 Bit Auflösung.
D.h. 10V entsprechen 1023 oder hex 03FF

wenn Du den Bewegungsmelder auslöst, steht im log:
0000C481 -> 00000001 [6] 69(i) 1900CA
0000C481 -> 00000001 [6] 69(i) 190193

00CA sind 202 dies ist ca 2 V
0193 sind 403 dies ist ca 4V

dies ist zuwenig damit der Digitaleingang auf ON wechselt.

Gruß Ralf

RoBra81 · 28 Juni 2015, 22:17:29

Klingt logisch - komischerweise hat es vor dem update funktioniert...

holzwurm83 · 29 Juni 2015, 20:37:09

Hallo zusammen,

ich habe leider immer noch das Problem, dass die Verbindung zum Bus regelmäßig abbricht. Für die Verbindung zum Bus verwende ich diesen Adapter:

http://forum.fhem.de/index.php/topic,14096.msg88557.html#msg88557

Ich habe die letzten Änderungen von gevoo eingespielt und die zwei Dateien von Harald auch. Leider besteht das Problem weiterhin.

Im Log steht leider nicht viel drin, zur Sicherheit hänge ich ihn mit an.

Kann ich euch sonnst irgendwelche anderen Infos zur Verfügung stellen um mir helfen zu können?

Homematic wired

hglaser