Hallo,
ich habe gestern eine 4-Tasten Keymatic FB (ohne Keymatic) an FHEM mit HMLAN-Adapter angelernt, weil ich die erstmal als FB für die Alarmanlage benutzen möchte. Angelernt habe ich zunächst mit der HMLAN-Software, die Verbindung ist für alle 4 Tasten als "gesichert" gekennzeichnet. Der Schlüssel ist von mir seinerzeit geändert und auch in FHEM eingetragen. Nach dem Danach habe ich das mittels hmPairForSec 600 FHEM beigebracht, das Gerät in HFB2 umbenannt und mit
set HFB2_light peerChan 0 HMLAN1 single
set HFB2_lock peerChan 0 HMLAN1 single
set HFB2_unlock peerChan 0 HMLAN1 single
set HFB2_open peerChan 0 HMLAN1 single
die Tasten mit HMLAN gepeert, um die Rückmeldung durch die grüne LED zu bekommen. Das funktioniert auch alles. Ich weiß, dass man letzteres eigentlich mit einem Channel peeren sollte und nicht mit einem Gerät, aber da im Log nicht "to broadcast" sondern "to HMLAN1" stand, wollte ich mir den virtuellen Aktor sparen.
Ein paar Dinge stören mich noch bzw. habe ich nicht richtig verstanden. ;)
1. Die Tasten "prellen" manchmal (vor allem bei schlechter Empfangslage, Quittungs-LED rot). Im Log steht dann beispielsweise mehrfach:
2014-07-21_08:03:03 HFB2 HFB2_lock Short (to HMLAN1)
2014-07-21_08:03:05 HFB2 HFB2_lock Short (to HMLAN1)
2014-07-21_08:03:06 HFB2 HFB2_lock Short (to HMLAN1)
Obwohl man nur einmal gedrückt hat und eine der Tasten sogar auf Doppelklick gestellt ist, man also eigentlich gar nicht prellen kann.
2. Ich habe versucht, AES in der Kommunikation mit FHEM zu erzwingen:
set HFB2_lock regSet expectAES on HMLAN1
Das führt dazu, dass die Bestätigungs-LED nach dem Senden immer rot quittiert. Auswerten kann man die Tasten immer noch, selbst wenn der HMLAN-Schlüssel in FHEM auskommentiert wird. Kann es sein, dass dieses AES-Erzwingen nur mit dem Keymatic-Antrieb Sinn hat? Könnte nun nicht jemand den Funkverkehr der FB mit FHEM mitsniffen und mir (wenn ich mal einen Keymatic--Antrieb über die FB steuere) die Tür öffnet?!
3. Das Auswerten des langen Tastendrucks ist schwierig, weil kein "LongRelease" kommt. Ich habe gelesen, dass dazu ein Aktor gepeert sein muss. Ändert sich das, wenn ich die FB mal mit einem Keymatic-Antrieb kopple? Ich habe noch eine 12-Tasten-FB (HM-RC-12-B), die ist auch nur mit dem HMLAN1 und sonst keinem Aktor verheiratet. Bei der kommt immer das "LongRelease".
4. Nach dem Drücken einer Taste steht im FHEM-Log
2014.07.21 08:03:05 3: CUL_HM set HFB2_open getConfig
2014.07.21 08:03:05 3: CUL_HM set HFB2_light getConfig
2014.07.21 08:03:05 3: CUL_HM set HFB2_lock getConfig
HMinfo liefert mir
missing register list
HFB2_light: RegL_01:
HFB2_lock: RegL_01:
HFB2_open: RegL_01:
Die vierte Taste (die HMinfo nicht bemängelt) hat dort "RegL_01: 04:10 08:01 09:00 00:00" stehen. Bei den anderen steht dieses Register leer oder wird gar nicht angezeigt. Irgendwas habe ich dort nicht vollständig abgeschlossen, aber was?
Das waren zunächst mal meine wichtigsten Fragen.
Ich möchte später mal erreichen, dass die Tür nur mit der FB geöffnet werden kann, aber aus Sicherheitsgründen zunächst mal nicht so einfach durch die Weboberfläche. Ich möchte mir eigentlich nur für den Notfall irgendwo die Möglichkeit lassen, die Tür zu öffnen, am besten mit einem möglichst kryptischen Befehl. Hat jemand eine Idee, das zu realisieren?
Zitatsondern "to HMLAN1" stand, wollte ich mir den virtuellen Aktor sparen.
man kann nur mit einen Channel peeren. Sicher hast du mit HMLAN1 channel 01 gepeert.
Wenn du eine vccu einrichtest wird dies auch als "kanal der vccU" also als "Kanal der Zentrale" (oder einer deiner Zentralen, falls du mehrere hast) eingetragen. Dann ist es auch besser sichtbar und steuerbar.
ZitatObwohl man nur einmal gedrückt hat und eine der Tasten sogar auf Doppelklick gestellt ist, man also eigentlich gar nicht prellen kann.
es könnte sein, dass eine Nachricht wiederholt wird. Das sollte aber nicht zu doppelten Events führen. Es gibt aber auch Readings, die dir anzeigen, ob es ein neuer trigger ist - da steht eine Nummer dahinter.
ZitatDas führt dazu, dass die Bestätigungs-LED nach dem Senden immer rot quittiert
.
dann hat die Zentrale (HMLAN in diesem Fall)AES von der FB2 gefordert, dies wurde nicht korrekt beantwortet und FHEM (besser HMLAN) hat kein ACK gesendet.
=> dein AES key stimmt nicht.
ZitatAuswerten kann man die Tasten immer noch, selbst wenn der HMLAN-Schlüssel in FHEM auskommentiert wird.
klar. Es wird der trigger von der FB2 in klartext gesendet - und ausgewertet. Da könnte/sollte man noch ein Reading einbauen "Trigger with AES acceptes". Das gibt es aktuell nicht.
ZitatKann es sein, dass dieses AES-Erzwingen nur mit dem Keymatic-Antrieb Sinn hat?
nein
ZitatKönnte nun nicht jemand den Funkverkehr der FB mit FHEM mitsniffen
ja
Zitatund mir (wenn ich mal einen Keymatic--Antrieb über die FB steuere) die Tür öffnet?!
vielleicht. wenn du die Tür über die Zentrale öffnest und die Zentrale auf ungesicherte Trigger reagiert - und der Dieb dies erfasst - ja, dann kann er.
In der Zentrale ist es deine Aufgaben sicherzustellen, dass der Sender auch korrekt quittiert hat.
ZitatDas Auswerten des langen Tastendrucks ist schwierig, weil kein "LongRelease" kommt.
es kommt eines, wenn man den Channel gepeert hat - sonst kommt keines.
ZitatÄndert sich das, wenn ich die FB mal mit einem Keymatic-Antrieb kopple?
klar - das kommt, egal mit wem du peerst (auch mit virtuellem Channel)
ZitatIch habe noch eine 12-Tasten-FB (HM-RC-12-B), die ist auch nur mit dem HMLAN1 und sonst keinem Aktor verheiratet. Bei der kommt immer das "LongRelease"
.
bist du sicher, dass die RC4 wirklich gepeert ist? Logge einmal deinen long-press
ZitatBei den anderen steht dieses Register leer oder wird gar nicht angezeigt.
leer kann nicht sein. leer gibt es garnicht in der SW - zumindest "00" sollte drin stehen. Mache ein getConfig.
Zunächst mal vielen Dank für Deine Zeit und die umfangreiche Antwort.
Zitat
dann hat die Zentrale (HMLAN in diesem Fall)AES von der FB2 gefordert, dies wurde nicht korrekt beantwortet und FHEM (besser HMLAN) hat kein ACK gesendet.
=> dein AES key stimmt nicht.
Das habe ich befürchtet. Da ist noch etwas im Argen. In den Readings der FB steht
CommandAccepted yes
D-Firmware 1.2
D-serialNr LEQ012345
PairedTo 0x987654
R-localResDis off
R-pairCentral 0x987654
aesKeyNbr 02
battery ok
In meiner gesamten Installation sollte es aber nur einen Key geben. Bevor ich das allererste Homematic-Gerät installiert habe, habe ich mit dem Windows-Programm den Key des HMLAN-Adapters geändert und nur dieser eine Key steht auch in der Datei der Windows-Software drin.
Alle Geräte paire ich zunächst mit der Windows-Software und dem aktivierten geänderten Key (den ich natürlich beim Zurückschalten auf FHEM wieder rausnehme und dort über attr HMLAN1 hmKey setze. Wie kann da ein falscher AES-Key in die FB kommen?
Dass der neue Key im System implementiert ist, kann ich über meine Aktoren feststellen. Diese schalten nicht mehr, wenn ich meinen persönlichen Key aus attr HMLAN1 hmKey auskommentiere.
Was das Prellen angeht: Kann das an meinem
attr HMLAN1 hmLanQlen 3_normalliegen? Mit dem Eintrag 1 hatte ich hin und wieder sporadische HMLAN-Disconnects.
[Edit:] Ich Idiot. jetzt habe ich das getconfig ausgelöst, obwohl ich im Büro bin und natürlich nicht die FB drücken kann... :o
setze einfach einmal den 2- key - ggf auf den gleichen wie den ersten. Die Devices verwalten auch die Nummer des AES keys - sicher um das Ändern möglich zu machen.
das Prellen hat nichts mit der q-lenzu tun. Zeichne einmal die messages auf.
Ich verstehe das so, dass ich in der entsprechenden Datei der Windows-Software einen zweiten Key eintrage, der mit dem ersten identisch ist und dann die FB erneut paire?
Ich hab das Log nicht mehr und hier im Büro auch die FB nicht. Aber bei LongPress sah das genauso aus, wie bei meiner 12-Tasten FB (nur ohne die Zeile LongRelease), nämlich so (upside down):
2014-07-20_23:21:16 HMRemote12 CMDs_done
2014-07-20_23:21:16 HMRemote12 HMRemote12_Btn_08 LongRelease 13-A040- (to HMLAN1)
2014-07-20_23:21:16 HMRemote12 battery: ok
2014-07-20_23:21:16 HMRemote12 HMRemote12_Btn_08 Long 12-8440- (to HMLAN1)
2014-07-20_23:21:16 HMRemote12 battery: ok
2014-07-20_23:21:16 HMRemote12 HMRemote12_Btn_08 Long 11-8440- (to HMLAN1)
2014-07-20_23:21:16 HMRemote12 battery: ok
2014-07-20_23:21:16 HMRemote12 HMRemote12_Btn_08 Long 10-8440- (to HMLAN1)
2014-07-20_23:21:16 HMRemote12 battery: ok
2014-07-20_23:21:15 HMRemote12 HMRemote12_Btn_08 Long 9-8440- (to HMLAN1)
2014-07-20_23:21:15 HMRemote12 battery: ok
2014-07-20_23:21:15 HMRemote12 HMRemote12_Btn_08 Long 8-8440- (to HMLAN1)
2014-07-20_23:21:15 HMRemote12 battery: ok
2014-07-20_23:21:15 HMRemote12 HMRemote12_Btn_08 Long 7-8440- (to HMLAN1)
2014-07-20_23:21:15 HMRemote12 battery: ok
2014-07-20_23:21:15 HMRemote12 HMRemote12_Btn_08 Long 6-8440- (to HMLAN1)
2014-07-20_23:21:15 HMRemote12 battery: ok
2014-07-20_23:21:14 HMRemote12 HMRemote12_Btn_08 Long 5-8440- (to HMLAN1)
2014-07-20_23:21:14 HMRemote12 battery: ok
2014-07-20_23:21:14 HMRemote12 HMRemote12_Btn_08 Long 4-8440- (to HMLAN1)
2014-07-20_23:21:14 HMRemote12 battery: ok
2014-07-20_23:21:14 HMRemote12 HMRemote12_Btn_08 Long 3-8440- (to HMLAN1)
2014-07-20_23:21:14 HMRemote12 battery: ok
2014-07-20_23:21:14 HMRemote12 HMRemote12_Btn_08 Long 2-8440- (to HMLAN1)
2014-07-20_23:21:14 HMRemote12 battery: ok
2014-07-20_23:21:13 HMRemote12 HMRemote12_Btn_08 Long 1-8440- (to HMLAN1)
Allerdings hat sich diese Zahl (hier 8440) alle 3 oder 4 Einträge geändert.
ZitatIch verstehe das so, dass ich in der entsprechenden Datei der Windows-Software einen zweiten Key eintrage, der mit dem ersten identisch ist
ja
Zitatund dann die FB erneut paire?
nein - pairen hat nichts mit AES zu tun
Offen ist bei mir noch ein Detail bei der key Zuweisung. Der User hatte damals keine Logs mehr gesendet. Evtl muss man dem HMLAN mitteilen,welcher key für welches Device zu nutzen ist. Ob dies auch mit der nummer des key oder nur dem keyinhalt zusammen hängt ist nicht gesichert. Könnte aber in die Richtung gehen...
ZitatAllerdings hat sich diese Zahl (hier 8440) alle 3 oder 4 Einträge geändert.
sollte sich in jeder zeile ändern. Hier brauche ich ggf die messages.
Ok, ich mache das heute Abend ... mit der FB in der Hand. :D
Jetzt habe ich nochmal (zum xundneunzigsten Mal) die Wiki-Seite AES Encryption gelesen. Unglaublich, man lernt immer noch dazu. :D
Klar, wo Du es sagst: pairen ist Blödsinn. Die Schlüssel werden ja nur dem HMLAN-Adapter mitgeteilt. Muss ich das dann auch in FHEM über "attr HMLAN1 hmKey2" machen bzw. genügt vielleicht sogar nur das?
Ist es richtig, dass sich diese drei 4-Tasten-Fernbedienungen (Standard, Alarmanlage, Keymatic) eigentlich nur durch den Aufdruck und ihren Namen unterscheiden oder hat die Keymatic-FB noch mehr integriert? Meine ist übrigens eine einzelne, also NICHT im Bundle mit einem Antrieb gekaufte Neuware und damit (hoffentlich) noch nicht gepairt gewesen.
Was passiert eigentlich, wenn ich die FB an einen Keymatic-Antrieb anlerne? Das geschieht doch zwangsläufig immer mit AES. Welcher Schlüssel wird dafür hergenommen? Ist der im Schloßantrieb hinterlegt? Ist das etwa der universelle, den ALLE Homematic-Geräte mit AES verordnet bekommen und den jeder kennt? Muss ich den Schloßantrieb also zwingend an die Zentrale anlernen, wenn ich meinen eigenen Schlüssel benutzen möchte? Kann ich den Antrieb hinterher wieder ablernen und den eigenen (AES-)Schlüssel trotzdem nutzen?
Sind Keymatic-Antriebe, die nicht an eine Zentrale angelernt werden, somit generell unsicher?
Sorry für die vielen Fragen, aber da das sicherheitsrelevant ist, möchte ich das ganz genau wissen...
Seit vielen Jahren habe ich die alte Keymatic, die nicht kompatibel zu Homematic ist und bin sehr zufrieden damit. Ich möchte nun gern die neue verbauen, aber eigentlich nur die Schaltzustände auslesen, um die Alarmanlage und den zustand "abwesend" damit zu schalten. Tür lock mit FB --> abwesend, scharf; unlock oder open mit FB --> anwesend, unscharf; lock direkt am Antrieb: anwesend, intern scharf. Deshalb muss auch die Kommunikation mit der FB AES-signiert sein. Die Tür öffnen über die Zentrale möchte ich eigentlich nicht oder nur als Notoption (falls mal ausgesperrt) .
Aber erstmal muss die FB alleine vernünftig funktionieren.
ZitatDie Schlüssel werden ja nur dem HMLAN-Adapter mitgeteilt.
die HM-SW schreibt es ins Device (und ins HMLAN, aber da nur ins RAM)
ZitatMuss ich das dann auch in FHEM über "attr HMLAN1 hmKey2" machen bzw. genügt vielleicht sogar nur das?
ein geändertes AES Attribut wird sofort ins HMLAN geschrieben.
ZitatIst es richtig, dass sich diese drei 4-Tasten-Fernbedienungen (Standard, Alarmanlage, Keymatic) eigentlich nur durch den Aufdruck und ihren Namen unterscheiden oder hat die Keymatic-FB noch mehr integriert?
schon. Sie haben einen anderen Code, damit die HM-SW es unterscheiden kann. Dann unterstützt die HM-SW das Programmieren (AES, Dual Buttons,...). Aber das ist nur "oben drüber". Man kann mit jeden Button das gleiche erreichen. FHEM unterstützt hier die defaults und der User legt fest, was der button machen soll.
ZitatWas passiert eigentlich, wenn ich die FB an einen Keymatic-Antrieb anlerne? Das geschieht doch zwangsläufig immer mit AES.
die keymatic wird immer nach einem key fragen -korrekt. Peeren geht von der Zentrale aus und ist wir immer 2-geteilt. Der teil der keymatic wird AES benötigen. Die FB nur wenn es eingeschaltet ist.
Operationell, also wenn die FB einen trigger sendet wird keymatic nach AES fragen und die FB muss antworten.
ZitatWelcher Schlüssel wird dafür hergenommen?
jede device hat einen key (meines wissens kann ein device nur einen, habe dafür aber keine bestätigung). Wenn sie sich unterhalten wollen (über AES) müssen sie den gleichen haben.
ZitatIst der im Schloßantrieb hinterlegt?
er muss in beiden hinterlegt sein - sonst kann es ja nicht geprüft werden. Der Aktor sendet einen String, der Sensor kodiert diesem mittels key und sendet zurück, der Aktor hat auch kodiert und prüft nun, ob die beiden identisch sind.
ZitatIst das etwa der universelle, den ALLE Homematic-Geräte mit AES verordnet bekommen und den jeder kennt?
den key solltest du verändern. Dann wird er in jedes Device übertragen (bin nicht sicher, ob er modifiziert wird, z.B. mit der ID).
Das (jedes) Device speichert diesen Key im Flash. Dieses Verteilen der Keys in die Devices unterstützt FHEM (noch) nicht. Daher kann man den key auch nur mit der HM-SW ändern.
Details:
das System kann mehrere Keys. Das ist notwendig, wenn du den key ändern willst. Dann sind zumindest kurzzeitig 2 keys im System, der alte und der neue. Das schreiben kann ja länger dauern (ein device ist gerade nicht verfügbar, es ist ein config-device undkeiner drückt anlernen,...). Daher hat jeder key eine nummer (wir erlauben gerade nummern 1-5). Möglich, dass es bis zu 255 keys sein könnten. So viele machen keinen Sinn, klar. Aber mit dem Konzept hat HM freie Hand keys kontinuierlich zu ändern und nachzügler zu behandeln.
ZitatMuss ich den Schloßantrieb also zwingend an die Zentrale anlernen, wenn ich meinen eigenen Schlüssel benutzen möchte?
an die FHEM-zentrale würde ich es immer. Zum key ändern musst du an die HM-SW - zwingend. Geschickt ist es daher, die HMId der HM-SW und die von FHEM identisch zu setzen. Dann ist kein pairen notwendig. (also einmal an der HM-SW, damit sie es kennt und einmal anlernen drücken für FHEM).
ZitatKann ich den Antrieb hinterher wieder ablernen
warum ablernen? nicht notwendig.
Zitatund den eigenen (AES-)Schlüssel trotzdem nutzen?
solltest du unbedingt.
ZitatSind Keymatic-Antriebe, die nicht an eine Zentrale angelernt werden, somit generell unsicher?
hm - gute Frage. Was du meinst wohl eher nicht. Wenn ein Device an einer Zentrale angelernt ist kann man es nicht so einfach an eine andere Zentrale anlernen - also angelernt leicht besser. Der keymatic sollte auch beim Anlernen schon einen key verlangen - von der Zentrale. Ich würde es an FHEM angelernt lassen. Sicherstellen musst du sowieso, dass keiner dein HMLAN häcken kann.
Zunächst mal die Reaktion auf LongPress:
2014-07-22_21:07:19 HFB2 CMDs_done
2014-07-22_21:07:19 HFB2 HFB2_lock Long 10-A240- (to HMLAN1)
2014-07-22_21:07:19 HFB2 battery: ok
2014-07-22_21:07:19 HFB2 HFB2_lock Long 9-8440- (to HMLAN1)
2014-07-22_21:07:19 HFB2 battery: ok
2014-07-22_21:07:18 HFB2 HFB2_lock Long 8-8440- (to HMLAN1)
2014-07-22_21:07:18 HFB2 battery: ok
2014-07-22_21:07:18 HFB2 HFB2_lock Long 7-8440- (to HMLAN1)
2014-07-22_21:07:18 HFB2 battery: ok
2014-07-22_21:07:18 HFB2 HFB2_lock Long 6-8440- (to HMLAN1)
2014-07-22_21:07:18 HFB2 battery: ok
2014-07-22_21:07:18 HFB2 HFB2_lock Long 5-8440- (to HMLAN1)
2014-07-22_21:07:18 HFB2 battery: ok
2014-07-22_21:07:17 HFB2 HFB2_lock Long 4-8440- (to HMLAN1)
2014-07-22_21:07:17 HFB2 battery: ok
2014-07-22_21:07:17 HFB2 HFB2_lock Long 3-8440- (to HMLAN1)
2014-07-22_21:07:17 HFB2 battery: ok
2014-07-22_21:07:17 HFB2 HFB2_lock Long 2-8440- (to HMLAN1)
2014-07-22_21:07:17 HFB2 battery: ok
2014-07-22_21:07:17 HFB2 HFB2_lock Long 1-8440- (to HMLAN1)
2014-07-22_21:09:09 HFB2 HFB2_open Long 7-A240- (to HMLAN1)
2014-07-22_21:09:09 HFB2 battery: ok
2014-07-22_21:09:09 HFB2 HFB2_open Long 6-8440- (to HMLAN1)
2014-07-22_21:09:09 HFB2 battery: ok
2014-07-22_21:09:09 HFB2 HFB2_open Long 5-8440- (to HMLAN1)
2014-07-22_21:09:09 HFB2 battery: ok
2014-07-22_21:09:08 HFB2 HFB2_open Long 4-8440- (to HMLAN1)
2014-07-22_21:09:08 HFB2 battery: ok
2014-07-22_21:09:08 HFB2 HFB2_open Long 3-8440- (to HMLAN1)
2014-07-22_21:09:08 HFB2 battery: ok
2014-07-22_21:09:08 HFB2 HFB2_open Long 2-8440- (to HMLAN1)
2014-07-22_21:09:08 HFB2 battery: ok
2014-07-22_21:09:08 HFB2 HFB2_open Long 1-8440- (to HMLAN1)
2014-07-22_21:09:08 HFB2 battery: ok
Das machen die anderen Tasten auch, man könnte also auf A240 abfragen. Die Taste, der ich "expectAES on" verordnet habe (Rotlicht) prellt immer noch und liefert bei LongPress:
2014-07-22_21:09:26 HFB2 CMDs_done
2014-07-22_21:09:26 HFB2 HFB2_light Long 3-A440- (to HMLAN1)
2014-07-22_21:09:26 HFB2 battery: ok
2014-07-22_21:09:26 HFB2 CMDs_done
2014-07-22_21:09:26 HFB2 HFB2_light Long 2-A440- (to HMLAN1)
2014-07-22_21:09:26 HFB2 battery: ok
2014-07-22_21:09:26 HFB2 CMDs_done
2014-07-22_21:09:26 HFB2 HFB2_light Long 1-A440- (to HMLAN1)
Zum AES-Schlüssel:
Das Eintragen des Schlüssels in die "keys" Datei der Bidcos-Software
Current Index = 1
Key 0 =
Key 1 = meinKey
Key 2 = meinKey
Last Index = 0
brachte keine Änderung. Immer noch Rotlicht auf der Taste. Die Readings der Taste:
CommandAccepted yes 2014-07-20 17:24:35
R-dblPress 0 s 2014-07-20 17:52:44
R-fhem01-expectAES on 2014-07-22 21:21:42
R-fhem01-peerNeedsBurst off 2014-07-22 21:21:42
R-longPress 0.4 s 2014-07-20 17:52:44
R-sign on 2014-07-22 21:05:20
RegL_01: 04:10 08:01 09:00 00:00 2014-07-22 21:21:41
RegL_04:fhem01 01:80 00:00 2014-07-22 21:21:42
peerList fhem01, 2014-07-22 21:21:41
state Short (to HMLAN1) 2014-07-22 21:22:00
trigger Short_72 2014-07-22 21:22:00
Ich habe auch mal PeerNeedsBurst auf on gestellt - keine Änderung.
Neuanlernen der Taste funktionierte auch, danach war expectAES wieder auf "off".
Langsam weiß ich auch nicht mehr...
Immerhin ist der issue 4 aus meinem Ausgangsposting nun verschwunden. Keine Fehler mehr in HMinfo und keine überflüssigen Logeinträge mehr bei Tastendruck.
Hi,
ich wollte eigentlich die rohmessages.
http://www.fhemwiki.de/wiki/Homematic_Nachrichten_sniffen
mit A240 sein einmal vorsichtig. lass mich die messages dazu sehen. Das sollte schon ein release sein - und auch so gemeldet werden.
Ich empfehle event-on-change-reading .*
Die Batteriemeldungen erzeugen unnötig Last.
zum AES - auch hier bitte die rohmessages.
Nebenthema:
Ich empfehle, einen vccu einzurichten und das HMLAN diesem zuzuordnen. Die vccu sollte entsprechend viele Kanäle haben,wie du gepeert hast (deine Register des Aktors sollten aktuell sein).
Im Kanal der vccu sollte dann der Aktor als peer stehen.
Wenn das so eingerichtet ist wird ein gutfall so aussehen
2014-07-22 22:30:38.564 CUL_HM FB FB_01 Short (to ccu)
2014-07-22 22:30:38.564 CUL_HM FB CMDs_done
2014-07-22 22:30:38.590 CUL_HM FB_01 Short (to ccu)
2014-07-22 22:30:38.330 CUL_HM FB_01 trigger: Short_47
2014-07-22 22:30:38.615 CUL_HM ccu_Btn1 trig_aes_FB_01: ok:0F
2014-07-22 22:30:38.615 CUL_HM ccu_Btn1 trig_FB_01: short
2014-07-22 22:30:38.615 CUL_HM ccu_Btn1 trigLast: FB_01 :short
das Event in der vccu ccu_Btn1 trig_aes_FB_01: ok:0F
muss also 'ok' sein. Die Nummer ist aus der Message, ohne bedeutung. Stellt sicher, dass es sich bei jeden neuen Event ändert und somit event-on-change-reading dies nicht ausblendet.
Ich muss noch ein bisschen spielen... mit der Nummer
Oioioi, so spät soll man nicht solche Experimente machen. Jetzt habe ich mit Müh und Not die FB wieder zum spielen gebracht (ließ sich nur mit einer der drei ausprobierten Key-Dateien noch reseten) und die HM-Software will mehreren meiner Komponenten (Raumthermostat, PIR) Daten übertragen und schafft es nicht. Wahrscheinlich will sie den doppelten Schlüssel übertragen, was nun nicht mehr geht... . Hoffentlich habe ich mir jetzt nicht einiges zerschossen.
Den Rest probiere ich nach dem Urlaub. Hoffentlich geht mein FHEM noch vernünftig ...
neue schlüssel vergeben ist eine Sache der HM SW.
wie ist die HMId der HM-SW und die von FHEM? Sollte identisch sein.
HM kann wohl nur einen neuen Key setzen, wenn es auch gepairt ist, das device also die korrekte HMId als pair eingetragen hat.
Sorry, ich war ein wenig panisch gestern Abend. Demnächst muss meine Installation besonders zuverlässig funktionieren...
Zunächst mal Danke für die vielen und interessanten Hintergrundinformationen.
Meine Homematic-ID ist dieselbe. In FHEM die Hex-Version derer, die in der HM-Software steht, ich habe das nach dieser Anleitung gemacht: http://www.meintechblog.de/2013/05/hmlan-adapter-am-fhem-server-einrichten/ (http://www.meintechblog.de/2013/05/hmlan-adapter-am-fhem-server-einrichten/).
Gestern Abend hatte ich nun bei meiner Bastelei folgendes Phänomen. Ich habe die Key-Datei der Homematic-Software geändert und diese hat sofort angefangen, das auf meinen ganzen Zoo an HM-Geräten zu verteilen. Das habe ich zunächst gar nicht bemerkt und offensichtlich mittendrin abgebrochen. 3 Versionen hatte ich dabei. Das hier ist die richtige (bei mir gibt es nur den einen Key):
Current Index = 1
Key 0 =
Key 1 = meinKey
Last Index = 0
Zwischendurch hatte ich mal:
Current Index = 1
Key 0 =
Key 1 = meinKey
Key 2 = meinKey
Last Index = 0
und auch mal
Current Index = 2
Key 0 =
Key 1 = meinKey
Key 2 = meinKey
Last Index = 1
probiert. Inzwischen steht wieder die erste drin. Irgendwann wollte ich die FB komplett löschen, das funktionierte aber nicht mehr. Die Software hat nach meinem Sicherheitsschlüssel gefragt, den ich dann eingegeben habe, aber erst nach Versuch 4 oder 5 hat er es dann tatsächlich akzeptiert und die FB gelöscht.
Nun stehen aber im Ausgangskorb der HM-Software immer noch 2 Befehle, die er angeblich wegen Verbindungsproblemen nicht ausgeführt bekommt: Meinem Raumthermostat (der ist gar nicht auf gesicherte Verbindung eingestellt) und meinem HM-PIR (der hingegen schon) möchte er irgendetwas übermitteln und bekommt es nicht hin. Die Geräte funktionieren aber tadellos und ich habe sie gestern auch gar nicht angefasst. Ich denke, er will den Key 2 verteilen, was aber nun nicht mehr geht, weil es ihn gar nicht mehr gibt. Kann man diesen Ausgangskorb irgendwo editieren/löschen oder noch besser dafür sorgen, dass alle Geräte wieder nur meinen einzigen Schlüssel Key1 bekommen?
Hast Du eine Idee, wie ich meine Konfiguration wieder aufräumen kann? Unter FHEM funktioniert zum Glück alles noch.
Ich habe immer gedacht, wenn ich in der HM-Software die Verbindung auf "Gesichert" stelle, dann ist sie das auch. Warum gibt es bei der FB eigentlich dieses Register expectAES?
ZitatMeine Homematic-ID ist dieselbe. In FHEM die Hex-Version derer, die in der HM-Software steht, ich habe das nach dieser Anleitung gemacht: http://www.meintechblog.de/2013/05/hmlan-adapter-am-fhem-server-einrichten/.
du kannst die originale homematicadresse von hmlan und hmusb auch über fhem ermitteln. wenn du
attr <io_name> logIDs syssetzt, erhälst du in fhem.log folgende einträge:
2014.07.23 11:20:32.336 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:18CA838C IDcnt:0007unter d:
1C671E sollte dann die adresse in hex sein.
martin könnte diese adresse eventuell ja auch unter internals neben der seriennummer mit angeben. kann man ab und an mal gebrauchen. ;)
gruss frank
Danke. Die stimmt überein, ist genau die Hex-Version der Zahl, die in der HM-Software-ids Datei steht.
Zitatmartin könnte diese adresse eventuell ja auch unter internals neben der seriennummer mit angeben. kann man ab und an mal gebrauchen.
verstehe ich nicht. Das ist die hmId - die steht doch beim IO.
in dezimal werde ich es nicht ausgeben - wer das brauchen sollte kann es selbst umrechnen
2014.07.23 11:20:32.336 0: HMLAN_Parse: hmlan1 V:03C4 sNo:JEQ0315335 d:1C671E O:1ACE1F t:18CA838C IDcnt:0007
2014.07.23 11:53:53.685 0: HMLAN_Parse: hmusb1 V:03C7 sNo:KEQ1111271 d:263408 O:1ACE1F t:01B2A9D0 IDcnt:0010
bei d: => hier steht die originale device adresse des hmlan (hmusb). diese adresse habe ich noch nie benutzt, nirgendwo eingegeben, oder irgendwo gesehen. weder in fhem noch in winsoftware. diese adresse nutzt die winsoftware zum pairen. die sw teilt diese auch nirgendwo mit. auch kann ich sie dort nicht ändern. man kann sie nur ermitteln, wenn man im dateisystem von windows eine versteckte datei ausgräbt und öffnet, und eine dort hinterlegte dezimalzahl auf hex umrechnet. du müsstest sie nur unter internals beim jeweiligen io anzeigen.
bei o: => hier steht immer die hmid, die ich über das attribut in fhem vergebe.
edit: hier noch mein 2. hmusb den ich für die winsoftware nutze. d: und o: sind gleich.
2014.07.23 21:06:05.684 0: HMLAN_Parse: hmusb1 V:03C7 sNo:JEQ0121054 d:1ACE1F O:1ACE1F t:00024F55 IDcnt:0010
gruss frank
Puuh, jetzt habe ich meine Geräte wieder alle (mehr oder weniger) sauber im System. Es ging nur über brutales Löschen aus der HM-Software und anschließendes Neuanlernen, wobei ich den Systemkey (es gibt nur den einen, auch die HM-Software sagt, dass der nur einmal geändert wurde) bei jedem Gerät eingeben mußte. Also genau der Fall, bei dem man Geräte einschicken muss, wen man den Key nicht kennt.
Nun ist mir Folgendes aufgefallen: Bei allen "gesichert"-Geräten sagt FHEM: AESkeyNbr 02, genau wie bei der Fernbedienung. Auch bei den Aktoren, die eindeutig nur geschaltet werden, wenn ich in FHEM den Key definiere.
Meine andere (12-Tasten-) FB meldet AESkeyNbr FF (Keine Ahnung, warum). Alle (auch der PIR) funktionieren auch, wenn in FHEM mein Key nicht definiert ist, nur die Aktoren nicht. Aber das ist wohl richtig so.
Wozu muss ich dann eigentlich überhaupt in der HM-Software das "gesichert" setzen, bzw. was bewirkt das?
Wie kriege ich den PIR und die andere FB in den AES-Modus? Was macht das Attribut aesCommReq?
Und warum ist das eigentlich so furchtbar kompliziert, wenn man jemals nur den einen code vergeben hat? :D
Ach ja, ich habe noch die 0.961 auf dem HMLAN-Adapter. Momentan will ich das update noch nicht machen, man liest hier so viel. Aber daran wird es wohl nicht liegen.
Hi Frank,
danke - hatte ich noch nciht realisiert.
Ich nehme es zum Anlass, hier etwas aufzuräumen. Da diese Dinge von Device gemeldet werden werde ich sie nach Readings schieben.
2014-07-24 08:33:45 D-HMIdAssigned AFFE01
2014-07-24 08:33:45 D-HMIdOriginal 1743BF
2014-07-24 08:33:45 D-firmware 0.964
2014-07-24 08:33:45 D-serialNr IEQ0244337
@topfi
ZitatMeine andere (12-Tasten-) FB meldet AESkeyNbr FF
FF bedeuted wohl "kein key" - muss ich noch einmal prüfen
ZitatWozu muss ich dann eigentlich überhaupt in der HM-Software das "gesichert" setzen, bzw. was bewirkt das?
das müsste der Schalter sein, der die Kommunikation zwischen Zentralrechner und IO beeinflusst. Also zwischen Computer und HMLAN.
FHEM kann das nicht - wenn HMLAN also "gesichert" haben will wird es nicht funktionieren.
Die Luft-schnittstelle ist davon unbeeinflusst.
ZitatWie kriege ich den PIR und die andere FB in den AES-Modus?
register "sign" definiert, obdas Device eine signatur (AES) fordert
ZitatWas macht das Attribut aesCommReq?
ist quasi sign der Zentrale. Es wird AES von Device gefordert, wenn dies bei der Zentrale Daten abladen will.
ZitatUnd warum ist das eigentlich so furchtbar kompliziert, wenn man jemals nur den einen code vergeben hat?
mit einem Code sollte es nicht kompliziert sein
- vergeben mit HM-SW
- eintragen in FHEM/HMLAN
- setzen der "sign" register
- setzen von aesCommReq
=> schon das Wiki dazu gelesen?
das sign-register kann man nur rücksetzen, wenn man den korrekten key kennt!
Kompliziert ist es nur, wenn man mehrere keys hat. Da habe ich deutlich zu wenig Daten um den Mechanismus zu verstehen.