KFOB-S versus KFOB-C

[jeep]

Hallo zusammen,

bin gerade über diesen Link gestolpert. Und nachdem ich mit meinem KFOB-S nicht sonderlich zufrieden bin (in manchen Forum wurde auch die Reichweite bemängelt) würde ich es gerne mit dem KFOB-C versuchen. Wenn ich dass lese so was in dem Link steht, denke ich das der KFOB-C von Popp die bessere Wahl ist.

KFOB-C-S

Vielleicht hat schon jemand Erfahrungen damit sammeln können.
Danke für Eure Hinweise.

Grüße,
Josef

[A.Harrenberg]

Hi,

hab' keine der beiden, aber anscheinend basieren ja beide auf der gleichen internen Hardware, daher wird sich die Reichweite der beiden Geräte wohl eher nicht unterscheiden...

Gruß,
Andreas.

[krikan]

Da der KFOB-C durch das "Software-Update" im Gegensatz zum KFOB-S Controllerfunktionen hat, ist eine bessere Reichweite durch Nutzung der Routeninfos gut vorstellbar. Der KFOB-C kennt als Controller alle Nachbarschaftsinformationen. Aber: Die Abgleichfunktionen der Routen zwischen Primär-, Sekundärcontroller bzw. SUC müssen mEn durch die Software unterstützt werden und das ist bisher in FHEM nicht der Fall. Wenn wer andere Infos hat, würde mich das freuen.
Gruß, Christian

[jeep]

Hallo zusammen,

gestern habe ich ein neu erhaltenen KFOB-S zurückgeschickt da nach 4,5 Meter freie Sicht nichts mehr zum Controller ankam. Und gleich einen KFOB-C bestellt. Werde dann berichten.

@Andreas, Security war installiert. Wurde der KFOB-S automatisch mit Security inkludiert oder hätte ich was beachten müssen?

Grüße,
Josef

[krikan]

Der KFOB-S wird nur dann mit SECURITY inkludiert, wenn Du das bei der Inklusion mit "set <ZWDongle> addNode on sec" explizit anforderst. Ansonsten wird er normal ohne Nutzung von SECURTITY eingebunden. Bei meinen KFOB-S zumindest...
Gruß, Christian

[A.Harrenberg]

Hi,

die Aussage von Christian ist richtig, es findet keine automatische Inklusion mit Security statt wenn das Gerät Security unterstützt, das muss manuell in die Befehlszeile eingetippt werden und ist nicht aus dem "Menü" heraus machbar.

Das stammt noch aus der Anfangszeit als Security noch nicht wirklich funktioniert hat, vielleicht kann man hier mal wenigstens den Befehl in das Menü einbauen.

Eine völlig automatische Inklusion mit SECURITY würde ich empfehlen, da für SECURITY einfach mehr Nachrichten nötig sind und es daher größere Latenzen gibt. Außerdem ist das ganze noch ein wenig fragil was Fehler angeht. Ich würde daher nur Sicherheitskritische Dinge wie Türschloss oder Alarmanlagen verschlüsseln um weniger Funkverkehr und kürzere Reaktionszeiten zu haben.

Gruß,
Andreas.

[rudolfkoenig]

Eine völlig automatische Inklusion mit SECURITY würde ich empfehlen

Ich gehe davon aus, dass hier ein "nicht" fehlt.

ist nicht aus dem "Menü" heraus machbar.

Habs geaendert. Bisher: "set Dongle addNode on sec", ab jetzt: "set Dongle addNode onSec".
Damit im Dropdown die "on" Optionen nebeneinander stehen, habe ich nwOn in onNw umbenannt. Damit haben wir
set Dongle addNode [on|onNw|onNwSec|onSec|off]

[A.Harrenberg]

Hi Rudi,

ja, da fehlte das "nicht".

Danke für das Einpflegen in das Menü!

Gruß,
Andreas.

[jeep]

Hallo zusammen,

danke schon mal für die Hinweise und die schnelle Aufnahme ins Menü.
Ja wenn man den Satz von Andreas aufmerksam ließt, erkennt man schon dass hier noch ein "nicht" dazugehört. Und natürlich hat er recht, warum noch mehr Latenz um eine Lampe verschlüsselt anzuschalten. Das ist wirklich keine kritische Aktion.

Grüße,
Josef
   

[jeep]

Hallo zusammen,

der KFOB-C kam heute an und ich habe ihn schon inkludiert. Allerdings sah das reading noch spärlich aus, da gibt es noch keinen Eintrag in der openzwave_manufacturer_specific.xml.

Laut GitHub https://github.com/OpenZWave/open-zwave/issues/714 soll er gleich sein wie der KFOB-S, nur eine andere Product-ID "0103"

Code Auswählen Erweitern


<Product type="0100" id="0103" name="ZME_KFOB-C 4 Button Key Fob" config="zwave.me/ZME_KFOB-S.xml" />


Vermute ich richtig dass jemand diesen Eintrag in der "openzwave_manufacturer_specific.xml" hinzufügen  muss?
Besten Dank.

Grüße,
Josef

[krikan]

Vermute ich richtig dass jemand diesen Eintrag in der "openzwave_manufacturer_specific.xml" hinzufügen in der muss?

Hallo Josef,

mache ich gleich. Kommt morgen ab ca. 8 Uhr per update oder Du ziehst es später per Download aus dem svn.

Bevor ich loslege, hätte ich von Dir aber noch gerne das Ergebnis von "get <device> model".

Danke und Gruß, Christian

[jeep]

Hallo Christian,

Danke, Du bist wieder superschnell. Hier der das gewünschte:

Code Auswählen Erweitern

model  0x0154 0x0100 0x0103
Ich werden dann wieder excludieren und morgen nochmals inkludieren.
Besten Dank, ich berichte mehr wenns was zu berichten gibt.

Grüße,
Josef

[krikan]

Dein KFOB-C läuft unter der manufId von Popp.
Ich würde dann mit der XML https://github.com/jeedom/plugin-openzwave/blob/master/ressources/openzwave/config/zwave.me/popp_kfob-c.xml verknüpfen, wenn Du nicht eine andere XML besser findest.
Irgendwie ist das bei Popp und Zwave.me mit den genutzten manufID schwierig zu unterscheiden. ozw/jeedom führt die im Gegensatz zu Deinem unter der manufId 115 von Zwave.me

[jeep]

Hallo Christian,

klar, ich denke es macht dann schon Sinn ihn mit der ../popp_kfob-c.xml zu verknüpfen. Es gibt schon ein paar Unterschiede in der Software zwischen KFOB-S und KFOB-C und ich gehe davon aus dass das so OK sein wird.
Und seit ich das Popp-Handbuch gelesen habe ist mir jetzt auch klar geworden was ich beim KFOB-S nie verstanden habe: nämlich "This mode implements communication pattern 7. (oder 6)
Da heißt es dann im Handbuch:
Communication pattern 7: Remote controls control actuators;
Communication pattern 6: Remote controls cause events in a static controller, which can be used for scene control for example 

Grüße,
Josef

[krikan]

Hallo Josef,
ist eingecheckt und ich bin mal auf Deine Erfahrungen gespannt. Insbesondere über die Auswirkungen der Controllereigenschaft des KFOB-C.
Gruß, Christian