RFID/Keypad mit Zwave in FHEM?

[A.Harrenberg]

Hallo Rudi,

Ich habe eine Version mit USER_CODE eingecheckt, die IDs fuer set/get/report habe ich geraten (da weder in zwapi, noch in openzwave gefunden), muss also nicht perfekt sein.

Wow, das ging schnell... Allerdings wird mir die im Update noch nicht gemeldet. Hab' zwar heute sowieso keine Zeit mehr, aber wie ist da der Rhythmus mit den Updates und wie könnte man vorab an das File kommen? Github?

@Andreas:
- so lowlevel musst du nicht arbeiten, wir sind inzwischen weiter. interessant ist das, was du als CMD:APPLICATION_COMMAND_HANDLER gemeldet bekommst, da musst du den ARG in einer der parse Zeilen
im %zwave_class verarbeiten.
- Pointer auf Doku ist in fhemwiki Artikel (siehe krikans Beitrag) oder du suchst selbst nach SDS11060
- Checksum hat jede ZWave Nachricht, und wird vom Code entfernt bzw. vor dem Senden hinzugefuegt.

Ja, ist mir schon klar das ich den lowlevel für den User_Code nicht brauche, ist mehr Neugier und ich bin ehrlich gesagt erstaunt wie wenig "offen" dieser Standard ist. Die meisten Dokumenten sind offiziell nur für Partner in der Z-Wave Alliance.

Das SDS-Dokument hab' ich mir schon runtergeladen und mir den Teil bei User_Code schon angesehen, ich war nur etwas verwirrt da der ausgelesene Tag-Code nicht mit der Rückmeldung zusammen passte. Ich gehe aber mal davon aus das die Rückmeldung vom RFID-Leser stimmt und das Auslesen des Tags mit dem Handy nicht korrekt war.

Vielen Dank schon mal für das Einbauen der Set/Get, hatte da auch schon mal rudimentär was reingeschrieben, dabei aber irgendwo ein Syntaxfehler reingemacht zu haben, dann ging erst mal gar nichts... ,-)

Gruß,
Andreas.

[A.Harrenberg]

Hi,

Mach in 15 Minuten mal ein update von Fhem und starte Fhem neu. Rudi hat Dir die meiste Arbeit in 10_ZWave.pm schon abgenommen, Du musst nur noch testen, anpassen und berichten.

Update ist drin, allerdings kann ich jetzt erst mal nicht weitertesten, muss leider bis zum WE warten.

Dann werde ich weitertesten und berichten.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi, hallo Krikan,

kurzer Zwischenbericht:
@Rudi, Deine eingebaute User_Code Funktionen funktionieren soweit schon mal, vielen Dank dafür. Ich muss mir aber noch mal anschauen wie das Reading userCode gesetzt wird und wie der "Default" Eintrag in das "set UserCode" kommt.

Ich habe es jetzt geschafft einen RFID-Tag und einen Tastencode zu definieren, der mir dann die entsprechende Rückmeldung "lock" oder "unlock" über die Alarm_Class gibt.
Ich habe es auch geschafft einen definierten Code wieder zu löschen und anschliessend neu anzulegen.

Probleme habe ich mit aktuell damit, das die Rückmeldung über die Alarm_Class nicht ganz "vollständig" ist. Das Keypad nutzt Alarm_Class V2, die ja eigentlich in FHEM unterstützt wird. In der Rohmessage wird noch die UserID mitgeschickt mit der man dann unterscheiden könnte wer "lock" oder "unlock" ausgelöst hat. Ich habe bisher aber keine für mich brauchbare Dokumentation für die V2 gefunden.

Das Topic hier http://forum.fhem.de/index.php?topic=35178.0 habe ich schon gefunden, werde aber aus den Informationen nicht so recht schlau. Das Keypad liefert "vorne" auch 00, sodass der Patch genutzt wird bei dem Alarm_Type/level dann aus dem hinteren Teil der Message genommen wird. Hier muss ich mich noch mal ein wenig mehr mit der Alarm_Class beschäftigen.

Rückmeldung sieht z.B. so aus:

0a 71 05 00 00 00 ff 06 06 01 01

0a ??
71 Alarm_Class
05 Alarm_Command_Report
00 ??
00 ??
00 ??
ff ??
06 Event=Access Control
06 (0x06)Keypad Unlock Operation(Enable) [oder 05 für lock]
01 ?? (scheint immer 01 zu sein)
01 UserId -> ändert sich je nachdem welcher RFID-Tag oder Code genutzt wird.

Soweit also alles schon mal sehr vielversprechend.

Offen ist für mich jetzt erst einmal die "fehlende" UserId in der Rückmeldung der Alarm_Class und eine Art "Userverwaltung" für die einzelnen UserIDs mit den Keys und dem Status (aktiv / inaktiv). Darüber muss ich mal ein wenig nachdenken

Vielen Dank schon mal für eure Hilfe und Unterstützung, mit der Implementierung von Rudi hat man ja wirklich eigentlich schon alles was man braucht.

Gruß,
Andreas.

[krikan]

Hallo Andreas,
habe nur wenig Zeit, darum auch nur ein paar kurze Anmerkungen.

Alarm_Class V2: Ist nur soweit in Fhem-parse implementiert, wie bekannt und bisher notwendig/gefordert gewesen. Für Deine Zwecke muss das ggfs. erweitert werden. Infos zu V2 findest Du https://github.com/cdjackson/openhab/blob/5bd2613739bfa01921b01f7a10324e16208c681f/bundles/binding/org.openhab.binding.zwave/src/main/java/org/openhab/binding/zwave/internal/protocol/commandclass/ZWaveAlarmCommandClass.java und https://github.com/OpenZWave/open-zwave/blob/master/cpp/src/command_classes/Alarm.cpp . Mehr kenne ich leider auch nicht. Für den Tagreader müsste der return-Code in sub
ZWave_alarmParse($$$) anscheind erweitert werden. Das "wie" kann man nur durch Analyse der obigen Codes und der Rohtelegramme herausfinden, wenn wir keine Doku haben.

Hilfreich für Aussenstehende ist, wenn Du mehrere Rohtelegramm (ARG) bzw. Log mit Angabe, was jeweils passiert ist, liefern könntest. Dann kann man eventuell bei der Analyse helfen, wenn Du es selbst nicht lösen kannst.

Bei Deiner gezeigten Rückmeldung ist 0a die ARG-Länge.

Wie ist eigentlich die Haptik und Qualitätsanmutung des Lesers? Ist das Billigstplastik?

Gruß, Christian

[rudolfkoenig]

Ab jetzt werden alle Argumente von ALARMV2 ausgegeben, damit kommt

alarm:AccessControl: Keypad Unlock Operation, arg 0101

und damit kann man die Benutzer unterscheiden.
Das erste 01 steht vermutlich fuer "Slot belegt" (wie in USER_CODE).

[A.Harrenberg]

Hi Krikan,

auch nur kurz...

Den Alarm.cpp code hatte ich auch schon mal gefunden, hat mir aber nicht wirklich weitergeholfen. Da werden dann bei V2 zusätzlich weitere Daten eingelesen ohne das im Code kommentiert wäre wozu die gut sind. Der Stand der verfügbaren Dokumente bzgl. Z-Wave ist wirklich erschreckend gering. Ich dachte wirklich immer das sein ein offener Standard... ;-(

Da ich den Standard nicht kenne kann ich ja auch nicht wissen ob das Keypad das auch alles schön nach Standard macht. Wenn man da jetzt was implementiert/erweitert was evtl. gar kein Standard ist wäre das ja auch ziemlich dumm...

Vielleicht fange ich mal damit an mir anszusehen wie Rudi diese "Ausnahmen" implementiert hat und packe dann erst mal alles in getrennte Funktionen.

Wegen der Logs, ist klar, ist momentan nur etwas umständlich da FHEM auf eine virtuellen Maschine läuft und ich da nur per remote drauf komme, ich kann da nicht so einfach mit copy/paste oder drag/drop arbeiten. Werde mir da noch eine bessere Arbeitsumgebung schaffen müssen.

Ich werde dann mal ein paar Log-Sequenzen vorbereiten und zur Info posten.

Zur Haptik/Anmutung:
Das Gerät ist jedenfalls kein allzuschlimmes Billigplastik. Die Oberfläche ist leicht matt, und das Ding ist doch erstaunlich klein (60x60 mm), hatte beim Kauf gar nicht so drauf geachtet.

So, jetzt noch mal zur Post und einen Bewegungsmelder abholen... (aber Homematic, kein Z-Wave...) und dann mal schauen wie weit ich heute noch komme.

Gruß,
Andreas.

[A.Harrenberg]

Hallo Rudi,

Ab jetzt werden alle Argumente von ALARMV2 ausgegeben, damit kommtund damit kann man die Benutzer unterscheiden.
Das erste 01 steht vermutlich fuer "Slot belegt" (wie in USER_CODE).

oh Mann, Du bist ja wirklich schneller als erlaubt...

Das mit dem User_Code "könnte" sein, zumindest der Reader hier sendet aber nicht mal ein Telegramm wenn ein falscher Coder oder ein nicht angelerntes Tag davorgehalten wird. Den eventuell besonderen Fall das ein bekannter Code deaktiviert wurde und damit versucht wird zu entsperren müsste ich explizit noch einmal probieren. Mir fällt aber gerade ein das der <User ID Status> auch 0x02 für "Reserved by administrator" sein kann.

Vielen Dank,
Andreas.

[A.Harrenberg]

Hi,
hier mal ein paar Logs zur Info:

Home gedrückt, dann Tag #1 davorgehalten
2015.05.09 15:28:08 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e630300008fa4d1542a0001040000    
Away gedrückt, dann Tag #1 davorgehalten
2015.05.09 15:29:37 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e630300008fa4d1542a0001040000

-> bei unbekannten Tags oder Codes wird nur der Tag bzw. Code übertragen, keine weitere Info über die Taste, UserCode ist immer 0, User ID Status ist immer 0. Code wird immer 10-stellig übertragen (hinten mit 00 aufgefüllt).

Home, Code 1234, Enter
2015.05.09 15:32:25 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e6303000031323334000000000000
-> Tasten werden als ASCII-Code übertragen

VERMUTUNG: Tags wird ein 8f vorangestellt (Mit Handy ausgelesene Tags haben kein vorangestelltes 8f) um im Zweifelsfall Tag und Code zu unterscheiden.

Zipato_EC ist mein Devicename (Zipato_EntryControl)
Anlernen Tag #1: set Zipato_EC userCode 1 1 8fa4d1542a0001040000
2015.05.09 15:37:56 4: Sending stored command: 13080e630101018fa4d1542a00010400000508

Auslesen UserID 1: get Zipato_EC userCode 1
2015.05.09 15:39:40 4: Sending stored command: 1308036302010508
2015.05.09 15:39:40 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e630301018fa4d1542a0001040000
-> 6303 = Command_Class & Report
-> 0101 = UserID 1, User_ID_Status = Occupied

Auslesen UserID 2: get Zipato_EC userCode 2
2015.05.09 15:42:37 4: Sending stored command: 1308036302020508
2015.05.09 15:42:37 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e6303020031323334000000000000
-> 6303 0200 = UserID 2, User_ID_Status=Available

Tastencode 1234 auf UserID 2 anlernen: set Zipato_EC userCode 2 1 31323334000000000000
2015.05.09 15:46:12 4: Sending stored command: 13080e63010201313233340000000000000508

Auslesen UserID 2: get Zipato_EC userCode 2
2015.05.09 15:46:54 4: Sending stored command: 1308036302020508
2015.05.09 15:46:54 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e6303020131323334000000000000
-> 6303 0201 = UserID 2, User_ID_Status=Occupied

Tamper alarm ausgelöst:
2015.05.09 15:48:29 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:09710500ff00ff070300

Home + Tag #1:
2015.05.09 15:49:02 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0a7105000000ff06060101
-> 0606 = Access Control & Unlock
-> 0101 = UserID-State??, UserID=1

Away + Tag #1:
2015.05.09 15:50:55 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0a710500ff00ff06050101
-> 0605 = Access Control & Lock

Home + 1234 + Enter:
2015.05.09 15:51:49 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0a7105000000ff06060102
-> 0102 = UserID-State??, UserID=2

Laut einem WIki-Eintrag bei Zipato http://wiki.zipato.com/wiki/Mini_Keypad_RFID/Z-Wave kann der Reader nur 10 Einträge speichern. Die ID ist jedoch anscheinen NICHT auf Zahlen <10 begrenzt:

Tag #2:
015.05.09 15:54:37 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e630300008fe37e542a0001040000

Anlernen auf ID 12: set Zipato_EC userCode 12 1 8fa4d1542a0001040000
Edit_2: Hier habe ich die Tag-Codes verwechselt und versehentlich den Tag-Code #1 angegeben, daher funktionierte das nicht...
2015.05.09 15:55:46 4: Sending stored command: 13080e63010c018fa4d1542a00010400000508

Auslesen ID 12: get Zipato_EC userCode 12
2015.05.09 15:57:32 4: Sending stored command: 13080363020c0508
2015.05.09 15:57:32 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e63030c018fa4d1542a0001040000
-> 0c01 UserID=12

Hier gibt es allerdings eine Perl Warnung:
2015.05.09 15:57:32 1: PERL WARNING: Argument "0c" isn't numeric in sprintf at (eval 135) line 1.

Nachtrag/Edit: Bei Auslesen wird einem zwar die UserID 12 als occupied gemeldet, der Tag funktioniert danach jedoch NICHT. Es scheint also doch eine Begrenzung zu geben. Das "höhere" IDs akzeptiert werden und dann nicht funktionieren ist allerdings etwas unschön von dem Gerät...

Edit_2: Da ich wie oben geschrieben den Tag-Code verwechselt hatte funktionierte dies nicht. Ich habe das gerade noch einmal gemacht. Tag #2 auf ID=12 angelernt und es funktioniert!

So, das müssten jetzt mal die wichtigsten Logs sein. Ich werden noch mal probieren mehr als 10 tastencodes zu definieren und schauen ob dann doch bei 10 aktiven codes mal ein Fehler gemeldet wird.

Die Tatsache das es ein Batteriegerät mit Wake-Up ist, macht das rumspielen nicht unbedingt einfacher, aktuell habe ich das Ding auf dem Tisch legen und hebe es kurz hoch damit der Tamper-Alarm generiert wird. Dadruch werden dann auch die Befehle abgearbeitet. Alternativ hatte ich auch das Wakeup-Interval auch schon mal auf 5 sekunden gesetzt, das müllt mir dann aber alle 5 sek. das Log zu...

Man kann das Device zum Konfigurieren auch in einen "always on" mode versetzen, davon bekommt FHEM aber nichts mit und wirft die Befehle trotzdem in die Warteschlagen bis zur Wake-Up-Notification.

Gruß,
Andreas.

P.S: Noch ein Wort zu den Tags, die ganz einfachen "EM4102/4200" funktionieren hier anscheinend NICHT. Der beiligende bzw. original dazu bestellte Zipato meldet sich mit Type: ISO 15693.

[krikan]

Man kann das Device zum Konfigurieren auch in einen "always on" mode versetzen, davon bekommt FHEM aber nichts mit und wirft die Befehle trotzdem in die Warteschlagen bis zur Wake-Up-Notification.

Lösche mal in attr classes WAKE_UP, dann landet das nicht in der Warteschlange, sondern wird direkt verschickt. Nicht vergessen nach Ausschalten von "allways on" WAKE_UP wieder in classses aufzunehmen.

[A.Harrenberg]

Hi Krikan,
#

Lösche mal in attr classes WAKE_UP, dann landet das nicht in der Warteschlange, sondern wird direkt verschickt. Nicht vergessen nach Ausschalten von "allways on" WAKE_UP wieder in classses aufzunehmen.

Danke für den Tipp, hatte mir schon vorgenommen rauszusuchen ob das so einfach funktioniert, und ja, es funktioniert so einfach... ,-)

Allerdings kann man diesen Modus "always on" (configTheMode) nur zum Konfigurieren und Auslesen nutzen. In dem Modus akzeptiert der Reader keine Tags oder Tasten-codes.

Gruß,
Andreas.

[krikan]

Hallo Andreas,
wenn ich Deine Angaben so durchsehe, scheinst Du Dich doch prima eingearbeitet zu haben. Funktioniert anscheinend auch schon sehr gut. Sehe momentan nicht, wo Du noch konkret Hilfe brauchst!?

VERMUTUNG: Tags wird ein 8f vorangestellt

Sehe ich auch so. Im BeNext Handbuch ist das im Beispiel auch so hinterlegt.

Bei Auslesen wird einem zwar die UserID 12 als occupied gemeldet, der Tag funktioniert danach jedoch NICHT. Es scheint also doch eine Begrenzung zu geben. Das "höhere" IDs akzeptiert werden und dann nicht funktionieren ist allerdings etwas unschön von dem Gerät...

Das muss im Fazit durch die Software sichergestellt werden, wenn ich das zwapi-PDF richtig interpretiere. (über "Users Number Report Command"). Anlasten würde ich es dem Tagreader jetzt nicht.

Gruß, Christian

PS:
Rudi sieht Deine "Edits" normalerweise nicht. Also besser neue Antwort anlegen.

[A.Harrenberg]

Hallo Krikan,

Hallo Andreas,
wenn ich Deine Angaben so durchsehe, scheinst Du Dich doch prima eingearbeitet zu haben. Funktioniert anscheinend auch schon sehr gut. Sehe momentan nicht, wo Du noch konkret Hilfe brauchst!?

dank der Implementation von Rudi läuft ja schon alles wie gewünscht, musste ja nichts machen ausser ausprobieren. Aktuell brauche ich daher erst mal keine Hilfe, die Logs hatte ich ja auch mit "zur Info" gepostet.

Tja, "Edits"... Ich hatte natürlich in der Zwischenzeit einen weiteren Edit gemacht. Eine ID oberhalb von 10 funktioniert auf jeden Fall schon mal. Habe vorhin mal mit einer Schleife alle 255 (0 geht ja nicht) möglichen IDs als inaktiv aber mit fortlaufenden Nummer beschrieben und wieder ausgelesen. Der Reader hat auf jeden Fall Speicherplatz für 255 IDs mit den Codes. Ich muss jetzt mal Tastencodes anlegen und sehen ob es da eine Grenze für aktive Codes gibt, kann ich mir jetzt aber fast nicht vorstellen wenn da schon Platz für 255 codes ist.

Muss jetzt nur mal überlegen wie ich am geschicktesten Tasten-Codes erzeuge damit ich die nicht per Hand da reinschreiben muss. Kleine Denksportaufgabe am Abend...

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

kleiner Nachtrag, der Reader kann mindestens 32 codes, mehr habe ich jetzt nicht durchprobieren wollen...

Gruß,
Andreas.

[A.Harrenberg]

Hallo,

da der Reader jetzt eigentlich schon komplett unterstützt wird habe ich mal einen Wiki-Eintrag für den Reader erstellt: http://www.fhemwiki.de/wiki/Z-Wave-ZIP_WT-RFID_Keypad.

Der Hinweis auf den Wiki-Eintrag habe ich auch im ersten Beitrag der Diskussion als Edit hinzugefügt.

Danke noch mal an Rudi und Krikan,
Andreas.

[ChrisW]

Kann ich hier auch ein Handy mit NFC dranhalten ?
Hat das Gerät jemand im Außeneinsatz ?