Abus HomeTec Pro CFA3010 Türschloss - Probleme bei der Inklusion

Begonnen von Ansgar Höber, 21 September 2020, 22:06:23

Vorheriges Thema - Nächstes Thema

Ansgar Höber

Hallo in's Forum,

ich habe mir ein "ABUS HomeTec CFA3010" ZWave-Türschloss gekauft und möchte es in FHEM inkludieren und ansteuern.
Dazu habe ich nach Bedienhandbuch die Sicherheit von der Standardeinstellung "S2" in "S0" geändert und dann mit dem Befehl

set ZWave_USB_Dongle addNode on

meinen ZWave-Controller ("Cyrus SmartHome USB Dongle") in den Inklusionsmodus. Dann setze ich das ABUS-Türschloss in den Inklusionsmodus und die Inklusion wird erfolgreich durchgeführt (siehe Bild "Türschloss_angelernt.jpg"). Es werden ein Device und ein FileLog erzeugt ("Übersicht_erzeugte_ZWave_Geräte.jpg").
Allerdings scheint die Inkusion fehlerhaft zuu sein, denn wenn man sich die "DeviceOverview" anschaut ("Türschloss_Übersicht_1.jpg" und "Türschloss_Übersicht_2.jpg") anschaut, gibt es im Vergleich zu den Herstellerinformationen zu wenige Klassen und Readings.
Und man kann auch nur sehr "übersichtliche" SET- und GET-Befehle ("Türschloss_Übersicht_set.jpg" und "Türschloss_Übersicht_get.jpg"), vor allem kann man das Schloss nicht über

set ZWave_ENTRY_CONTROL_17 on

oder

set ZWave_ENTRY_CONTROL_17 off

steuern oder konfigurieren. Auch kann ich keine Informationen wie Hersteller oder Modell abrufem, denn wie abgebildet fehlt auch der Befehl

get ZWave_ENTRY_CONTROL_17 model

Kann mir jemand helfen und mir sagen, wie ich mein "ABUS HomeTec CFA3010" ZWave-Türschloss korrekt einbinden kann?

Zu meiner FHEM-Umgebung:
Ich betreibe FHEM in der Version 6 auf einem RaspberryPi 4 mit 8 GByte RAM, einem EnOcean- und einem ZWave-USB-Dongle.
FHEM-Version: 6.0
FHEM-Server: RaspBerryPi 4, 8 GByte RAM
FHEM-Server-Betriebssystem: Raspbian Buster (32 Bit)
Hausautomationssysteme: EnOcean, ZWave, Netatmo; Philips Hue
Kommunikationsmodul: EnOcean USB-Dongle (USB 300 EnOcean Gateway), ZWave USB-Dongle (Z-Wave.Me UZB Smart Home Stick)

rudolfkoenig

Zitatgibt es im Vergleich zu den Herstellerinformationen zu wenige Klassen und Readings.
Vermutlich ist der Hersteller der Ansicht, Tuer aufmachen soll nur bei verschluesselten Verbindung funktionieren.

ZitatKann mir jemand helfen und mir sagen, wie ich mein "ABUS HomeTec CFA3010" ZWave-Türschloss korrekt einbinden kann?
Da laut Bild neben SECURITY_S2 auch SECURITY verfuegbar ist, wuerde ich versuchen, bei der Inklusion onSec/onNwSec verwenden, und in der Geraete-Doku feststellen wie man am Geraet Inklusion per SECURITY (nicht _S2) aktiviert.

ZitatIch betreibe FHEM in der Version 6 ...
Das sagt wenig, bitte in FHEM update ausfuehren.
Und wenn moeglich, statt screenshots lieber den Text kopieren, das kann man einfacher durchsuchen, oder kopieren, wenn man was nachstellen will.

Ansgar Höber

Hallo Herr König,

ich habe das Schloss ja schon unter OpenHAB betrieben und da waren alle Parameter, die im Handbuch beschrieben werden, auch änderbar. Und da es bei OpenHAB auch keine S2-Verschlüsselung gegeben hat, musste ich auf den S0-Modus umstellen, bevor ich das Türschloss überhaupt inkludieren konnte. Da auch keine sichere Inklusion angeboten wurde, gehe ich davon aus, dass es eine normale Inklusion war - genau wie der "set ZWave_USB_Dongle addNode on" Befehl.
Den Befehl "set ZWave_USB_Dongle addNode onSec" habe ich auch ausprobiert, aber danach hatte ich noch eine "SET"-Option weniger.
Was mich halt wundert (und Sie vermutet haben) ist, dass man die Schliessfunktionen (siehe die Klassen unten, die ich aus dem Handbuch kopiert habe) nur über den S2-Modus nutzen kann, ich aber definitiv zur Inklusion in den S0-Modus wechseln musste und zumindest unter OpenHAB das Türschloss bedienen konnte. Und selbst wenn ich die S2-Funktionen nicht nutzen kann, müssten doch mindestens die anderen in der DeviceOverview sowohl für die "SET"- und "GET"-Befehle nutzbar sein:

• Basic (nur S2 Zugang)
• Door Lock (nur S2 Zugang)
• Transport Service
• Association Grp Info
• Device Reset Locally
• Zwaveplus Info
• Supervision
• Configuration (nur S2 Zugang)
• Manufacturer Specific
• Powerlevel
• Firmware Update Md  (nur S2 Zugang)
• Battery
• Association
• Version
• Multi Channel Association
• Security
• Security 2

Ich habe den Eindruck, dass bei der Inklusion das falsche oder gar kein xml ausgewählt wird - warum auch immer. Kann man das manuell zuweisen?
Ich bin da echt ratlos, aber da schon in einem anderen Thread erwähnt wurde, dass die Inklusion funktioniert hat und das Schloss auch bedient werden kann, hoffe ich, dass es eine allgemeingültige Lösung gibt.
Und nächstes Mal werde ich versuchen, den Text aus den Fenstern zu kopieren, was bei Aufklappmenüs aber bestimmt schwierig sein dürfte...
FHEM-Version: 6.0
FHEM-Server: RaspBerryPi 4, 8 GByte RAM
FHEM-Server-Betriebssystem: Raspbian Buster (32 Bit)
Hausautomationssysteme: EnOcean, ZWave, Netatmo; Philips Hue
Kommunikationsmodul: EnOcean USB-Dongle (USB 300 EnOcean Gateway), ZWave USB-Dongle (Z-Wave.Me UZB Smart Home Stick)

rudolfkoenig

Das XML ersetzt nur den Beipackzettel, damit man bei den config* Befehlen eine Hilfe kriegt, und nettere config-Befehlsnamen. Mehr nicht.

Mit addNode on/onNw kriegt man _keine_ sichere Verbindung hin (kein SECURITY, aka S0), dafuer muss man onSec/onNwSec verwenden. Evtl. fehlen dafuer in FHEM die perl-Crypto-Bibliotheken (Crypt::Rijndael), das steht aber in den Readings bzw. im FHEM-Log.

Ich empfehle das Geraet mit removeNode zu entfernen, und es danach mit onSec/onNwSec erneut zu inkludieren.
Den Status kann man an dem SECURITY Reading ablesen.

Ansgar Höber

Hallo Herr König,
Ihr Hinweis auf die Rijndael-Crypt-Bibliothek hat zumindest etwas geholfen  :) Ich kann jetzt die Parameter des Türschlosses setzen und auslesen.
Aber ein Problem habe ich noch:
Ich kann das Schloss nicht über FHEM nicht öffnen oder schließen - es gibt keinen "set ZWave_Tuerschloss_1 on" oder "set ZWave_Tuerschloss_1 off" Befehl.
(Das gleiche Problem habe ich auch mit dem "FIBARO System FGBS222 Smart Implant": Konfigurieren funktioniert, Steuern nicht. Auch dieses Gerät habe ich sicher inkludiert)
FHEM-Version: 6.0
FHEM-Server: RaspBerryPi 4, 8 GByte RAM
FHEM-Server-Betriebssystem: Raspbian Buster (32 Bit)
Hausautomationssysteme: EnOcean, ZWave, Netatmo; Philips Hue
Kommunikationsmodul: EnOcean USB-Dongle (USB 300 EnOcean Gateway), ZWave USB-Dongle (Z-Wave.Me UZB Smart Home Stick)

curt

Hallo Ansgar,

Dieses AssociationAdd hattest Du gemacht? Dann klick mal bitte auf https://wiki.fhem.de/wiki/Z-Wave#Welche_Infos_sollten_Anfragen_im_ZWave-Forum_enthalten.3F

Führe mal bitte die dort stehenden Befehle

    get <device> associationAll
    get <device> configAll
    get <device> versionClassAll
    get <device> mcaAll
    get <device> wakeupInterval (nur bei batteriebetriebenen Geräten)

aus - oder hattest Du das schon gemacht?

@rudolfkoenig
Das ist möglicherweise die gleiche Baustelle wie mit dem Thermostat Spirit ... also aus meiner Sicht tappelt jeder einzeln mit einer neuen ZWave-Device durch die Landschaft und wundert sich, das alles mögliche fehlt. Und wirft das Gerät wegen "geht nicht" weg.
RPI 4 - Jeelink HomeMatic Z-Wave

Ansgar Höber

Hallo "curt",

vielen Dank für den Link :)
Ich habe versucht, die Befehle umzusetzen, die Du aufgeführt hast. Aber ich bekomme keine Ergebnisse bei den Befehlen:

get ZWave_Tuerschloss_1 associationAll
get ZWave_Tuerschloss_1 configAll
get ZWave_Tuerschloss_1 mcaAll


Nachdem ich die Befehle eingegeben habe, bekomme ich ein Hinweisfenster mit der Meldung "working in the background" und es passiert nichts weiter. Ähnliches passiert bei Eingabe des Befehls

get ZWave_Tuerschloss_1 versionClassAll

Nur erhalte ich hier ein Hinweisfenster mit der Meldung "working in the background, check the vclasses attribute" und es passiert auch nichts weiter.
Die Hinweisfenster habe ich dann jeweils nach knapp fünf Minuten weggeklickt.
Ein Wakeup-Intervall kann ich nicht abfragen, obwohl es sich um ein batteriebetriebenes Gerät handelt...

FHEM-Version: 6.0
FHEM-Server: RaspBerryPi 4, 8 GByte RAM
FHEM-Server-Betriebssystem: Raspbian Buster (32 Bit)
Hausautomationssysteme: EnOcean, ZWave, Netatmo; Philips Hue
Kommunikationsmodul: EnOcean USB-Dongle (USB 300 EnOcean Gateway), ZWave USB-Dongle (Z-Wave.Me UZB Smart Home Stick)

rudolfkoenig

Bei batteriebetriebenen Geraeten kann man ueblicherweise einen Knopf druecken, um sie ausserplanmaessig zu wecken. Damit muss man nicht auf das konfigurierte Wakeup warten, und man kann die ausstehenden Befehle zeitnah abarbeiten.

Ansgar Höber

Hallo Herr König,

da ich die einzelnen Parameter über die Befehle

set ZWave_Tuerschloss_1 configXXXX <Wert>
get ZWave_Tuerschloss_1 configXXXX


setzen und abfragen kann, gehe ich davon aus, dass das Schloss "wach" ist. Und, wie erwähnt, gibt es den Parameter "wakeupIntervall" nicht.
FHEM-Version: 6.0
FHEM-Server: RaspBerryPi 4, 8 GByte RAM
FHEM-Server-Betriebssystem: Raspbian Buster (32 Bit)
Hausautomationssysteme: EnOcean, ZWave, Netatmo; Philips Hue
Kommunikationsmodul: EnOcean USB-Dongle (USB 300 EnOcean Gateway), ZWave USB-Dongle (Z-Wave.Me UZB Smart Home Stick)

rudolfkoenig

Dann ist das vmtl. ein FLiRS Geraet: kann per Funk geweckt werden.

Ansgar Höber

Vermutlich...
Und wenn das so ist, warum führen dann die Befehle

get ZWave_Tuerschloss_1 associationAll
get ZWave_Tuerschloss_1 configAll
get ZWave_Tuerschloss_1 mcaAll
get ZWave_Tuerschloss_1 versionClassAll


zu keinem Ergebnis, sondern zu den Meldungen "working in the background"/"working in the background, check the vclasses attribute"?
Ich will nur die Befehle ausführen, um "curt"s Vorschlag umzusetzen und gegebenenfalls aus den erhaltenen Informationen eine Problemlösung zu bekommen.
FHEM-Version: 6.0
FHEM-Server: RaspBerryPi 4, 8 GByte RAM
FHEM-Server-Betriebssystem: Raspbian Buster (32 Bit)
Hausautomationssysteme: EnOcean, ZWave, Netatmo; Philips Hue
Kommunikationsmodul: EnOcean USB-Dongle (USB 300 EnOcean Gateway), ZWave USB-Dongle (Z-Wave.Me UZB Smart Home Stick)

rudolfkoenig

Weil diese Befehle jeweils eine Liste von Einzelbefehlen absetzen, und auf deren Antwort zu warten wuerde FHEM zu lange blockieren.

Es gibt inzwischen ein Framework, um solche Ergebnisse asynchron zu sammeln, es zu verwenden ist aber  aufwendiger, und lange nach dem Implementieren dieser Befehle entstanden, d.h. man muesste diese umbauen.

Ansgar Höber

Ok. Dann werde ich die Befehle noch einmal absetzen und auf das Ergebnis warten  :)
FHEM-Version: 6.0
FHEM-Server: RaspBerryPi 4, 8 GByte RAM
FHEM-Server-Betriebssystem: Raspbian Buster (32 Bit)
Hausautomationssysteme: EnOcean, ZWave, Netatmo; Philips Hue
Kommunikationsmodul: EnOcean USB-Dongle (USB 300 EnOcean Gateway), ZWave USB-Dongle (Z-Wave.Me UZB Smart Home Stick)

Ansgar Höber

Hallo Herr König,

einen Fehler habe ich gefunden :) Und der lag zwischen den Ohren. Denn ich hatte erwartet, dass ich ein Fenster angezeigt bekomme, wenn der Befehl ein Ergebnis produziert. Ich habe natürlich nicht daran gedacht, dass ich auch im Log nachschauen kann, wo die Ergebnisse auch drinstehen sollten.
Die Befehle

get ZWave_Tuerschloss_1 associationAll
get ZWave_Tuerschloss_1 configAll
get ZWave_Tuerschloss_1 mcaAll


lieferten folgende Ergebnisse:

2020-09-23_19:47:29 ZWave_Tuerschloss_1 assocGroups: 1
2020-09-23_19:47:29 ZWave_Tuerschloss_1 assocGroup_1: Max 5 Nodes ZWave_USB_Dongle
2020-09-23_19:48:30 ZWave_Tuerschloss_1 configABUSFirmwareVersion: 273
2020-09-23_19:48:31 ZWave_Tuerschloss_1 configAcousticFeedback: Locked
2020-09-23_19:48:31 ZWave_Tuerschloss_1 configLatchHoldTime: 2
2020-09-23_19:48:31 ZWave_Tuerschloss_1 configLatchTorque: Max
2020-09-23_19:48:31 ZWave_Tuerschloss_1 configLockStatus: Unlocked
2020-09-23_19:48:32 ZWave_Tuerschloss_1 configMotorForce: Automatic
2020-09-23_19:48:32 ZWave_Tuerschloss_1 configTouchPanel: Active
2020-09-23_19:48:32 ZWave_Tuerschloss_1 configTravelCyclesLatch: 219
2020-09-23_19:48:32 ZWave_Tuerschloss_1 configTravelCyclesLocked: 295
2020-09-23_19:48:33 ZWave_Tuerschloss_1 configTravelCyclesUnlocked: 251
2020-09-23_19:48:33 ZWave_Tuerschloss_1 configTravelTime: Multiple
2020-09-23_19:50:49 ZWave_Tuerschloss_1 mcaGroups: 1
2020-09-23_19:50:49 ZWave_Tuerschloss_1 mca_1: Max 5 Nodes ZWave_USB_Dongle


Der Befehl

get ZWave_Tuerschloss_1 versionClassAll

liefert aber keine Informationen zu den Versionen der Klassen. Aber das Attribut "vclasses" besitzt folgende Einträge:

ALARM:8
ASSOCIATION:2
ASSOCIATION_GRP_INFO:1
BATTERY:1
CONFIGURATION:1
DEVICE_RESET_LOCALLY:1
DOOR_LOCK:2
FIRMWARE_UPDATE_MD:4
MANUFACTURER_SPECIFIC:2
MULTI_CHANNEL_ASSOCIATION:3
POWERLEVEL:1
SECURITY:1
SECURITY_S2:1
SUPERVISION:1
TRANSPORT_SERVICE:2
VERSION:3
ZWAVEPLUS_INFO:2


Kann man da einen Hinweis finden, warum ich das Schloss nicht öffnen oder schließen kann?
FHEM-Version: 6.0
FHEM-Server: RaspBerryPi 4, 8 GByte RAM
FHEM-Server-Betriebssystem: Raspbian Buster (32 Bit)
Hausautomationssysteme: EnOcean, ZWave, Netatmo; Philips Hue
Kommunikationsmodul: EnOcean USB-Dongle (USB 300 EnOcean Gateway), ZWave USB-Dongle (Z-Wave.Me UZB Smart Home Stick)

rudolfkoenig

Da DOOR_LOCK in vclasses auftaucht, wird es auch in classes auftauchen, und damit ist in FHEM "set doorLockOperation close" verfuegbar. Wenn das nicht funktioniert, dann ist evtl. der Eintrag in der Liste von vorhin: "Door Lock (nur S2 Zugang)" ernstzunehmen.

Allerdings wuerde ich den Hersteller fragen, wieso diese Klassen dann unter "S0" ueberhaupt angeboten werden.