RFID/Keypad mit Zwave in FHEM?

[A.Harrenberg]

Hallo,

ich suche nach einer Möglichkeit ein RFID/Keypad in FHEM einzubinden. Das einzige was ich bisher als "Fertiglösung" gefunden habe ist das hier:

http://www.benext.eu/en/products/tag-reader/, gibt es wohl auch (baugleich?) noch von Zipato (http://control-your-home.de/zipato-rfid-keypad). Nun hat das Ding Zwave, meine bisherigen Komponenten sind alle Homematic, daher kenne ich mich mit ZWave erst mal gar nicht aus...

In der Forum oder im Wiki habe ich bisher nichts zu dem Teil finden können. Im Forum von Symcon (https://www.symcon.de/forum/threads/25266-zipato-MINI-KEYPAD-Modulklasse-63-wird-nicht-unterstuetzt/page2) haben einige da zumindest schon mal die rudimentären Funktionen realisieren können.

Besteht eine berechtigte Hoffnung das der RFID Leser auch unter FHEM in Betrieb genommen werden kann?

Gruß,
Andreas.

EDIT:
Der RFID Reader wird mittlerweile unterstützt, ein entsprechender Wiki-Eintrag existiert nun auch: http://www.fhemwiki.de/wiki/Z-Wave-ZIP_WT-RFID_Keypad

[krikan]

Der RFID-Leser wird derzeit nicht ohne Code-Anpassungen mit Fhem funktionieren; aber Hoffnung gibt es immer.

Die Class USER CODE (63) ist in Fhem (noch) nicht integiert. Die Doku zu dieser Class ist aber zu finden und könnte implementiert werden. Sieht auf den ersten Blick auch nicht so kompliziert aus. Alle anderen geforderten Classes kann Fhem soweit ich sehe jetzt schon. Ob es Besonderheiten und Anpassungsbedarf bei den vorhandenen Classes für den Leser gibt, ist ohne Testgerät für mich schwer festzustellen. Das Handbuch des Lesers ist jedoch erfreulich ausführlich.

Was mich aber verwundert ist, dass der Leser nicht die Class SECURITY nutzt. Wenn Du den Leser im sicherheitskritischen Bereich einsetzen willst, würde ich mir das genau überlegen.

[A.Harrenberg]

Hallo Krikan,

vielen Dank schon mal für die doch recht positiv klingende Rückmeldung.

Was heisst denn "...könnte implementiert werden." und "Sieht ... nicht so kompliziert aus"?

Ich möchte jetzt ja nicht unbedingt jemanden dazu bringen das (nur) für mich zu implementieren, allerdings kann ich das zumindest momentan nicht selbst/alleine. Programmierkenntnisse (vorwiegend in C) sind zwar vorhanden, mit perl und fhem habe ich zwar auch schon erste eigene kleine Funktionen geschrieben, aber ein Modul habe ich bisher noch nicht erzeugt. Und wie gesagt ist Zwave völliges Neuland für mich.

Wie "tief" steckst Du denn in den Zwave Sachen drin?

Ob es Besonderheiten und Anpassungsbedarf bei den vorhandenen Classes für den Leser gibt, ist ohne Testgerät für mich schwer festzustellen.

Das hört sich für mich so an als ob Du da schon häufiger mit zu tun hattest.

Momentan würde ich dazu tendieren mir das Ding einfach mal zu bestellen, anzufangen und auf Hilfestellungen im Forum zu vertrauen. Zur Not kann ich ja ein Testgerät zur Verfügung stellen...

Ich würde wahrscheinlich den Zipato bestellen, der ist billiger und schneller erhältlich, ich hoffe mal das die Firmware sich da nicht unterscheiden wird, was denkst Du?

Allerdings ist da noch das Thema Sicherheit das Du aufgebracht hast. Wo ist denn der Unterschied zwischen Class Security und den anderen Klassen? Ist das verschlüsselt? Ich will damit nicht meine Haustüre öffnen, sondern INNEN die Alarmanlage unscharf schalten. Momentan habe ich dafür einen 6-fach Homematic Taster mit Code-Eingabe vorgesehen, da ist die Übertragung soweit ich weiss auch nicht verschlüsselt. So eine "Schlüsselanhängerlösung" fände ich jedoch schicker...

Könntest Du mir evtl. noch einen ZWave controller (USB-Stick?) empfehlen?

Schönen Sonntag noch und viele Dank,
Andreas.

[krikan]

Also ich bin definitiv kein Programmierer, habe es aber auch schon geschafft Kleinigkeiten mit Rudis Hilfe in Fhem-ZWave einzubinden. Mit meinem Try-und-Error hat schon einiges funktioniert und die fehlende Class strotzt beim Lesen nicht vor Komplexität. Ob ich Dir in dem speziellen Fall helfen kann, weiß ich nicht. Habe bisher immer nur mit Testobjekten gearbeitet. Dann sieht man, was passiert. Im Fazit bleibt einiges an Basteln und probieren bei Dir hängen. Versprich Dir von mir nicht zu viel. Du solltest Dir vielleicht vor einer Bestellung mal 10_ZWave.pm und die Infos zu der Class USER CODE anschauen (wo: siehe http://forum.fhem.de/index.php/topic,36675.msg290223.html#msg290223). Ein Modul musst Du für die Class nicht schreiben, sondern normalerweise "nur" fehlende Codes oder subs ergänzen. Forum und vor allem Rudi helfen aber weiter. Evtl. meldet sich Rudi ja hier auch noch.

Wie tief ich in ZWave drin stecke? Schau im Forum und im Wiki: Interessierter User (Große Klappe hab ich zumindest...). Bei Zwave bin ich nur gelandet, da in EnOcean einige Geräte nicht existierten.

Wie sich BeNext und Zipato unterscheiden weiß ich nicht. Ich habe mir nur BeNExt im Detail angeschaut, da ich nur den bei http://www.pepper-one.de/zwavedb/ gefunden habe.

SECURITY wäre verschlüsselt und nicht in Fhem integriert. Wenn SECURITY notwendig wäre, würde ich mich an den Leser nicht herantrauen. Ohne Security ist es unverschlüsselt, aber zumindest über die Funkstrecke nach meiner Meinung sicherer als HM.

Einfach ist die Stickempfehlung: Nimm (Zave.me UZB http://www.z-wave.me/index.php?id=28 ). Der ist günstig und mit ZWave-Plus-Zertifizierung sehr aktuell.

Momentan würde ich dazu tendieren mir das Ding einfach mal zu bestellen, anzufangen und auf Hilfestellungen im Forum zu vertrauen.

So würde ich das bei den Infos zum Leser machen.

[rudolfkoenig]

Kann dem Text von krikan nicht viel hinzufuegen.

Viele Klassen kann man im ZWave Modul mit Debugausgaben- bzw. Doku-Studieren implementieren, ohne "richtig" programmieren zu muessen, es muessen "nur" die passenden Zeilen in zwave_class eingefuegt werden.

USER CODE zu implementieren sollte einfach sein.

SECURITY muessen wir auch mal implementieren, ich vermute aber, dass das laenger dauern wird, und ich auch ein Geraet anschaffen muss. Ich warte aber damit solange, biss dafuer einen oeffentlichen Druck gibt. Gibt es _interessante_ Geraete mit SECURITY?

[det.]

Hallo Rudolf,
öffentlichen Druck mag ich nicht aufbauen, aber wenn Ihr Z-Wave Security in Angriff nehmt, kaufe ich ein DanaLock und teste daran gern mit.

[A.Harrenberg]

Hallo Krikan, hallo Rudolf,

tja, dann werde ich wohl mal bestellen und sehen wie weit ich komme. Habe allerdings auch gewisse zeitliche Beschränkungen... Meine Frau wird mich sowieso schon schlagen wenn Sie sieht was ich bisher während Ihrer Abwesenheit so alles installiert habe

Werde mir mal das Zwave Modul ansehen und schauen was ich über die "Class User code" so alles finden kann. Im Symcon Forum haben die das ja auch hinbekommen.

Würde mich dann mal melden sobald das Teil angekommen ist und ich Hilfe beim Einstieg oder Verständnis des Moduls benötigen sollte.

Vielen Dank,
Andreas.

[krikan]

Gibt es _interessante_ Geraete mit SECURITY?

Muss gestehen, dass ich mir Danalock auch schon häufiger fasziniert angesehen habe. Jedoch fände ich SECURITY bei einer kleinen Handfernbedienung für meine Zwecke auch sehr interessant. Die ZWave.me KFOB-S http://www.pepper-one.de/zwavedb/device/562, die SECURITY unterstützt, kann ich nur leider in keinen Shop finden (nur alte Variante). Andere Handfernbedienungen mit SECURITY scheint es derzeit seltsamerweise nicht zu geben.

Werde mir mal das Zwave Modul ansehen und schauen was ich über die "Class User code" so alles finden kann.

Schau Dir im von mir verlinkten Beitrag die Quellen (PDF, openX-Code) an, das reicht mit der Bedienungsanleitung zumeist. Wenn Du selbst weitergehende oder aktuellere Infos finden solltest, dann gerne mitteilen.

[A.Harrenberg]

Hallo Krikan,

Schau Dir im von mir verlinkten Beitrag die Quellen (PDF, openX-Code) an, das reicht mit der Bedienungsanleitung zumeist. Wenn Du selbst weitergehende oder aktuellere Infos finden solltest, dann gerne mitteilen.

Hab' mir das mal kurz angesehen, liest sich jetzt erst mal wie ein relativ einfaches Protokoll. Bin jetzt gerade erst mal dabei ein zweites fhem aufzusetzen mit dem ich dann später "spielen" kann. Danach schaue ich mir mal das Modul näher an und versuche mal zu verstehen wie das ganze dort implementiert ist.

Dann muss ich wohl warten bis die HW da ist, damit ich erst mal prinzipiell sehen kann was da so alles passiert. Die "Grundfunktion" inklusive dem bereits angelernten RFID müsste ja eigentlich bereits funktionieren. Die Class User Code wird ja anscheinend nur für das An- und Ablernen der Tags und Tastencodes gebraucht.

In der openzwave_manufacturer_specific.xml sind zumindest schon Einträge für einen Tag Reader enthalten. Welcher das nun ist muss ich dann herausfinden.

Code Auswählen Erweitern

<Manufacturer id="008a" name="BeNext">
<Product type="0001" id="0100" name="myGate"/>
<Product type="0002" id="0100" name="myDisplay"/>
<Product type="0003" id="0100" name="DHS-ZW-SNMT-01 Multi Sensor" config="BeNext/Molite.xml"/>
<Product type="0003" id="0101" name="DHS-ZW-SNMT-01 Multi Sensor" config="BeNext/Molite.xml"/>
<Product type="0004" id="0100" name="Door Sensor" config="BeNext/DoorSensor.xml"/>
<Product type="0004" id="0101" name="Door Sensor" config="BeNext/DoorSensor.xml"/>
<Product type="0005" id="0101" name="Alarm Sound" config="BeNext/AlarmSound.xml"/>
<Product type="0006" id="0101" name="Energy Switch" config="BeNext/EnergySwitch.xml"/>
<Product type="0007" id="0100" name="Tag Reader" config="BeNext/TagReader.xml"/>
<Product type="0007" id="0101" name="Tag Reader" config="BeNext/TagReader.xml"/>
<Product type="0008" id="0101" name="Power Switch"/>
<Product type="000d" id="0100" name="Built-in Dimmer" config="BeNext/BuiltinDimmer.xml"/>
<Product type="0017" id="0100" name="Scene Controller" config="BeNext/SceneController.xml"/>
<Product type="0018" id="0100" name="Plug-in Dimmer" config="BeNext/PluginDimmer.xml"/>
<Product type="001e" id="0001" name="1Pole Switch" config="BeNext/1poleswitch.xml"/>
<Product type="001f" id="0001" name="2Pole Switch" config="BeNext/2poleswitch.xml"/>
</Manufacturer>

Wobei ich jetzt doch den Zipato bestellt habe...

Code Auswählen Erweitern

<Manufacturer id="0131" name="Zipato">
<Product type="0002" id="0002" name="RGBW LED Bulb" config="zipato/RGBBulb.xml" />
<Product type="6131" id="4501" name="Zipato Mini Keypad" config="zipato/MiniKeypad.xml" />
</Manufacturer>

Könnte also auch das Mini-Keypad sein... Mal sehen mit welchen IDs sich das Teil meldet.

Diese Fernbedienung ist interessant. Auf die Idee mit dem RFID/Keypad bin ich nur gekommen weil die Fernbedienung für Homematic so unglaublich klobig ist. Diese Fernbedienung hatte ich auch schon gesehen und sie von der Größe her noch als akzeptabel eingestuft, wobei die RFID Tags noch kleiner und vor allem robuster sind.

Die FB meiner momentanen Alarmanlage halten nicht sooo lange und jetzt gibt es die auch nicht mehr nachzukaufen... (Daher auch die Umstellung auf FHEM...)

Schönen Restsonntag noch,
Andreas.

[A.Harrenberg]

Hi Krikan,

Die ZWave.me KFOB-S http://www.pepper-one.de/zwavedb/device/562, die SECURITY unterstützt, kann ich nur leider in keinen Shop finden (nur alte Variante). Andere Handfernbedienungen mit SECURITY scheint es derzeit seltsamerweise nicht zu geben.

Also die FB hier bei Amazon hat das "-S" und dürfte dann doch die neue Variante mit Security sein, oder?
http://www.amazon.de/Z-Wave-Mini-Fernbedienung-Tasten-ZME_KFOB-S/dp/B00PR20P5Q/ref=sr_1_27?ie=UTF8&qid=1430674915&sr=8-27&keywords=zwave

Gruß,
Andreas.

[krikan]

Hallo Andreas,
zu den XMLs, da mir nicht bekannt ist, ob Du darüber schon informiert bist:
Die XMLs in Fhem, die im Wesentlichen von Openzwave kommmen, sind "nur" Hilfen zur Konfiguration der Geräte. Sie haben keine funktionale Bedeutung in Fhem. Auch ohne Auflistung des Gerätes in den XMLs funktionieren diese grundsätzlich.

Also die FB hier bei Amazon hat das "-S" und dürfte dann doch die neue Variante mit Security sein, oder?
http://www.amazon.de/Z-Wave-Mini-Fernbedienung-Tasten-ZME_KFOB-S/dp/B00PR20P5Q/ref=sr_1_27?ie=UTF8&qid=1430674915&sr=8-27&keywords=zwave

Danke fürs Suchen und Finden. Kennst Du diesen Händler? Mir ist der nicht bekannt und mich wundert, dass die einschlägigen ZWave-Spezialshops die Fernbedienung nicht listen. Das Dumme ist halt nur noch die fehlende Class SECURITY und die werde ich nicht in Fhem eingebunden bekommen. Das ist einfach zu komplex.

Gruß, Christian

[A.Harrenberg]

Hallo Krikan,

zu den XMLs, da mir nicht bekannt ist, ob Du darüber schon informiert bist:
Die XMLs in Fhem, die im Wesentlichen von Openzwave kommmen, sind "nur" Hilfen zur Konfiguration der Geräte. Sie haben keine funktionale Bedeutung in Fhem. Auch ohne Auflistung des Gerätes in den XMLs funktionieren diese grundsätzlich.

Das habe ich mittlerweile auch gesehen, dachte zuerst das da evtl. auch die Kommandos drin stehen würden.

Habe mir mittlerweile mal das Modul kurz angesehen, das wird 'ne Weile dauern bis ich mich da eingearbeitet habe...

Zur Fernbedienung, gesucht habe ich die nicht extra... Habe mir eben noch einen Z-Wave Steckdosenschalter bestellt damit ich wenigstens eine funktionierende Z-Wave Hardware habe mit der ich vergleichen kann. Dabei ist mir die FB aufgefallen.

Gruß,
Andreas.

[krikan]

Habe mir mittlerweile mal das Modul kurz angesehen, das wird 'ne Weile dauern bis ich mich da eingearbeitet habe...

Glaube ich. Zum Einstieg: Ergänzen musst Du die Zeile 210 der heutigen 10_Zwave.pm:

Code Auswählen Erweitern

  USER_CODE                => { id => '63', },
Hier sind set, get und parse analog zu den anderen Klassen einzuarbeiten. Die einzutragenden Werte ergeben sich aus dem besagten PDF in Verbindung mit den Implementierungen bei openX.

[krikan]

Habe mir eben noch einen Z-Wave Steckdosenschalter bestellt ..

Aber hoffentlich nicht Düwi!?

[det.]

ich hab inzwischen 2 von denen:
http://www.amazon.de/gp/product/B00AKA5EYC?psc=1&redirect=true&ref_=oh_aui_detailpage_o07_s00
und bin sehr zufrieden. Die DÜWI sehen genauso aus , sind nur teurer. Gibts da Schwierigkeiten?

[krikan]

Original-DÜWI-Firmware hat ein paar "Unschönheiten". Status bspw. wird nur durch Polling. Weiteres mal Tante Google fragen, oder Rudi wegen der Fernbedieung. Darum würde ich Düwi nicht mehr bei PC-Ansteuerung empfehlen. ZWave.me hat Düwi laut eigener Homepage übernommen und die Probleme mit der Firmware ausgebügelt. Taphome wird wohl auch die neuere Firmware nutzen.

[A.Harrenberg]

Hi Krikan,

selbstverständlich habe ich eine DÜWI bestellt... War ja die billigste... ,-(

Wollte ja nur was einfaches haben um eine funktionierende Kommunikation zu sehen. Ich hoffe die Firmware ist nicht völlig unbrauchbar oder lässt sich vielleicht sogar updaten?
Wobei sich Status nur über pollen schon grausig anhört. Habe ja eigentlich extra einen Aktor mit Rückmeldung genommen (dachte ich...).

Gerade ein wenig gesucht, Firmware scheint es nicht zu geben, und auf der Webseite von Zwave.me wird auf Unterschiede hingewiesen:

Code Auswählen Erweitern

Hint: This product was part of the  Z-Wave product line of the former German Brand Düwi acquired by Z-Wave.Me in March of 2014. The Z-Wave.Me version of the device may not be 100 % compatible with functions of the original Düwi product.
Tja, das nennt man dann wohl Lehrgeld ,-)

Vielleicht sollte ich dann die DÜWI zurückschicken und mir auch eine Taphome kaufen?

Gruß,
Andreas.

[krikan]

Die Firmware ist "unschön". Keine Class ASSOCIATION, keine Explorer Frames, SDK 5.x, ...
Würde ich persönlich nicht einsetzen und gerade für einen Einstieg in Fhem-ZWave finde ich das "ungeschickt".
Ob der Taphome besser ist, weiß ich nicht definitiv und habe erst mal Zweifel.
=> DÜWI/Popp-Original-Produkte würde ich im Einsatz mit Fhem meiden.

[rudolfkoenig]

Ich gehe davon aus, dass bei diesen Schaltern um die Sparversion handelt: Laut einem FHEM-Benutzer werden in den USA die guenstigeren ZWave Geraete ohne die regelmaessige Meldung der Daten verkauft, weil auf dieses Merkmal jemand ein Patent haelt.

Bei der DÜWI Fernbedienung hat jemand das Geraet ohne an eine Zentrale zu denken entworfen.

Vielleicht hat(te) man bei DÜWI generell nicht die HA-Anwender mit Zentrale im Fokus.

[A.Harrenberg]

Hallo Krikan, hallo Rudolf,

die Bestellung der DÜWI konnte ich noch stornieren, hatte aber ersatzweise bereits die taphome bestellt. Nach den Kommentaren von Käufern ist das zumindest eine neuere Version die bereits die Leistungs-/Strommessung unterstützt. So wie ich das im Internet nachverfolgen konnte war Düwi zwischendurch auch mal von RevRitter übernommen bevor dann z-Wave.me dran war...

Werde mein "Glück" jetzt erst mal damit versuchen, und mal sehen was die Steckdose so alles meldet.

Allerdings ist der USB-Stick und das RFID/Keypad bisher noch nicht mal verschickt worden ,-( Das wäre ja der wichtigere Teil.

Was das Modul angeht, da ist schon etwas mehr Regex und "hash" drin als ich ohne weiteres nachvollziehen kann... Werde mir mal eine einfache Klasse raussuchen und das Schritt für Schritt nachvollziehen um das Prinzip zu verstehen. So ganz ohne Hardware ist das aber ganz schön abstrakt, so kann ich ja nicht einmal Debug-output in den Code einfügen da ich das Modul ja gar nicht in Betrieb nehmen kann.

Mir stellt sich allerdings die Frage wie man die Befehle für die Klasse "User Code" denn im Modul unterbringt. Die müssten ja quasi für jedes Gerät das diese Klasse unterstützt spezifisch sein. Das gleiche müsste ja für "Manufacturer Specific" gelten, werde mal schauen wie es da gelöst ist.

Hab' ja noch ein paar Tage bis die Hardware ankommt.

Gruß,
Andreas.

[det.]

So sieht die Schaltscteckdose bei mir aus

[A.Harrenberg]

Hi det!

Welche Steckdose meinst Du denn jetzt, die tapHome oder die Düwi? Zumindest erkenne ich bei Dir die Klassen Meter, Powerlevel und Association, was ja schon mal dafür spricht das es nicht die alte Düwi ist.

Kannst Du mir noch verraten ob Du eine Statusmeldung in FHEM bekommst wenn Du die Steckdose manuell schaltest?

Gruß,
Andreas.

[det.]

hallo Andreas,
ich hatte den Link zum Produkt ( tapHome Homecontrol EasyPlug Schalt-Adapter) doch schon in Antwort 15 gepostet: http://www.amazon.de/gp/product/B00AKA5EYC
Die Statusmeldung beim manuellen Schalten kommt zuverlässig wenn Du die Dinger richtig wie im WIKI beschrieben einrichtest.

[A.Harrenberg]

Hi det,

ok, richtig, war irgendwie daneben.
Hört sich doch gut an, dann habe ich ja ein Device mit dem ich probieren kann.

Vielen Dank,
Andreas.

[A.Harrenberg]

Hallo,

so, meine HW ist da... und schon geht es mit den Fragen los...
Aber erst mal kurz zum aktuellen Stand:

USB-Stick eingebunden und tapHome Steckdose ohne größere Probleme eingebunden, funktioniert.

Zipato Keypad/RFID eingebunden, wird von get ... model als "Schlage Link Mini Keypad RFID" erkannt.

Wie erwartet funktioniert der RFID Reader nicht, User_Code wird ja noch nicht unterstützt. Dummerweise ist der beiliegende RFID-Tag NICHT angelernt, sodaß ich die Rückmeldung über "Command_Calls_Alarm_V2" auch nicht probieren kann.

Hier mal ein Logausschnitt wenn ich einen unbekannten Tag an das Gerät halte:

Code Auswählen Erweitern


2015.05.07 22:41:27 5: ZWDongle/RAW: /01
2015.05.07 22:41:27 5: ZWDongle/RAW: 01/14000400080e6303
2015.05.07 22:41:27 5: ZWDongle/RAW: 0114000400080e6303/00
2015.05.07 22:41:27 5: ZWDongle/RAW: 0114000400080e630300/00
2015.05.07 22:41:27 5: ZWDongle/RAW: 0114000400080e63030000/8f
2015.05.07 22:41:27 5: ZWDongle/RAW: 0114000400080e630300008f/e3
2015.05.07 22:41:27 5: ZWDongle/RAW: 0114000400080e630300008fe3/7e
2015.05.07 22:41:27 5: ZWDongle/RAW: 0114000400080e630300008fe37e/54
2015.05.07 22:41:27 5: ZWDongle/RAW: 0114000400080e630300008fe37e54/2a
2015.05.07 22:41:27 5: ZWDongle/RAW: 0114000400080e630300008fe37e542a/00
2015.05.07 22:41:27 5: ZWDongle/RAW: 0114000400080e630300008fe37e542a00/01040000e0
2015.05.07 22:41:27 4: ZWDongle_0: checksum= e0
2015.05.07 22:41:27 4: ZWDongle_0: data before substr 0114000400080e630300008fe37e542a0001040000e0
2015.05.07 22:41:27 4: ZWDongle_0: data after substr 
2015.05.07 22:41:27 5: SW: 06
2015.05.07 22:41:27 5: ZWDongle_Read ZWDongle_0: 000400080e630300008fe37e542a0001040000
2015.05.07 22:41:27 5: ZWDongle_0 dispatch 000400080e630300008fe37e542a0001040000
2015.05.07 22:41:27 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e630300008fe37e542a0001040000
2015.05.07 22:41:27 4: ZWave_ENTRY_CONTROL_8: Unknown message (USER_CODE 0e630300008fe37e542a0001040000)


Hier fällt mir auf das der data-string beim zusammenbauen mit einem "e0" aufhört (die extra Logzeile mit "data before substr" habe ich eingefügt), bei der Übergabe wird das im Code aber als checksumme wieder entfernt.

Ein Freund hat mir diesen Tag mal ausgelesen und da wird als Code für den Tag:
e37e542a000104e0 ausgegeben. Laut den Informationen die ich zu dem Reader gefunden habe, wird der Code des Tags 10-stellig übertragen, damit wäre das e0 dann Bestandteil des Tag-Codes und nicht die Checksumme. Allerdings stimmt die Berechnung der Checksumme...

Also mal erste Frage: wird JEDE Übertragung mit einer Checksumme beendet, oder wäre es möglich das ausgerechnet User_Code keine Checksumme sendet?

Edit: Hab die Messages mal mit Tastencodes erzeugt und es scheint so das "8f" auch noch zum Tag-Code gehört und dann das "e0" doch nur die Checksumme ist, da hat dann anscheinend was beim Auslesen des Tags bei meinem Freund nicht funktioniert... Das hat sich also "erledigt"

Zweite Frage wäre, wie ist der Aufbau von den Messages? Ich habe da bisher nicht wirklich viel dazu gefunden.
0114000400080e630300008fe37e542a0001040000e0
01 SOF start of frame
14 = dezimal 20 = Länge der Message
00040008
0e
63 Command Class User Code
03 report command
00 User ID (laut Info zum Reader)
00 UserID Status (laut Info zum Reader)
8f ??
e3 7e 54 2a 00 01 04 00 00 e0 Tag-Code

Edit:
8f e3 7e 54 2a 00 01 04 00 00 Tag-Code
e0 Checksumme


Wo finde ich denn Informationen zu dem Teil nach der Message Länge?

Und wie kann ich eine RAW-Message an ein Device schicken um z.B. mal manuell den Befehl zum Anlernen zu verschicken?

Vielen Dank schon mal,
Andreas.

[krikan]

2015.05.07 22:41:27 4: ZWDongle_0 CMD:APPLICATION_COMMAND_HANDLER ID:08 ARG:0e630300008fe37e542a0001040000

Schau Dir nur das im ARG an.
0e=Message-Länge
Den Rest hast Du schon auseinandergepflückt.

Baue für das ARG mal die passende Zeile in ein parse an der (in einer meiner obigen Beiträge) gezeigten Stelle in USER_CODE ein.
Anschließend baust Du in set das Passende zum Senden ein; würde nicht mit raw (beim Dongle) arbeiten.
Dann ein notify auf das parse-Event mit einem set zum setzen des Wertes.

Hoffe Du kannst mit der Kurzfasung hier was anfangen, ansonsten morgen mehr.

[rudolfkoenig]

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.

@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.

[krikan]

Rudi so schnell kann ich nicht mal tippen, wie Du den Code änderst .
IDs stehen hier drin: https://github.com/OpenZWave/open-zwave/blob/master/cpp/src/command_classes/UserCode.cpp

[A.Harrenberg]

Hallo Krikan,

Schau Dir nur das im ARG an.
0e=Message-Länge
Den Rest hast Du schon auseinandergepflückt.

Ah, noch mal eine Länge...
Mir ist schon klar das ich den vorderen Teil nicht brauche, würde trotzdem gerne wissen/verstehen was da übertragen wird. Da müsste ja Sender/Empfänger, evtl. auch das Routing drin stecken.

Baue für das ARG mal die passende Zeile in ein parse an der (in einer meiner obigen Beiträge) gezeigten Stelle in USER_CODE ein.
Anschließend baust Du in set das Passende zum Senden ein; würde nicht mit raw (beim Dongle) arbeiten.
Dann ein notify auf das parse-Event mit einem set zum setzen des Wertes.

Hoffe Du kannst mit der Kurzfasung hier was anfangen, ansonsten morgen mehr.

Yep, auf die Idee das einfach mal als einen "festen" set einzubauen bin ich gestern Nacht auch noch gekommen. Soweit ich Deinen Vorschlag verstehe geht das schon etwas weiter.
"Allgemeine" Set-Routine, Parsen, über Notify die benötigte Set-Message bauen und dann mit dem Set verschicken.

Werde ich mich mal dransetzen, allerdings kann ich da heute abend nicht dran arbeiten, muss dann bis zum WE warten.

Danke,
Andreas.

[krikan]

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.

[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 ?

[A.Harrenberg]

Hi,

ich habe das Ding im Einsatz, im Wiki hatte ich die verwendeten RFID tags mal aufgelistet:

Das Gerät ist für Tags nach:

ISO 15693
ISO 18000-3
Tag-itTM
spezifiziert. Als weiteres ist noch "RFiD" angegeben, was aber nicht wirklich hilft ein passenden Tag zu kaufen. Die "Standard"-Tags die es z.B. auf ebay oder bei Amazon gibt verwenden meistens ISO 14443 und sind nicht kompatibel. Bisher sind keine kompatiblen Tags ausser den originalen Hersteller-Tags bekannt.

Falls es Dir gelingen sollte mit dem Handy einen dieser Chips zu emulieren sollte es gehen, ich habe damals auf die schnelle keine Möglichkeit gefunden. Falls Du das was rausfindest wäre ich an der Lösung interessiert...

Gruß,
Andreas.

[ChrisW]

Schade da man ein Handy eh immer dabei hat bzw meine Smartwatch auch NFC hat .. wäre ja cool die Türe per Uhr zu öffnen

[tabbi]

Das Gerät ist für Tags nach:

    ISO 15693
    ISO 18000-3
    Tag-itTM

spezifiziert. Als weiteres ist noch "RFiD" angegeben, was aber nicht wirklich hilft ein passenden Tag zu kaufen. Die "Standard"-Tags die es z.B. auf ebay oder bei Amazon gibt verwenden meistens ISO 14443 und sind nicht kompatibel. Bisher sind keine kompatiblen Tags ausser den originalen Hersteller-Tags bekannt.

Ich habe mal folgende Tags ausprobiert und sie funktionieren:

Icode SLI ISO 15693 13,56 MHz Schlüsselanhänger Blau ABS (10 Stück) https://www.amazon.de/dp/B07GBLBS54/ref=cm_sw_r_em_apa_i_WKWH4EBKE852AXQ6AJDB?_encoding=UTF8&psc=1

Gruß tabbi