AES mit CUL nicht mehr möglich?

mgernoth · 01 September 2016, 10:01:22

Hallo Frank,

Zitat von: frank am 01 September 2016, 09:56:10
dazu habe ich mal eine frage?
wenn dem so wäre, dass der cul nichts empfängt, müsste dann nicht fhem die antworten über den hmlan bekommen und die weiteren messages wieder über den cul senden? es heisst doch immer, dass alle io's empfangen, und nach der ersten eingehenden message, egal von wem sie empfangen wurde, fhem reagiert.

Ja, deswegen sendet der CUL auch die Challenge raus. Das passt zum List von 19:47 gestern:

Code Auswählen


   IODev      CUL0 
   LASTInputDev HMLAN1

Evtl. kommt die Challenge aber auch nicht beim Fenstersensor an, wenn das Funkmodul einen Defekt hat.

Viele Grüße,
Michael

Bytechanger · 01 September 2016, 10:22:16

Dieses Verhalten habe ich auch bei einem Actor.
Also ein CUL Problem??

Wo kann ich hier ansetzen??
Mit dem CUL kann ich ja kommunizieren...
Er hat auch (nachweislich vor einiger Zeit) ordnungsgemäß funktioniert...

Greets

Byte

Bytechanger · 01 September 2016, 10:46:31

Einige Test haben nun folgendes ergeben:

Wenn ich im CUL in FHEM ein reopen mache geht zumindest manchmal der statusRequest.

Was auch dagegen spricht ist, wenn ich beim Fensterkontakt AES Signaturanforderung abschalte, gehts...
Also sendet und empfängt der CUL...

Greets

Byte

mgernoth · 01 September 2016, 12:46:11

Hallo,

schalte doch mal testweise Deinen HMLAN ab. Funktioniert dann noch irgendwas? (Die VCCU benutzt dann für alles den CUL)
Wo steckt der CUL dran? Ist die Stromversorgung ausreichend dimensioniert (bei Einplatinencomputern)?

Wenn Dein Log kein vom CUL empfangenen Pakete zeigt, ist irgendwas ausserhalb von CUL_HM kaputt...

EDIT: Achja, bei einem reopen wird der CC1101 auf dem CUL reinitialisiert.

Viele Grüße
Michael

Bytechanger · 01 September 2016, 21:04:48

Tja,

da kommt nix mehr an. Habe mal kurz ein Disconnect Connect im Log gesehen,

also CUL ist defekt oder wie?
Nochmal 50€ für ein neuen??

Geflashed habe ich das Teil schon mehrfach...
Leider ohne Erfolg.

Spannung kann es nicht sein, hab ihn mal an einen USB-Hub mit Spannungsversorgung geklemmt..

Aber das Log liest sich, als käme noch was

Code Auswählen

2016.09.01 20:59:36.061 4: CUL_Parse: CUL0 0 D2 E2 D07D 3913D0 4 
2016.09.01 20:59:36.123 2: CUL0: unknown message 0D2E2D07D3913D04
2016.09.01 20:59:36.123 4: CUL_Parse: CUL0 3 20 00 0060 021656 A 
2016.09.01 20:59:36.183 2: CUL0: unknown message 320000060021656A
2016.09.01 20:59:36.184 4: CUL_Parse: CUL0 5 5E 43 023B 900070 0 
2016.09.01 20:59:36.244 2: CUL0: unknown message 55E43023B9000700
2016.09.01 20:59:36.245 4: CUL_Parse: CUL0 1 81 46 C070 090876 B 
2016.09.01 20:59:36.305 2: CUL0: unknown message 18146C070090876B
2016.09.01 20:59:36.306 4: CUL_Parse: CUL0 F 85 61 1EF2 C1A1F4 1 
2016.09.01 20:59:36.308 5: CUL0 dispatch 810f04xx0101a00185611e00f2c1a1f41
2016.09.01 20:59:36.376 3: FS20 Unknown device 8561 (31222312), Button 1e (1243) Code d2 (unknown_d2 1024), please define it
2016.09.01 20:59:36.877 4: CUL_Parse: CUL0 0 05 97 F3F8 8310B0 0 
2016.09.01 20:59:37.008 2: CUL0: unknown message 00597F3F88310B00
2016.09.01 20:59:38.011 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.09.01 20:59:38.074 1: Perfmon: possible freeze starting at 20:59:37, delay is 1.073
2016.09.01 20:59:38.573 1: /dev/ttyACM0 reappeared (CUL_0)
2016.09.01 20:59:43.828 1: Perfmon: possible freeze starting at 20:59:41, delay is 2.827
2016.09.01 21:00:02.081 4: CUL_send:  CUL0V      
2016.09.01 21:00:02.092 5: CUL/RAW (ReadAnswer): V 1.61 CUL868

2016.09.01 21:00:46.820 1: Perfmon: possible freeze starting at 21:00:44, delay is 2.819
2016.09.01 21:01:44.799 3: set CUL0 raw e
2016.09.01 21:01:44.800 4: CUL_send:  CUL0e      
2016.09.01 21:01:45.335 1: /dev/ttyACM0 disconnected, waiting to reappear (CUL_0)
2016.09.01 21:01:45.392 1: /dev/serial/by-id/usb-busware.de_CUL868-if00 disconnected, waiting to reappear (CUL0)
2016.09.01 21:01:45.811 4: CUL_send:  CUL0V      
2016.09.01 21:01:45.822 5: CUL/RAW (ReadAnswer): V 1.61 CUL868

2016.09.01 21:01:45.823 4: CUL_send:  CUL0?      
2016.09.01 21:01:45.834 5: CUL/RAW (ReadAnswer): ? (? is unknown) Use one of B b C F i A Z E G M K U Y R T V W X e f m l t u x

Greets

Byte

mgernoth · 01 September 2016, 23:26:43

Hallo,

Zitat von: Bytechanger am 01 September 2016, 21:04:48
Tja,

da kommt nix mehr an. Habe mal kurz ein Disconnect Connect im Log gesehen,

also CUL ist defekt oder wie?

Zumindest scheint er die Fehlerursache zu sein.

Zitat
Nochmal 50€ für ein neuen??

Flashe erst nochmal culfw 1.66, die 1.61 ist schon etwas älter, ich bin mir gerade nicht mehr sicher, ob die schon alle HomeMatic-fixes enthält. (Die 1.66 hattest Du anfangs drauf)

Hast Du evtl. nicht-Homematic-Geräte, die über den CUL geschaltet werden? Die dynamische Protokollumschaltung zwischen den einzelnen Funkprotokollen kann evtl. zu komischem Verhalten führen, hier könnte es Bugs in der culfw geben. Wenn ja, welches Protokoll ist das?

Ansonsten in jedem Fall mal den CUL einfach als Homematic-Sniffer ausserhalb von Fhem betreiben:
- CUL in Fhem auf closed setzen oder ganz disablen
- screen -c /dev/null /dev/serial/by-id/usb-busware.de_CUL868-if00 115200
(Baudrate ist egal)

Im screen dann erstmal mit "V<ENTER>" schauen, ob der cul überhaupt reagiert. Wenn er das tut, den CUL mit "Ar<ENTER>" in den AskSin(BidCos/HomeMatic)-Empfangsmodus versetzen. Wenn jetzt durch ein Gerät bzw. den HMLAN eine Homematic-Nachricht gesendet wird, sollte diese mit Prefix "A" auftauchen.
Das ganze mal eine Zeit lang mitlaufen lassen und schauen, ob es irgendwann plötzlich aufhört.

Zitat
Aber das Log liest sich, als käme noch was
Code Auswählen Erweitern
2016.09.01 20:59:36.061 4: CUL_Parse: CUL0 0 D2 E2 D07D 3913D0 4 2016.09.01 20:59:36.123 2: CUL0: unknown message 0D2E2D07D3913D04 2016.09.01 20:59:36.123 4: CUL_Parse: CUL0 3 20 00 0060 021656 A 2016.09.01 20:59:36.183 2: CUL0: unknown message 320000060021656A

Irgendwelche Bytes schickt der CUL, aber zumindest für mich ist das kein bekanntes Protokoll. Sieht eher zufällig aus.

Viele Grüße
Michael

Bytechanger · 02 September 2016, 08:27:29

Hallo,

jetzt wird es interessant, da ich mehr über die Details erfahre:

Also auch nach einer Stunde empfängt der CUL noch etwas, wenn ich auf der Console schaue:

Code Auswählen


 screen -c /dev/null /dev/serial/by-id/usb-busware.de_CUL868-if00 115200
V 1.66 CUL868
A0C6CA6412782911DA46201A2C835
A0A6C80021DA4622782910016
A0B2FA0011DA462456779010E17
A0A2F80021DA4624567790016
A123080024567791DA4620101C80034DC5B03CCF5
A1131A0024567791DA462049A67E13CF30E02F5
A1931A0031DA46245677923402F43F3898F454A6DDD0FFFEA3DEC16
A123180024567791DA4620101000034F7ECA1C9F3
A11EFA00217E2BB1C58010455493D31949A02D7
A0EEF800217E2BB1C580100E68E1AADD6
A0E32A0111DA462456779020100000015
A1133A0024567791DA462047C4546CBDF6602F5
A1933A0031DA4624567793AE27B08138F4980D85D599B07C6068715
A0E34A4104567791DA4620601C80034F6
A1135A0024567791DA46204767EE69B90FA02F6
A1935A0031DA462456779843BE1887019FA007B7E653DF4ECEB2D15
A1136A0024567791DA46204667E23FD3D9C02F4
A1936A0031DA462456779F097DDEA78A919018C870BDB92C4C8C215
A1142A00241702A408A0A048B790000791E02D9
A1937A0031DA462456779AC98BB9492976D6F2694CD468B57822815
A1143A00241702A408A0A04587E00007E1F02D2
A0E38A4104567791DA4620601000034F5

Greets

Byte

PS: Ich musste "screen" erstmal installieren; Am Schluss musste ich auch ganz schön suchen, bis ich den Ausgang gefunden habe

Ctrl+A dann D macht es

mgernoth · 03 September 2016, 19:15:08

Hi,

Zitat von: Bytechanger am 02 September 2016, 08:27:29
Also auch nach einer Stunde empfängt der CUL noch etwas, wenn ich auf der Console schaue:

Code Auswählen Erweitern
A0E38A4104567791DA4620601000034F5

Sieht gut aus, also scheint der CUL Nachrichten zu empfangen.

Sende testweise mal eine Nachricht:

Code Auswählen


As09998112999999000000<ENTER>

Empfängt der CUL danach immer noch Nachrichten?

Hast du evtl. nicht-Homematic-Geräte, die den CUL als IO benutzen? Die Protokollumschaltung ist nicht ganz sauber da...

Zitat
PS: Ich musste "screen" erstmal installieren; Am Schluss musste ich auch ganz schön suchen, bis ich den Ausgang gefunden habe Ctrl+A dann D macht es

Damit hast Du dich nur detached, der screen läuft weiter (reattach mit screen -r).
Wirklich beendet kriegst Du ihn it CTRL-A \ (oder einfach den CUL abziehen).

Viele Grüße
Michael

Bytechanger · 05 September 2016, 17:05:50

OK,

bin nun davon ausgegangen, dass der CUL defekt ist.
Habe einen neuen bestellt. Diesen geflashed und installiert...

Leider zeigt er das gleiche Verhalten.
Ich kann also mit großer Sicherheit einen Hardwaredefekt ausschließen.
Nein ich habe keine anderen Devices außer HM.

Benötige also weiterhin Hilfe!

Ach so, kann ich über Putty mit "Maus rechts" in das screen Fenster den Sendebefehl kopieren?
Man bekommt ja keine Optische Rückmeldung, was man eingetippt hat...

Greets

Byte

mgernoth · 05 September 2016, 18:24:46

Hi,

Zitat von: Bytechanger am 05 September 2016, 17:05:50
Leider zeigt er das gleiche Verhalten.
Ich kann also mit großer Sicherheit einen Hardwaredefekt ausschließen.

Ja, scheint so.

Zitat
Nein ich habe keine anderen Devices außer HM.

Ok, dann kann das als Ursache ausgeschlossen werden.

Was bekommst Du denn als Ausgabe, wenn Du das folgende ausfuehrst wenn der CUL in Fhem eingebunden ist?

Code Auswählen


sudo lsof /dev/ttyACM*

(Evtl. vorher Paket lsof installieren)

Zitat
Ach so, kann ich über Putty mit "Maus rechts" in das screen Fenster den Sendebefehl kopieren?
Man bekommt ja keine Optische Rückmeldung, was man eingetippt hat...

Ja, screen macht da kein lokales Echo. Du koenntest es hoechstens mit einem zweiten CUL im Sniffing-Modus sehen. Aber ich gehe jetzt mal davon aus, dass das alles klappt und Du an dieser Stelle nicht weitersuchen musst.

Viele Gruesse
Michael

Bytechanger · 05 September 2016, 19:01:47

So also,

in meinem CUL Log steht:

Code Auswählen

2016.09.01 19:38:52.970 5: CUL0 sending As0B2CA0011DA462456779010E
2016.09.01 19:38:52.971 4: CUL_send:  CUL0As 0B 2C A001 1DA462 456779 010E
2016.09.01 19:38:54.994 5: CUL0 sending As0B2CA0011DA462456779010E
2016.09.01 19:38:54.995 4: CUL_send:  CUL0As 0B 2C A001 1DA462 456779 010E
2016.09.01 19:39:00.273 5: CUL0 sending As0B2CA0011DA462456779010E
2016.09.01 19:39:00.274 4: CUL_send:  CUL0As 0B 2C A001 1DA462 456779 010E
2016.09.01 19:39:04.303 5: CUL0 sending As0B2CA0011DA462456779010E
2016.09.01 19:39:04.304 4: CUL_send:  CUL0As 0B 2C A001 1DA462 456779 010E

Habe mir da ein As 0B 2C A001 1DA462 456779 010E geschnappt und gesendet und sogar eine Antwort gesehen:

Code Auswählen

A0E2CA4104567791DA462060100004EF9
A0A2C80021DA462456779002A

Also scheint Senden und Empfangen OK zu sein... Ist ja auch der neue CUL...

Code Auswählen

sudo lsof /dev/ttyACM*
COMMAND  PID USER   FD   TYPE DEVICE SIZE/OFF  NODE NAME
perl    1170 fhem   36u   CHR  166,0      0t0 15157 /dev/ttyACM0
perl    1170 fhem   38u   CHR  166,0      0t0 15157 /dev/ttyACM0

Sieht doch auch gut aus, bis auf die Tatsache, dass er doppelt vorkommt?

Greets

Byte

mgernoth · 05 September 2016, 19:23:27

Hi,

Zitat von: Bytechanger am 05 September 2016, 19:01:47
Habe mir da ein As 0B 2C A001 1DA462 456779 010E geschnappt und gesendet und sogar eine Antwort gesehen:
Code Auswählen Erweitern
A0E2CA4104567791DA462060100004EF9 A0A2C80021DA462456779002A
Also scheint Senden und Empfangen OK zu sein... Ist ja auch der neue CUL...

Ja, sieht gut aus.

Zitat
Code Auswählen Erweitern
sudo lsof /dev/ttyACM* COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME perl 1170 fhem 36u CHR 166,0 0t0 15157 /dev/ttyACM0 perl 1170 fhem 38u CHR 166,0 0t0 15157 /dev/ttyACM0

Sieht doch auch gut aus, bis auf die Tatsache, dass er doppelt vorkommt?

Nein, er sollte nur einmal offen sein (ich habe das gerade nochmal sicherheitshalber hier nachgeschaut). Wenn er mehrfach geoffnet wird, kannst Du Dir in Empfangsrichtung nie sicher sein, wo die Bytes genau zugestellt werden. Das wuerde auch Deine "zufaelligen" Bytes in einem aelteren Log erklaeren.

Schau mal in Deine Fhem-Config, der Port muesste da zweimal definiert sein (evtl. einmal nicht als CUL).

Viele Gruesse
Michael

Bytechanger · 05 September 2016, 21:10:58

Hey,

darauf muss man erstmal kommen, dem war so!!!!
In der FHEM.config war an einer Stelle plötzlich

define CUL_0 CUL /dev/ttyACM0@9600 1034

definiert !!! Das war ich ganz bestimmt nicht!! Insbesondere weil dort eine ID vergeben wurde, ich habe den CUL immer nur mit 0000 definiert!
Es stand auch mitten zwischen irgend welchen anderen devices ganz alleine ohne weitere attribute !

nach einem Neustart ist er jetzt nur noch einmal drin:

ALSO Stand ist nun:
Die Statusinfos scheinen ohne AES jetzt gut zu laufen.

ABER bei den Fensterkontakten habe ich das problem, dass das ACK offensichtlich nicht an den Fensterkontakt übertragen wird.
Er bleibt sehr lange auf orange um dann später auf ROT zu gehen!

Das Reading aesCommToDev bleibt auch auf "pending"

Das Eventlog:

Code Auswählen

2016-09-05 21:07:39.753 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:39.955 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:40.054 CUL_HM EG_FensterBuero aesCommToDev: fail
2016-09-05 21:07:40.054 CUL_HM EG_FensterBuero trig_aes_vccu: fail:238
2016-09-05 21:07:40.249 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:40.443 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:40.630 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:40.825 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero aesCommToDev: ok
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero battery: ok
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero contact: open (to vccu)
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero open
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero trig_aes_vccu: ok:238
2016-09-05 21:07:41.058 CUL_HM EG_FensterBuero trigger_cnt: 238
2016-09-05 21:07:41.248 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:41.448 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:07:41.646 CUL_HM EG_FensterBuero aesCommToDev: pending

Log:

Code Auswählen

2016.09.05 21:07:39.571 5: CUL/RAW: /A0CB8A6412782911DA46201EEC832

2016.09.05 21:07:39.573 4: CUL_Parse: CUL0 A 0C B8 A641 278291 1DA462 01EEC832 -49
2016.09.05 21:07:39.576 5: CUL0 dispatch A0CB8A6412782911DA46201EEC8::-49:CUL0
2016.09.05 21:07:39.579 5: CUL0 sending As11B8A0021DA4622782910455B720B8CF5F02
2016.09.05 21:07:39.581 5: CUL 278291 dly:93ms
2016.09.05 21:07:39.676 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0455B720B8CF5F02
2016.09.05 21:07:39.765 5: CUL/RAW: /A11B8A0021DA462278291046CFA5C12734E0220

2016.09.05 21:07:39.766 4: CUL_Parse: CUL0 A 11 B8 A002 1DA462 278291 046CFA5C12734E0220 -58
2016.09.05 21:07:39.768 5: CUL0 dispatch A11B8A0021DA462278291046CFA5C12734E02::-58:CUL0
2016.09.05 21:07:39.780 5: CUL0 sending As11B8A0021DA4622782910455B720B8CF5F02
2016.09.05 21:07:39.782 5: CUL 278291 dly:96ms
2016.09.05 21:07:39.879 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0455B720B8CF5F02
2016.09.05 21:07:39.977 5: CUL/RAW: /A19B8A2032782911DA4629BA1CAF28A8E0E74D0311507B15B4D8231

2016.09.05 21:07:39.978 4: CUL_Parse: CUL0 A 19 B8 A203 278291 1DA462 9BA1CAF28A8E0E74D0311507B15B4D8231 -49.5
2016.09.05 21:07:39.980 5: CUL0 dispatch A19B8A2032782911DA4629BA1CAF28A8E0E74D0311507B15B4D82::-49.5:CUL0
2016.09.05 21:07:40.074 5: CUL0 sending As11B8A0021DA4622782910431F506C4771902
2016.09.05 21:07:40.075 5: CUL 278291 dly:95ms
2016.09.05 21:07:40.172 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0431F506C4771902
2016.09.05 21:07:40.264 5: CUL/RAW: /A0CB8A2412782911DA46201EEC831

2016.09.05 21:07:40.265 4: CUL_Parse: CUL0 A 0C B8 A241 278291 1DA462 01EEC831 -49.5
2016.09.05 21:07:40.267 5: CUL0 dispatch A0CB8A2412782911DA46201EEC8::-49.5:CUL0
2016.09.05 21:07:40.271 5: CUL0 sending As11B8A0021DA4622782910431F506C4771902
2016.09.05 21:07:40.272 5: CUL 278291 dly:94ms
2016.09.05 21:07:40.368 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0431F506C4771902
2016.09.05 21:07:40.456 5: CUL0 sending As11B8A0021DA4622782910431F506C4771902
2016.09.05 21:07:40.458 5: CUL 278291 dly:96ms
2016.09.05 21:07:40.555 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0431F506C4771902
2016.09.05 21:07:40.652 5: CUL0 sending As11B8A0021DA4622782910431F506C4771902
2016.09.05 21:07:40.653 5: CUL 278291 dly:96ms
2016.09.05 21:07:40.751 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 0431F506C4771902
2016.09.05 21:07:40.846 5: CUL/RAW: /A19B8A2032782911DA462AD0AE0625856903C68231A56B9CF4D032E
A0CB8A2412782911DA46201EEC82A

2016.09.05 21:07:40.847 4: CUL_Parse: CUL0 A 19 B8 A203 278291 1DA462 AD0AE0625856903C68231A56B9CF4D032E -51
2016.09.05 21:07:40.849 5: CUL0 dispatch A19B8A2032782911DA462AD0AE0625856903C68231A56B9CF4D03::-51:CUL0
2016.09.05 21:07:40.858 5: CUL0 sending As11B880021DA4622782910101C800299e8100
2016.09.05 21:07:40.860 5: CUL 278291 dly:88ms
2016.09.05 21:07:40.949 4: CUL_send:  CUL0As 11 B8 8002 1DA462 278291 0101C800299e8100
2016.09.05 21:07:41.069 4: CUL_Parse: CUL0 A 0C B8 A241 278291 1DA462 01EEC82A -53
2016.09.05 21:07:41.072 5: CUL0 dispatch A0CB8A2412782911DA46201EEC8::-53:CUL0
2016.09.05 21:07:41.075 5: CUL0 sending As11B8A0021DA46227829104BBD4EC49089D02
2016.09.05 21:07:41.077 5: CUL 278291 dly:94ms
2016.09.05 21:07:41.172 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 04BBD4EC49089D02
2016.09.05 21:07:41.274 5: CUL0 sending As11B8A0021DA46227829104BBD4EC49089D02
2016.09.05 21:07:41.275 5: CUL 278291 dly:96ms
2016.09.05 21:07:41.373 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 04BBD4EC49089D02
2016.09.05 21:07:41.471 5: CUL0 sending As11B8A0021DA46227829104BBD4EC49089D02
2016.09.05 21:07:41.472 5: CUL 278291 dly:96ms
2016.09.05 21:07:41.570 4: CUL_send:  CUL0As 11 B8 A002 1DA462 278291 04BBD4EC49089D02

Auch wenn ich aesCommReq auf 0 setze läuft es nicht rund:

Eventmonitor:

Code Auswählen

2016-09-05 21:09:01.423 LaCrosse Thermo_KuehlschrankHund temperature: -0.3
2016-09-05 21:09:01.493 CUL_HM EG_FensterBuero aesCommToDev: pending
2016-09-05 21:09:01.692 CUL_HM EG_FensterBuero battery: ok
2016-09-05 21:09:01.692 CUL_HM EG_FensterBuero contact: closed (to vccu)
2016-09-05 21:09:01.692 CUL_HM EG_FensterBuero closed
2016-09-05 21:09:01.692 CUL_HM EG_FensterBuero trigger_cnt: 239
2016-09-05 21:09:01.778 CUL_HM EG_FensterBuero aesCommToDev: fail
2016-09-05 21:09:01.778 CUL_HM EG_FensterBuero trig_aes_vccu: fail:239
2016-09-05 21:09:01.987 CUL_HM EG_FensterBuero aesCommToDev: fail
2016-09-05 21:09:01.987 CUL_HM EG_FensterBuero trig_aes_vccu: fail:239

Log:

Code Auswählen


2016.09.05 21:09:01.504 5: CUL/RAW: /A0CB9A6412782911DA46201EF0031

2016.09.05 21:09:01.505 4: CUL_Parse: CUL0 A 0C B9 A641 278291 1DA462 01EF0031 -49.5
2016.09.05 21:09:01.507 5: CUL0 dispatch A0CB9A6412782911DA46201EF00::-49.5:CUL0
2016.09.05 21:09:01.515 5: CUL0 sending As0DB980021DA4622782910101C800
2016.09.05 21:09:01.517 5: CUL 278291 dly:89ms
2016.09.05 21:09:01.608 4: CUL_send:  CUL0As 0D B9 8002 1DA462 278291 0101C800
2016.09.05 21:09:01.796 5: CUL/RAW: /A0CB9A2412782911DA46201EF0030

2016.09.05 21:09:01.797 4: CUL_Parse: CUL0 A 0C B9 A241 278291 1DA462 01EF0030 -50
2016.09.05 21:09:01.799 5: CUL0 dispatch A0CB9A2412782911DA46201EF00::-50:CUL0
2016.09.05 21:09:01.803 5: CUL0 sending As0DB980021DA4622782910101C800
2016.09.05 21:09:01.804 5: CUL 278291 dly:94ms
2016.09.05 21:09:01.900 4: CUL_send:  CUL0As 0D B9 8002 1DA462 278291 0101C800

Ist das bei Euch auch so mit AES und dem HM-SEC-SC-2. Der steht im Register sign auf ON.

Der Aktor HM-LC-Sw1-Pl-DN-R1 läuft ohne Probleme auf AES !!!!!
Ein Implementierungsfehler des HM-SEC-SC-2??

********* Da ein Problem, dass nicht mehr ganz zum Titel passt, mache ich einen neuen Thread auf!

Greets

Byte