AES check durch HMLAN vorhanden

[martinp876]

Hi Jan,

lösche Zeile 733 aus CUL_HM (oder kommentiere sie aus)
  return if(!(CUL_HM_getRxType($hash) & 0x10));

Und berichte.
Zeichne auf ab dem Setzen des Attributs, falls es Probleme gibt. Bereits beim Attribut setzen wird HMLAN entsprechend initialisiert.

Gruss Martin

[JanS]

Hi Martin,

erkenne auf Anhieb nicht den geringsten Unterschied, aesCommToDev bleibt auf dem Stand des letzten getConfigs.
Anbei mal ein Log ab Serverstart. Ich habe fhem, den hmland und den USB Stick "restartet". aesCommToDev ändert sich nur, wenn ich von FHEM aus Config Änderungen schreibe oder ein getConfig Request lostrete.
Dei register des SC stehen auf:
RegL_00: 02:01 09:01 0A:26 0B:33 0C:B6 10:01 14:06 00:00
RegL_01: 08:01 20:60 21:00 22:64 30:06 00:00

Soweit ich das derzeite verstehe ist 08:01 ja gleichbedeutend mit AES "Ein", und beim Konfigurieren wird aesCommToDev ja auch mehrfach aktualisiert.

Code Auswählen Erweitern

2014.05.04 17:43:02.257 1: Including fhem.cfg
2014.05.04 17:43:02.928 1: HMLAN_Parse: hmUSB new condition disconnected
2014.05.04 17:43:02.952 1: HMLAN_Parse: hmUSB new condition init
2014.05.04 17:43:04.032 1: Including ./log/fhem.save
2014.05.04 17:43:04.105 0: Server started with 20 defined entities (version $Id: fhem.pl 5715 2014-05-01 15:02:06Z rudolfkoenig $, os linux, user jasc, pid 12949)
2014.05.04 17:43:04.107 0: HMLAN_Parse: hmUSB V:03C7 sNo:KEQ1111385 d:2633B6 O:2633B6 t:00004336 IDcnt:0000
2014.05.04 17:43:04.107 0: HMLAN_Parse: hmUSB R:E251B96   stat:0000 t:00000C65 d:FF r:FFD0     m:BD 845E 251B96 000000 8000A300000000000909FE
2014.05.04 17:43:04.151 0: HMLAN_Parse: hmUSB R:RC7E71C6F stat:0002 t:00000000 d:FF r:7FFF     m:99 8112 999999 000001
2014.05.04 17:43:04.152 1: HMLAN_Parse: hmUSB new condition ok
2014.05.04 17:43:09.051 0: HMLAN_Send:  hmUSB I:+251B96,02,01,1E
2014.05.04 17:43:10.094 0: HMLAN_Send:  hmUSB I:+251B96,00,00,
2014.05.04 17:43:10.095 0: HMLAN_Send:  hmUSB S:+251B96,02,01,1E
2014.05.04 17:43:10.096 0: HMLAN_Send:  hmUSB S:SC7E73854 stat:  00 t:00000000 d:01 r:C7E73854 m:01 A001 2633B6 251B96 010E
2014.05.04 17:43:10.427 0: HMLAN_Parse: hmUSB R:E251B96   stat:0000 t:0000600C d:FF r:FFCF     m:01 A410 251B96 2633B6 060100002E
2014.05.04 17:43:10.523 0: HMLAN_Parse: hmUSB R:RC7E73854 stat:0001 t:00006011 d:FF r:FFCF     m:01 A410 251B96 2633B6 060100002E
2014.05.04 17:43:27.971 0: HMLAN_Send:  hmUSB I:K
2014.05.04 17:43:28.027 0: HMLAN_Parse: hmUSB V:03C7 sNo:KEQ1111385 d:2633B6 O:2633B6 t:0000A4D5 IDcnt:0001
2014.05.04 17:43:52.988 0: HMLAN_Send:  hmUSB I:K
2014.05.04 17:43:53.051 0: HMLAN_Parse: hmUSB V:03C7 sNo:KEQ1111385 d:2633B6 O:2633B6 t:00010694 IDcnt:0001
2014.05.04 17:44:03.387 0: HMLAN_Parse: hmUSB R:E250212   stat:0000 t:00012EF7 d:FF r:FFCF     m:2F A641 250212 2633B6 012800
2014.05.04 17:44:03.390 0: HMLAN_Send:  hmUSB I:+250212,00,00,
2014.05.04 17:44:03.489 0: HMLAN_Send:  hmUSB S:+250212,01,01,1E
2014.05.04 17:44:03.490 0: HMLAN_Send:  hmUSB S:SC7E80884 stat:  00 t:00000000 d:01 r:C7E80884 m:2F 8002 2633B6 250212 0101C800
2014.05.04 17:44:03.609 0: HMLAN_Parse: hmUSB R:RC7E80884 stat:0002 t:00000000 d:FF r:7FFF     m:2F 8002 2633B6 250212 0101C800
2014.05.04 17:44:04.154 0: HMLAN_Parse: hmUSB R:E250212   stat:0000 t:000131EF d:FF r:FFCD     m:2F A241 250212 2633B6 012800
2014.05.04 17:44:04.257 0: HMLAN_Send:  hmUSB S:SC7E80B81 stat:  00 t:00000000 d:01 r:C7E80B81 m:2F 8002 2633B6 250212 0101C800
2014.05.04 17:44:04.538 0: HMLAN_Parse: hmUSB R:RC7E80B81 stat:0002 t:00000000 d:FF r:7FFF     m:2F 8002 2633B6 250212 0101C800
2014.05.04 17:44:06.137 0: HMLAN_Parse: hmUSB R:E250212   stat:0000 t:000139B4 d:FF r:FFC9     m:30 A641 250212 2633B6 0129C8
2014.05.04 17:44:06.242 0: HMLAN_Send:  hmUSB S:SC7E81342 stat:  00 t:00000000 d:01 r:C7E81342 m:30 8002 2633B6 250212 0101C800
2014.05.04 17:44:06.521 0: HMLAN_Parse: hmUSB R:RC7E81342 stat:0002 t:00000000 d:FF r:7FFF     m:30 8002 2633B6 250212 0101C800
2014.05.04 17:44:11.385 0: HMLAN_Parse: hmUSB R:E250212   stat:0000 t:00014E39 d:FF r:FFC8     m:31 A641 250212 2633B6 012A00
2014.05.04 17:44:11.491 0: HMLAN_Send:  hmUSB S:SC7E827C2 stat:  00 t:00000000 d:01 r:C7E827C2 m:31 8002 2633B6 250212 0101C800
2014.05.04 17:44:11.769 0: HMLAN_Parse: hmUSB R:RC7E827C2 stat:0002 t:00000000 d:FF r:7FFF     m:31 8002 2633B6 250212 0101C800
2014.05.04 17:44:15.897 0: HMLAN_Parse: hmUSB R:E250212   stat:0000 t:00015FCD d:FF r:FFC6     m:32 A641 250212 2633B6 012BC8
2014.05.04 17:44:16.000 0: HMLAN_Send:  hmUSB S:SC7E83962 stat:  00 t:00000000 d:01 r:C7E83962 m:32 8002 2633B6 250212 0101C800
2014.05.04 17:44:16.281 0: HMLAN_Parse: hmUSB R:RC7E83962 stat:0002 t:00000000 d:FF r:7FFF     m:32 8002 2633B6 250212 0101C800
2014.05.04 17:44:17.993 0: HMLAN_Send:  hmUSB I:K
2014.05.04 17:44:18.041 0: HMLAN_Parse: hmUSB V:03C7 sNo:KEQ1111385 d:2633B6 O:2633B6 t:00016835 IDcnt:0002
2014.05.04 17:44:42.998 0: HMLAN_Send:  hmUSB I:K
2014.05.04 17:44:43.034 0: HMLAN_Parse: hmUSB V:03C7 sNo:KEQ1111385 d:2633B6 O:2633B6 t:0001C9D4 IDcnt:0002

Grüße,
Jan

[martinp876]

Soweit ich das derzeite verstehe ist 08:01 ja gleichbedeutend mit AES "Ein", und beim Konfigurieren wird aesCommToDev ja auch mehrfach aktualisiert.

AES fordert immer und nur der Empfänger an.
wenn du sign einschaltest wird das Device vom Sender (FHEM?, durch HMLAN?) AES anfordern, wenn dieser ein Kommando sendet.

aesCommToDev sagt zu HMLAN: Sollte das Device einen Trigger senden, frage nach AES von dem Device. Es ist also die andere Richtung. Beides ist unabhängig von einander.

Du testest mit USB - das habe ich nicht - sollte aber genauso wie HMLAN funktionieren.
Das AES wird korrekt gesetzt - so wie ich es vom HMLAN kenne. Die Indikation, das HMUSB hier AES anfordert fehlt. Könnte also sein, dass USB dies tatsächlich nicht unterstützt - oder aber in anderer Form.

Da muss ich also passen. Ein HMLAN hast du nicht - zum Vergleich?

Gruss Martin

[JanS]

AES fordert immer und nur der Empfänger an.
wenn du sign einschaltest wird das Device vom Sender (FHEM?, durch HMLAN?) AES anfordern, wenn dieser ein Kommando sendet.

Hmm, das ist wohl der Punkt, wo schalte ich in dieser Konstellation sign an? Ich habe ja kein Peering zu einem Aktor, nur den SC und den HMLAN/USB. Die Richtung ist ja aus meiner Sicht schon so, dass das Device einen Trigger sendet, nämlich open oder closed. aesCommToDev ändert sich aber nur bei der anderen Richtung HMLAN/FHEM zu Device.
Leider habe ich keinen echten HMLAN zur Hand nur den HM-CFG-USB-2.

[martinp876]

Leider habe ich keinen echten HMLAN zur Hand nur den HM-CFG-USB-2.

das ist der Punkt - leider. Dein Aufbau ist korrekt - aber HMUSB signalisiert nicht, dass es AES anfordert oder bearbeitet.

Bei HMLAN kann ich sehen, dass AES funktioniert. Bein USB habe ich es erwartet -aber nicht testen können.
Wie gesagt, da muss ich passen - sorry

[JanS]

Code Auswählen Erweitern

Bei HMLAN kann ich sehen, dass AES funktioniert. Bein USB habe ich es erwartet -aber nicht testen können.
Wie gesagt, da muss ich passen - sorry

Macht nix, haben wir immerhin wieder was bei gelernt
Ich werde allerdings tatsächlich mal ne CCU2 testen und schauen inwieweit ich über XML-RPC das Ganze mit FHEM aufbohren kann. Primärziel ist aber erstmal eine sauber abgesicherte Kommunikation zwischen SC und einer wie auch immer gearteten Zentrale. Bevor ich also nen HMLAN kaufe, greife ich gleich zur CCU2 und schau was da so mit Erweiterungen machbar ist.