[HM-Wired] HMW-LC-Sw2-DR / HBW-LC-Sw-8 => neues input/output Modul HBW-IO-6-6

a_quadrat · 08 Oktober 2019, 12:44:51

Hallo Thomas,

das Anlegen der Verknüpfung war kein Problem, aber es hatte leider nicht funktioniert. Ich gucke mal, ob ich die beiden Module zusammen gestrickt bekomme.

VG Andreas

loetmeister · 08 Oktober 2019, 18:01:14

Hi,

Eventuell hast du noch ein paar mehr Infos... Auch für alle anderen, die die historie nicht kennen.

Um HMW-LC-Sw2-DR geht es ja nicht, oder? Sondern Peering eines HBW-LC-Sw-8, mit?

https://github.com/ThorstenPferdekaemper/HBWired/tree/master/HBW-LC-Sw-8

Bei dem HBW-LC-Sw-8 kannst du ja mal im seriellen Monitor schauen. Ansonsten auch im FHEM event log...

Gruß,
Thomas

Thorsten Pferdekaemper · 09 Oktober 2019, 11:35:30

Zitat von: a_quadrat am 08 Oktober 2019, 12:44:51
das Anlegen der Verknüpfung war kein Problem

Das ist klar, da die Homebrew-Version ja dasselbe XML wie das Original verwendet. Daher "glaubt" FHEM, dass das geht.

Zitat von: loetmeister am 08 Oktober 2019, 18:01:14
Um HMW-LC-Sw2-DR geht es ja nicht, oder? Sondern Peering eines c, mit?

War die Ausgangssituation nicht ein 6-fach Taster? D.h. zumindest der HBW-LC-Sw-8 alleine würde nichts bringen.

Gruß,
Thorsten

a_quadrat · 09 Oktober 2019, 13:01:28

Die Ausgangssituation war, dass ich ein Gerät benötige, dass zwei Eingänge und zwei Ausgänge besitzt. Daher der Ansatz, folgendes Modul zu benutzen - HMW-LC-Sw2-DR.
Bei der Software die ich verwendet habe, habe ich festgestellt, dass ein peeren in der CCU möglich war, aber funktioniert hatte es nicht.
Der zweite Ansatz, das Modul HBW-LC-Sw-8 mit dem Modul HBW-SEN-key zu vereinheitlichen und dann testen, ob das peeren funktioniert.
Ich hatte das Modul HBW-LC-Sw-8 schon probiert zu peeren, aber es hatte ebenfalls nicht funktioniert.

Meine HMW-Testgeräte sind alle auf einer CCU angelegt und kommunizieren mit fhem über das HMCCU Modul.

Zu meinem Verständnis, sind die Geräte einmal gepeert, läuft die Kommunikation doch direkt über den Bus und sollte auch CCU/FHEM unabhängig laufen, oder?

VG Andreas

loetmeister · 09 Oktober 2019, 21:54:46

Zitat von: a_quadrat am 09 Oktober 2019, 13:01:28
Ich hatte das Modul HBW-LC-Sw-8 schon probiert zu peeren, aber es hatte ebenfalls nicht funktioniert.

Mir fehlt noch immer das Gegenstück... wo ist er Sensor (Taster) mit dem du HBW-LC-Sw-8 verknüpft hast?? Welches Modul nutzt du?

Zitat
Zu meinem Verständnis, sind die Geräte einmal gepeert, läuft die Kommunikation doch direkt über den Bus und sollte auch CCU/FHEM unabhängig laufen, oder?

Ja, das ist korrekt.

Gruß,
Thomas

a_quadrat · 11 Oktober 2019, 15:57:11

Hallo Thomas,

als Tasterschnittstelle habe ich das Modul HMW-IO-12-Sw7-DR.

Ich war eigentlich der Meinung, dass ich das Modul HBW-LC-Sw-8 schon getestet hatte, aber das war scheinbar nicht der Fall. Ich habe es jetzt nochmal aufgebaut und festgestellt, dass unter der CCU der Schaltbefehl nicht ausgeführt wird. Folgende Zeilen sind der Mitschnitt vom Bus:

Code Auswählen


B: 2A 1220
T: FD:FF:FF:FF:FF:F8:42:00:00:17:12:41:00:83:00:00:66:48:42:57:37:32:39:36:32:37:39:04:06
R: FD:FF:FF:FF:FF:DE:00:00:96:F3:06:4B:01:00:EF:1A:D8
R: FD:FF:FF:FF:FF:D8:00:00:96:F3:06:4B:01:00:EF:91:C0
R: FD:FF:FF:FF:FF:DA:00:00:96:F3:12:41:01:12:00:03:06:4A:45:D1:30:B4:39:B7:39:33:30:0B:3EE: CRC
R: FD:42:00:00:17:1E:00:00:00:81:05:38:00:E8:53:26E: CRC
R: FD:42:00:00:17:1E:00:00:00:81:05:38:00:E8:53:26E: CRC
R: FD:42:00:00:17:1E:00:00:00:81:05:38:00:E8:53:26E: CRC
R: FD:42:00:00:17:1E:00:00:00:81:05:38:00:E8:53:26E: CRC
R: FD:42:00:00:17:1E:00:00:00:81:05:38:00:E8:53:26E: CRC
R: FD:42:00:00:17:1E:00:00:00:81:05:38:00:E8:53:26E: CRC

Die ersten beiden Zeilen sind Anmeldung am Bus. Die nächsten 3 Zeilen sind die Befehle aus der Verknüpfung vom Tastermodul und der Rest, ist der Einschaltbefehl aus der CCU.

Leider funktioniert es nicht. Kannst du erkennen woran es liegen kann?

VG Andreas

Thorsten Pferdekaemper · 11 Oktober 2019, 21:18:59

Hi,
für mich sieht das so aus, als ob der Prüfsummencheck fehlschlägt. Komischerweise scheinen die Tastendrücke (4B) ok zu sein, aber die A-Message (41) sowie alles von der CCU nicht. Seltsam...
@Thomas: Hast Du was am Prüfsummencheck gemacht?
Gruß,
Thorsten

loetmeister · 11 Oktober 2019, 23:16:46

Hallo,

Am Empfangsteil habe ich eigentlich nichts gemacht.. Schon gar nicht an den crc Routinen.
Die Nachrichten mit dem crc Fehler sehen auch irgendwie abgeschnitten aus..

Verknüpfung der Taster mit broadcast funktioniert leider nicht.. Keine Ahnung ob HMW-IO-12-Sw7-DR auch die Tastendruck Nachricht direkt an die Adresse des aktors schicken würde.

Das Thema mit Tasten Peerings hatten wir letztens ähnlich hier diskutiert: https://forum.fhem.de/index.php/topic,22952.msg966355.html#msg966355

Gruß,
Thomas

Thorsten Pferdekaemper · 12 Oktober 2019, 09:44:14

Zitat von: loetmeister am 11 Oktober 2019, 23:16:46
Verknüpfung der Taster mit broadcast funktioniert leider nicht.. Keine Ahnung ob HMW-IO-12-Sw7-DR auch die Tastendruck Nachricht direkt an die Adresse des aktors schicken würde.

Ja, müsste er. Bei mir sieht das so aus (das ist aus dem FHEM-Log, also nicht genau das, was auf dem Bus passiert):

Code Auswählen


FD0F006542000014FA000123264B030158

Die Empfängeradresse 42000014 ist ein HBW-Teil und 00012326 ist ein HMW-IO-12-Sw7-DR, desses Taste damit gepeert ist. Ich denke, dass die drei Nachrichten aus dem Log von Andreas nichts mit einem Peering zu tun haben. ...oder anders: Die Geräte sind wohl gar nicht verknüpft.

Gruß,
Thorsten

a_quadrat · 12 Oktober 2019, 10:07:35

Hi,

ja, das könnte so sein, aber das erste Problem ist, dass ich es aus der Geräteoberfläche (CCU) nicht steuern kann. Das waren die "abgeschnittenen" CRC Fehler bzw. Zeile 6-11.

VG Andreas

Thorsten Pferdekaemper · 12 Oktober 2019, 12:40:17

Hi,
ich habe mir jetzt nochmal die eine Message genauer angeschaut:

Code Auswählen


R: FD:42:00:00:17:1E:00:00:00:81:05:38:00:E8:53:26E: CRC

Als das 42000017 sieht ok aus.
00000081 ist dann die Adresse Deiner CCU. Ist das korrekt? Es wundert mich ein bisschen, da die CCU normalerweise auf 00000001 hört.
Dan die 38 sollte eigentlich eine 78 (oder 73) sein.
Die E8 ist auch seltsam. Es sollte eher eine C8 sein.
Das sieht so aus als ob in der Nachricht einzelne Bits gekippt sind. Das sieht wirklich nach Fehlern in der Übertragung aus.
Gruß,
Thorsten

a_quadrat · 14 Oktober 2019, 20:22:36

Hi,

ja, die 00000081 ist die CCU, es ist keine orginal CCU sondern eine RaspberryMatic. Es ist schon merkwürdig, aber einen Übertragungsfehler kann ich mir nur schwer vorstellen, der Bus ist nur 30 cm lang und mit der Firmware von jfische funktioniert es.

Anbei einmal ein Mitschnitt eines Schaltbefehls vom HMW-IO-12-Sw7-DR:

Code Auswählen


R: FD:00:00:96:F3:1C:00:00:00:81:84E: MsgTooLong
:13:0C:32:FAR: FD:00:00:00:01:5C:00:00:56:73:06:29:0C:E8:00:5F:90E: CRC
R: FD:00:00:96:F3:59:00:00:00:81:82E: MsgTooLong
:92:4AR: FD:00:00:96:F3:1E:00:00:00:81:84E: MsgTooLong
:13:0C:2F:56R: FD:00:00:00:01:7E:00:00:16:73:06:29:0C:E8:00:06:56E: CRC
R: FD:00:00:96:F3:79:00:00:00:81:82E: MsgTooLong
:F6:0CR: FD:00:00:96:F3:18:00:00:00:81:84E: MsgTooLong
:13:8D:B8:A0R: FDR: FD:00:00R: FD:00:00:96R: FD:00:00:00R: FD:00R: FD:00:00:96:F3R: FD:00:00R: FD:00:00:96R: FD:00:00:96R: FD:00:00:00R: FD:00R: FD:00:00:96:F3:18:00:00R: FD:00R: FDR: FD:00:00:96R: FD:00:00:00R: FD:00:00:96R: FD:00:00:96R: FD:00R: FD:00:00:96R: FD:00:00R: FD:00:00:00R: FD:00:00R: FD:00:00:96:F3:18:00:00R: FD:00:00R: FD:00:00:96R: FD:00:00:96R: FD:00:00R: FD:00:00:96R: FD:00:00:96:F3:1C:00R: FD:00:00R: FD:00:00:96R: FD:00:00R: FD:00:00R: FD:00:00:96R: FD:00:00:96:F3:18:00:00:00:81:05:38:0C:00:A7:90E: CRC
R: FD:00:00:00:01:18:00:00:56:73:06:29:0C:00:00:B4:D4E: CRC
R: FD:00:00:96:F3:19:00:00:00:81:82E: MsgTooLong
:4B:

VG Andreas

loetmeister · 14 Oktober 2019, 22:56:21

Hi Andreas,

scheint gibt es mit der neuen Arduino IDE noch immer Probleme. Nicht mehr ganz so fatal wie vorher, aber es funktioniert nicht so recht... (habe https://forum.fhem.de/index.php?topic=22952.msg981363#msg981363 ergänzt)

Habe eben mal einen Test mit HBW-LC-Sw-8 gemacht. Mit IDE 1.8.10 & Arduino AVR Boards, Version 1.8.1.
Die Kommunikation mit FHEM funktioniert nicht, es gibt "MsgTooLong" und CRC Fehler Meldungen im Seriellen Monitor... also insgesamt nicht funktionsfähig.

Gehe ich wieder zurück auf die alte Boardversion:
Weiterhin IDE 1.8.10 aber Arduino AVR Boards, Version 1.6.21, läuft es wie gewohnt.

z.b. HBW-LC-Sw-8 start, dann per FHEM Kanal 1 ON (S: set 200)

Code Auswählen

22:21:51.008 -> B: 2A 1220
22:21:52.028 -> T: FD:FF:FF:FF:FF:F8:42:00:00:16:12:41:00:83:00:00:66:48:42:57:37:32:39:36:32:37:38:B2:A6
22:21:58.927 -> R: FD:42:00:00:16:1E:00:00:00:01:05:78:00:C8:9F:D2
22:21:58.961 -> S: 00 C8
22:21:58.961 -> T: FD:00:00:00:01:78:42:00:00:16:05:69:00:C8:9C:56
22:21:58.995 -> R: FD:42:00:00:16:19:00:00:00:01:02:F4:02
22:21:58.995 -> R: ACK
22:22:00.931 -> T: FD:00:00:00:01:98:42:00:00:16:05:69:00:C8:46:A4
22:22:00.964 -> R: FD:42:00:00:16:19:00:00:00:01:02:F4:02
22:22:00.998 -> R: ACK

Kannst du mal HBW-LC-Sw-8 mit Arduino AVR Boards, Version 1.6.21 kompilieren und testen?
Wenn du die Größen des Kompilierten Sketch vergleicht, sollte es so aussehen wie:

ok -> Arduino AVR Boards, Version 1.6.21
Der Sketch verwendet 14104 Bytes (45%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 452 Bytes (22%) des dynamischen Speichers, 1596 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes

not ok -> Arduino AVR Boards, Version 1.8.1
Der Sketch verwendet 13660 Bytes (44%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 452 Bytes (22%) des dynamischen Speichers, 1596 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.

Keine Ahnung was fehlt... scheint aber Code zu sein der für die Kommunikation wichtig ist..

Gruß,
Thomas

Thorsten Pferdekaemper · 15 Oktober 2019, 20:31:06

Hi,
ich kann mir vorstellen, dass das mit (der Spezialversion) der SoftwareSerial zusammenhängt. Möglicherweise wird da sowas wie tunedDelay "kaputtoptimiert". Inzwischen scheint die normale SoftwareSerial das auch ein bisschen anders zu machen: Es wird jetzt wohl _delay_loop_2 aus delay_basic.h verwendet. Vielleicht müsste man da mal was anpassen.
Gruß,
Thorsten

loetmeister · 15 Oktober 2019, 23:06:57

Hi Thorsten,

es scheint tatsächlich mit HBWSoftwareSerial zusammen zuhängen... obwohl ich mir das nicht so erklären kann, da ich auch unterschiedliche Größen des Kompilierten Sketch habe, selbst wenn ich HBWSoftwareSerial gar nicht genutzt habe.

Ich habe aber dennoch mal zum testen HBW-LC-Sw-8 und HBW-1W-T10 auf die neue SoftwareSerial abgeändert (es können ja nun mehrere Instanzen erzeugt werden).

Code Auswählen

  Serial.begin(19200);  // Serial->USB for debug
  rs485.begin(19200);    // RS485 via SoftwareSerial, must use 19200 baud!

Der Code, generiert mit Arduino AVR Boards, Version 1.8.1 scheint tatsächlich zu laufen... bei einem kurzen Test mit HBW-LC-Sw-8 und HBW-1W-T10 habe ich in FEHM und im Seriellen Monitor keine Probleme erkennen können.

D.h. ich könnte HBWSoftwareSerial aus allen Devices entfernen, um dieses Thema mit der Arduino AVR Boards Version zu begraben.

HBW-LC-Sw-8, Arduino AVR Boards, Version 1.8.1 & New SoftwareSerial
Der Sketch verwendet 13624 Bytes (44%) des Programmspeicherplatzes. Das Maximum sind 30720 Bytes.
Globale Variablen verwenden 460 Bytes (22%) des dynamischen Speichers, 1588 Bytes für lokale Variablen verbleiben. Das Maximum sind 2048 Bytes.

Gruß,
Thomas