Fensterkontakt

Begonnen von ulli, 17 Januar 2016, 13:01:24

Vorheriges Thema - Nächstes Thema

ulli

Hallo zusammen,

ich bin gerade dabei mir endlich Fensterkontakt zu zulegen. Dafür plante ich aktuell die HM-Sec-SCo (optisch) zu verwenden.
Ist der Betrieb der Kontakte nur mit einem CUL möglich? Oder brauch ich für eine Art Erstkonfiguration dieses Homematic USB Stick?

Hinzu kommt, dass mich folgender Hinweis auf der ELV Seite  irritiert:
"Nicht kompatibel mit der BidCoS®-Alarmzentrale HM-Sec-Cen und Funk-Wandthermostaten HM-CC-TC."
(http://www.elv.de/homematic-funk-tuer-fensterkontakt-optisch-komplettbausatz.html)

Gibt es Unterschiede in den Homematic Fensterkontakten? Ich weiß nur das es optische und REED-Relais Kontakte gibt, welche aber meines Erachtens auf Seiten der Funkverbindung identisch sind, oder? d.h. für einen reinen Betrieb der Fensterkontakte mit FHEM über einen CUL dürfte ich keine Probleme haben, oder?
(Das sind die einzigen Homematic Komponenten die ich dann im Haus habe)

Besten Dank schon mal im Voraus.

frank

Zitatd.h. für einen reinen Betrieb der Fensterkontakte mit FHEM über einen CUL dürfte ich keine Probleme haben,
richtig. für homematic haben hmlan und hmusb timingvorteile gegenüber einem cul.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

ulli

Ok, danke soweit.
Aber wie ist denn folgende Aussage zu werten?
"Nicht kompatibel mit der BidCoS®-Alarmzentrale HM-Sec-Cen und Funk-Wandthermostaten HM-CC-TC."
Bedeutet das das es ein anderes Protokoll ist oder kein AES besitzt?

frank

ZitatBedeutet das das es ein anderes Protokoll ist oder kein AES besitzt?
der ist sogar ab werk auf aes gesetzt.
warum er nicht mit dem hm-cc-tc funktionieren sollte, ist mir schleierhaft. ich benutze einige dieser thermostate, aber keinen optischen sensor.
die alarmzentrale nutzt wohl ein anderes protokoll.
FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

martinp876

Wenn AES genutzt wird brauchen beide peers den gleichen key

ulli

Gibt es eine Möglichkeit ohne AES  die Fensterkontakte mit einem cul  zu verwenden ohne den HM stick zu besitzen?
Z.b. über den cul das AES  zu deaktivieren?

frank

FHEM: 6.0(SVN) => Pi3(buster)
IO: CUL433|CUL868|HMLAN|HMUSB2|HMUART
CUL_HM: CC-TC|CC-VD|SEC-SD|SEC-SC|SEC-RHS|Sw1PBU-FM|Sw1-FM|Dim1TPBU-FM|Dim1T-FM|ES-PMSw1-Pl
IT: ITZ500|ITT1500|ITR1500|GRR3500
WebUI [HMdeviceTools.js (hm.js)]: https://forum.fhem.de/index.php/topic,106959.0.html

Newima1201

Hallo zusammen,

ich verzweifele gerade beim Pairing der optischen Tür-/Fensterkontakte.
Es will einfach nicht gelingen.
Die Rawmessages bekommt FHEM.
Das Perl-Modul zur AES-Encryption habe ich über cpan auch installiert.
Mein CUL heisst VCCU und hat eine von mir vergebene 6-stellige hmid.
In VCCU_RAWMSG steht dann z.B. A3101008F1277C9F00003103014F711A00000D3C98C91FE000100000102010A0704039FDC4437F1981DA9999842A1898CA24F::-81:VCCU

wenn ich jetzt den CUL mittels set hmPairForSec 120 in den Pairing mode schicke und auf dem Kontakt den Taster drücke, blinkt die LED immer nur gelb. Von Pairing keine Spur. Was mache ich da falsch?

martinp876

Logge einmal das anlernen, siehe sniffen in wiki
Die abgebildete msg ist bloedsinn

Newima1201

Moin,

hier noch ein paar ergänzende Daten zu meinem Problem mit dem Anlernen des optische Türkontakts.
Mein CUL ist wie folgt definiert/konfiguriert
# *********** CUL als VCCU definieren ***********
define VCCU CUL /dev/ttyACM1@38400 0000
attr VCCU hmId 123458
attr VCCU hmProtocolEvents 2_dumpFull
attr VCCU model CUL
attr VCCU rfmode HomeMatic
attr VCCU room Hardware
attr VCCU showtime 1
attr VCCU verbose 4


Der Türkontakt ist so definiert
# ********** Fensterkontakt OG West **********
define HM_Fenster2 CUL_HM 1277C9
attr HM_Fenster2 IODev VCCU
attr HM_Fenster2 actCycle 001:50
attr HM_Fenster2 actStatus alive
attr HM_Fenster2 autoReadReg 4_reqStatus
attr HM_Fenster2 expert 2_full
attr HM_Fenster2 firmware 1.0
attr HM_Fenster2 model HM-SEC-SCo
attr HM_Fenster2 peerIDs 00000000,
attr HM_Fenster2 rawToReadable 1
attr HM_Fenster2 room CUL_HM
attr HM_Fenster2 subType switch
attr HM_Fenster2 verbose 5
attr HM_Fenster2 webCmd statusRequest:toggle:on:off
#attr HM_Fenster2 actStatus alive
#attr HM_Fenster2 aesKey 1
define FileLog_HM_Fenster2 FileLog ./log/HM_Fenster2Sco_1277C9-%Y.log HM_Fenster2


Evtl. sind einige Einträge überflüssig? Ich habe nun schon ein paar Tage lang alles mögliche probiert, aber es wird zusehens ein stochern im Nebel :-\
Das Log zum Pairing sieht dann so aus
2016.01.23 17:23:23.463 4: CUL_Parse: VCCU A 31 01 008F 12658D F00003 103014F711A00000D3C98C9224000100000102010A0704030B8E44A0E4BA18BBC9C238204B8B3F4935 -47.5
2016.01.23 17:23:23.560 1: RCV L:31 N:01 F:00 CMD:8F SRC:HM_Fenster3 DST:F00003 103014F711A00000D3C98C9224000100000102010A0704030B8E44A0E4BA18BBC9C238204B8B3F49 ()
2016.01.23 17:23:24.777 4: CUL_Parse: VCCU A 31 01 008F 1277C9 F00003 103014F711A00000D3C98C91FE000100000102010A070403786747425B7C7980B04D952C880B5A192C -52
2016.01.23 17:23:24.780 1: RCV L:31 N:01 F:00 CMD:8F SRC:HM_Fenster2 DST:F00003 103014F711A00000D3C98C91FE000100000102010A070403786747425B7C7980B04D952C880B5A19 ()
2016.01.23 17:23:33.662 4: CUL_Parse: VCCU A 31 01 008F 12658D F00003 103014F711A00000D3C98C9224000100000102010A0704030B8E44A0E4BA18BBC9C238204B8B3F492D -51.5
2016.01.23 17:23:33.667 4: CUL_HM HM_Fenster3 dupe: dont process
2016.01.23 17:23:34.870 4: CUL_Parse: VCCU A 31 01 008F 1277C9 F00003 103014F711A00000D3C98C91FE000100000102010A070403786747425B7C7980B04D952C880B5A192D -51.5
2016.01.23 17:23:34.873 4: CUL_HM HM_Fenster2 dupe: dont process
2016.01.23 17:23:43.688 4: CUL_Parse: VCCU A 31 01 008F 12658D F00003 103014F711A00000D3C98C9224000100000102010A0704030B8E44A0E4BA18BBC9C238204B8B3F492F -50.5
2016.01.23 17:23:43.842 4: CUL_HM HM_Fenster3 dupe: dont process
2016.01.23 17:23:44.968 4: CUL_Parse: VCCU A 31 01 008F 1277C9 F00003 103014F711A00000D3C98C91FE000100000102010A070403786747425B7C7980B04D952C880B5A192B -52.5
2016.01.23 17:23:44.971 4: CUL_HM HM_Fenster2 dupe: dont process
2016.01.23 17:23:53.697 4: CUL_Parse: VCCU A 31 01 008F 12658D F00003 103014F711A00000D3C98C9224000100000102010A0704030B8E44A0E4BA18BBC9C238204B8B3F4930 -50
2016.01.23 17:23:53.700 4: CUL_HM HM_Fenster3 dupe: dont process
2016.01.23 17:23:55.095 4: CUL_Parse: VCCU A 31 01 008F 1277C9 F00003 103014F711A00000D3C98C91FE000100000102010A070403786747425B7C7980B04D952C880B5A1929 -53.5
2016.01.23 17:23:55.102 4: CUL_HM HM_Fenster2 dupe: dont process
2016.01.23 17:24:02.715 4: CUL_Parse: VCCU A 24 00 008F 1277C9 F00001 2001023014F711A00000D3C98C91FE00010400010A0701060200093C -44
2016.01.23 17:24:02.724 1: RCV L:24 N:00 F:00 CMD:8F SRC:HM_Fenster2 DST:F00001 2001023014F711A00000D3C98C91FE00010400010A070106020009 ()
2016.01.23 17:24:03.785 4: CUL_Parse: VCCU A 31 01 008F 12658D F00003 103014F711A00000D3C98C9224000100000102010A0704030B8E44A0E4BA18BBC9C238204B8B3F492F -50.5
2016.01.23 17:24:03.790 4: CUL_HM HM_Fenster3 dupe: dont process
2016.01.23 17:24:05.390 4: CUL_Parse: VCCU A 31 01 008F 1277C9 F00003 103014F711A00000D3C98C91FE000100000102010A07040311AB83926DC7553389A2C5A23DF011093C -44
2016.01.23 17:24:05.394 1: RCV L:31 N:01 F:00 CMD:8F SRC:HM_Fenster2 DST:F00003 103014F711A00000D3C98C91FE000100000102010A07040311AB83926DC7553389A2C5A23DF01109 ()
2016.01.23 17:24:13.963 4: CUL_Parse: VCCU A 31 01 008F 12658D F00003 103014F711A00000D3C98C9224000100000102010A0704030B8E44A0E4BA18BBC9C238204B8B3F4931 -49.5
2016.01.23 17:24:13.968 4: CUL_HM HM_Fenster3 dupe: dont process
2016.01.23 17:24:15.538 4: CUL_Parse: VCCU A 31 01 008F 1277C9 F00003 103014F711A00000D3C98C91FE000100000102010A07040311AB83926DC7553389A2C5A23DF011092B -52.5
2016.01.23 17:24:15.544 4: CUL_HM HM_Fenster2 dupe: dont process


Ich denke, da findet gar kein Pairing statt, oder?
Im Log des Sensors steht dann aber ein
HM_Fenster2 Activity: alive


martinp876

Korrekt, keine config messages zu sehen. Die vorhandenen messages sind erstaunlich lang. Da stimmt etwas nicht.
Klappt sonst alles???

Newima1201

Hallo,

was meinst Du mit alles?
Z.B. kann ich die slowrf messages der anderen Sensoren über den anderen CUL lesen. Das geht.
Aber die optischen FT-Kontakte sind bei mir unter Homematic die einzigen. Daher ist es neu für mich und sonst gibt es auch nichts was unter Homematic schon installiert wäre.
Irgendwie komme ich auch mit dem Beitrag http://www.fhemwiki.de/wiki/HomeMatic_Devices_pairen nicht weiter. Die 10-stellige Serialnummer habe ich nicht gefunden. Dafür habe ich einen elendig langen  Key mit 5 * 5 Stellen oder eien SGTIN mit 6 *4 Stellen für jedes Device mitgeliefert bekommen. (Plus QR-Code)
komisch ist auch folgendes:
Dem Fensterkontakt 3 habe ich mittels attribut einen hmkey 1234567890 angegeben.
Danach hat fhem (wie prophezeit) eine md5 errechnet und diese in den hmkey eingetragen. Also die AES-Thematik scheint grundsätzlich zu funktionieren.
Versuche ich das beim nächsten Sensor, bekomme ich eine Fehlermeldung, das man das nur beim Device VCCU machen könnte "use hmKey only for vccu device" >:( Das ist totaler quatsch, da man das beim vccu nicht machen kann. dort gibt es den hmkey nicht nur die hmid.
Kann das sein, das man damit die externe VCCU von ELV konfigurieren kann?
Die Fehlermeldung ist jedenfalls irreführend, wenn das so ist.
Ich versuche es für einen Sensor nochmal mit autocreate.




Newima1201

So, ich bin einen Schritt weiter

mittel set HM_Fenster3 getconfig habe ich folgendes erzeugen können.

2016.01.23 22:00:38.595 4: CUL_send:  VCCUAs 10 02 A001 123458 12858D 00040000000000
2016.01.23 22:00:38.610 1: SND L:10 N:02 F:A0 CMD:01 SRC:123458 DST:HM_Fenster3 00040000000000 (CONFIG_PARAM_REQ CHANNEL:0x00 PEER_ADDRESS:0x000000 PEER_CHANNEL:0x00 PARAM_LIST:0x00) (,BIDI,RPTEN)
2016.01.23 22:00:42.621 4: CUL_send:  VCCUAs 10 02 A001 123458 12858D 00040000000000
2016.01.23 22:00:45.681 4: CUL_Parse: VCCU A 31 01 008F 12658D F00003 103014F711A00000D3C98C9224000100000102010A07040367AA9A8A8360B8389FD8AE3223D825091C -60
2016.01.23 22:00:45.692 1: RCV L:31 N:01 F:00 CMD:8F SRC:12658D DST:F00003 103014F711A00000D3C98C9224000100000102010A07040367AA9A8A8360B8389FD8AE3223D82509 ()
2016.01.23 22:00:45.694 1: RCV L:31 N:01 F:00 CMD:8F SRC:12658D DST:F00003 103014F711A00000D3C98C9224000100000102010A07040367AA9A8A8360B8389FD8AE3223D82509 ()
2016.01.23 22:00:45.697 3: VCCU: Unknown code A3101008F12658DF00003103014F711A00000D3C98C9224000100000102010A07040367AA9A8A8360B8389FD8AE3223D82509::-60:VCCU, help me!
2016.01.23 22:00:48.358 4: CUL_send:  VCCUAs 10 02 A001 123458 12858D 00040000000000
2016.01.23 22:00:53.529 4: CUL_send:  VCCUAs 10 02 A001 123458 12858D 00040000000000
2016.01.23 22:00:55.582 4: CUL_Parse: VCCU A 31 01 008F 12658D F00003 103014F711A00000D3C98C9224000100000102010A07040367AA9A8A8360B8389FD8AE3223D825091B -60.5
2016.01.23 22:00:55.586 1: RCV L:31 N:01 F:00 CMD:8F SRC:12658D DST:F00003 103014F711A00000D3C98C9224000100000102010A07040367AA9A8A8360B8389FD8AE3223D82509 ()
2016.01.23 22:00:55.588 1: RCV L:31 N:01 F:00 CMD:8F SRC:12658D DST:F00003 103014F711A00000D3C98C9224000100000102010A07040367AA9A8A8360B8389FD8AE3223D82509 ()
2016.01.23 22:00:55.591 3: VCCU: Unknown code A3101008F12658DF00003103014F711A00000D3C98C9224000100000102010A07040367AA9A8A8360B8389FD8AE3223D82509::-60.5:VCCU, help me!
2016.01.23 22:01:52.303 4: CUL_Parse: VCCU A 31 01 008F 12658D F00003 103014F711A00000D3C98C9224000100000102010A07040367AA9A8A8360B8389FD8AE3223D8250937 -46.5

Was ich jetzt nicht verstehe, das ist, das es so aussieht, als ob der Tk seine Message an einen Adresse 0xF00003 zurückschickt. Dann hat aber doch das pairing nicht funktioniert, da hier doch meine VCCu-Adresse 123458 stehen müsste, oder?



martinp876

Ich tue mich schwer es zu verstehen.
12585d ist der fk.
1277c9 ist wer?
Die zu langen Nachrichten werden nicht korrekt nummeriert. Eigentlich sind die Müll. Entweder ein anderes Format oder eben Schrott.
Kannst du von diesem oder einem anderen device etwas ordentliches empfangen? Oder spinnt dein IO?

Newima1201

Hi,
ich konnte von dem CUL im slowrf-Format was ordentliches empfangen. der funktionierte einwandfrei.
Die langen Meldungen kommen, seit ich hmProtocolEvents 2_dumpFull
aktiviert habe.
Die zweite Nummer stammt von einem weiteren TK.
Ich habe dann mal "back to the roots" ein fhem.cfg aufgesetzt, wo nichts drin ist und der eine CUL neu per usbcreate erkannt wird.
Da der im slowrf mode beginnt, wurden auch alle passenden Sensoren sofort erkannt und eingebunden (geht echt super). Alle slowrf Devices haben ein auch ein AutoCr_<Device>-2016.log

Dann habe ich den CUL auf Homematic umgestellt und ihm eine eigene hmid (123458) verpasst.
Bei einem shutdown restart oder rereadcfg hätte ich erwartet, das autocreate aktiv wird und die Sensoren findet. Das ist nicht der Fall. ich kann die Devices nur von Hand anlegen.