Hallo,
Ich habe es, wie in Folgenden Thread beschrieben, geschafft das HomeMatic Protokoll mit einer anderen Hardware als dem CUL zum laufen zu bekommen.
http://forum.fhem.de/index.php/topic,49300.0.html
Dafür nutze ich das Modul CUL_HM. Leider ist in diesem Modul fest ein Bezug auf die CUL Hardware in Form einer TYPE Abfrage integriert.
Daher die Frage ob eine zusätzliche Attributeabfrage eingebaut werden kann, welches es erlaubt auch andere Hardware mit diesem Modul zu nutzen.
Das könnte evtl. so aussehen:
if ($hash->{IODev}->{TYPE} eq "CUL" || AttrVal($hash->{IODev},"simCULHW",0) == 1)
Grüße,
Ulli
erkläre:
CUL_HM fragt das IO nur ab, wenn es um AES geht. Du solltest also alles betreiben können - nur nicht AES. Ist das korrekt?
kannst du AES?
ist das Timing entsprechend der alternative FW realisiert der wird es die üblichen Probleme geben?
Zitat von: martinp876 am 14 Februar 2016, 20:03:48
erkläre:
CUL_HM fragt das IO nur ab, wenn es um AES geht. Du solltest also alles betreiben können - nur nicht AES. Ist das korrekt?
Das ist korrekt. Da ich aber die Komponenten, sprich in meinem Fall aktuell Fensterkontakte, pairen muss und dafür eine AES Signierung notwendig ist benötige ich die AES Unterstützung aus dem CUL_HM.
Zitat von: martinp876 am 14 Februar 2016, 20:03:48
kannst du AES?
ist das Timing entsprechend der alternative FW realisiert der wird es die üblichen Probleme geben?
Ich bin mir nicht sicher was du meinst. Ich habe die 0.1ms delay aus dem CUL Modul auch bei mir integriert. Komischerweise bekomme ich aber die Fensterkontakte mit und ohne dieses delay zu pairen. Oder was meintest du?
ZitatKomischerweise bekomme ich aber die Fensterkontakte mit und ohne dieses delay zu pairen.
ja logisch. Ein Event ist eine message. da braucht es kein delay, die empfängst du einfach.
warum brauchst du AES zum pairen? Das ist per Default aus, also sollte es kein Problem sein.
generell willst du aber AES nutzen - da brauchst du die Funktion.
Warum nutzen wir nicht ein gemeinsames Attribut - z.B. "rfmode=homematic"
dann ist es bei CUL und dir identisch.
Ich bin da flexibel, bei mir heißt es zwar "setReceiverMode" aber zur Not ergänze ich noch ein Reading. Rssi wäre auch ein mögliches Reading
Was meintest du denn dann genau mit dem Timing?
Zitat von: martinp876 am 16 Februar 2016, 20:16:22
warum brauchst du AES zum pairen? Das ist per Default aus, also sollte es kein Problem sein.
Nicht beim verwendeten HM-SEC-SCo, da ist es per Default an.
Zitat von: martinp876 am 16 Februar 2016, 20:16:22
ja logisch. Ein Event ist eine message. da braucht es kein delay, die empfängst du einfach.
warum brauchst du AES zum pairen? Das ist per Default aus, also sollte es kein Problem sein.
generell willst du aber AES nutzen - da brauchst du die Funktion.
Warum nutzen wir nicht ein gemeinsames Attribut - z.B. "rfmode=homematic"
dann ist es bei CUL und dir identisch.
Wie sollen wir es nun machen?