Zutrittskontrolle mit ESP/Wiegand-Reader/868-MHz-Funkschloss

Begonnen von tomster, 16 November 2018, 16:06:04

Vorheriges Thema - Nächstes Thema

tomster

Geile Tür & lässiges Schloß!
Aber wie man das elektrifizieren soll (ohne den Style kaputt zu machen)? Puuuhh, keine Ahnung...

sbiermann

Das Schloss muss wohl wirklich noch aus der Zeit stammen in der das Haus erbaut wurde so um 1900 rum, wenn Google recht hat.

Meine Idee (heute beim Duschen gekommen) wäre, ein Seil oder Plastikgestänge (frisch aus dem eigenen 3D-Drucker) an den Hebel (auf dem Bild unten Links am Schloss) zum öffnen der Tür befestigen und dann mittels Servo- oder Schrittmotor den Hebel ziehen und somit das Schloss zu öffnen. Dann lässt es sich noch Mechanisch öffnen ohne das es Probleme gibt und könnte per RFID geöffnet werden. Dieser komische Holzstopfen über den Schloss scheint wohl früher mal für einen Türknauf oder so gewesen zu sein, da lässt sich vermutlich ein runder RFID Reader alla iButton rein setzen so das der auf der anderen Seite der Tür raus schaut.

ext23

Zitat von: tomster am 04 Dezember 2018, 09:19:29
Es geht auch mit den NFC-Chips im Handy. Zumindest mein Nokia wird einwandfrei erkannt.

Das lässt aber vermuten, dass per RFID nur die (U)ID ausgelesen wird. Das ist natürlich Sicherheitstechnischer Murks weil die kann man perfekt clonen heutzutage... So ein System macht nur Sinn mit EV1 Karten und vor allen wenn man mit Applikationen arbeitet und nicht nur Stumpf die UID benutzt nur damit man möglichst viele RFID Tags unterstützt...

HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

Stütti

Zitat von: sbiermann am 06 Dezember 2018, 08:19:50
Meine Idee (heute beim Duschen gekommen) wäre, ein Seil oder Plastikgestänge (frisch aus dem eigenen 3D-Drucker) an den Hebel (auf dem Bild unten Links am Schloss) zum öffnen der Tür befestigen und dann mittels Servo- oder Schrittmotor den Hebel ziehen und somit das Schloss zu öffnen. Dann lässt es sich noch Mechanisch öffnen ohne das es Probleme gibt und könnte per RFID geöffnet werden. Dieser komische Holzstopfen über den Schloss scheint wohl früher mal für einen Türknauf oder so gewesen zu sein, da lässt sich vermutlich ein runder RFID Reader alla iButton rein setzen so das der auf der anderen Seite der Tür raus schaut.

Ein Bekannter hatte früher auch ein ähnliches Schloss an seiner Haustür, aber das war schon "elektrifiziert". Da wurde der Riegel über einen Elektromagneten freigegeben/geöffnet.
Knopfriegelschloss nennen sich die. Die antike Variante habe ich nicht gefunden, aber in neuer gibt es sowas:
https://www.alibaba.com/product-detail/D88A-S-gate-door-Stainless-steel_60187890278.html
https://www.ebay.de/itm/263962364129
https://www.youtube.com/watch?v=GzIdbsv296g
FHEM auf Pi 4 + FTUI auf Pi 3, Eltako 14, SignalESP, JeeLink, EasyESP, ArduCounter, eBus-Koppler, openDTU

tomster

Zitat von: ext23 am 06 Dezember 2018, 09:41:26
So ein System macht nur Sinn mit EV1 Karten und vor allen wenn man mit Applikationen arbeitet und nicht nur Stumpf die UID benutzt nur damit man möglichst viele RFID Tags unterstützt...

Da gebe ich Dir vollkommen Recht. Und natürlich Danke für den Hinweis. Hatte ich so nicht auf dem Schirm!
Die zum Projekt gehörige Firmware unterstützt derzeit wohl lediglich die UID. Zumindest habe ich noch keine andere Einstellung gefunden. Der von mir verlinkte Leser kann aber laut Specs auch EV1/EV2. Meine Tags können das auch, nur halt mein Handy nicht.
Ich muss alerdings auch gestehen, dass ich mir darüber bislang keine großen Gendanken gemacht habe, da das die Software betrifft und man daran auch im verbauten Zustand jederzeit "schrauben" kann. 

ext23

Zitat von: tomster am 06 Dezember 2018, 10:09:35
Da gebe ich Dir vollkommen Recht. Und natürlich Danke für den Hinweis. Hatte ich so nicht auf dem Schirm!
Die zum Projekt gehörige Firmware unterstützt derzeit wohl lediglich die UID. Zumindest habe ich noch keine andere Einstellung gefunden. Der von mir verlinkte Leser kann aber laut Specs auch EV1/EV2. Meine Tags können das auch, nur halt mein Handy nicht.
Ich muss alerdings auch gestehen, dass ich mir darüber bislang keine großen Gendanken gemacht habe, da das die Software betrifft und man daran auch im verbauten Zustand jederzeit "schrauben" kann.

Dann solltest du auch EV1/EV2 Karten benutzen weil die sind noch recht sicher. Die Frage ist nur, wenn die wirklich nur die UID lesen, und man anstelle einer EV1 Karte eine MiFare Classic Karte mit derselben UID simuliert, ob der Leser das merkt oder nicht...

System die das wirklich richtig umsetzen kosten einiges mehr, und können in der Regel auch nur ein Kartensystem. Alles andere ist mehr oder weniger Spielzeug. Das ist wie die Abus Alarmanlagen die 4000er 125kHz Token nehmen, da habe ich einen Kollegen schon mit geärgert. Klar kann an zusätzlich ein PinPad benutzen, aber dann sind die Karten auch nur Spielzeug, die Sicherheit ist dann die PIN.

Also da wirklich schauen, gerade bei Türen. Das Thema ist nämlich das folgende: Einbrechner kommen rein, so oder so. Aber wenn sie reinkommen auf "normalen" weg, zahlt keine Versicherung. Das sollte einem klar sein.

/Daniel
HM, KNX, FS20, 1-Wire, PanStamp, AVR-NET-IO, EM1000EM, PCA301, EC3000, HM-LAN, CUL868, RFXtrx433, LGW, DMX @Ubuntu-Server (Hauptsystem) & Raspberry Pi (Satellit)

tomster

Leider stehe ich nicht wirklich im Thema, und weiß nicht wie Wiegand/DesFire/EV1 überhaupt zusammenspielen.
Vom Ansatz her würde ich vermuten, dass mein jetziges Setup schlichtweg auf dem Auslesen (nach Mifare Classic) der UID basiert. Da ja eigentlich alle EV1/EV2-Tags auch Classic "können" funktioniert das auch hier ganz gut. Nur halt nicht wirklich kopiergeschützt.

Hier hat jemand aber sogar eine DesFire-Library für Arduino/ Tensy entwickelt:
https://www.codeproject.com/Articles/1096861/DIY-electronic-RFID-Door-Lock-with-Battery-Backup

Der Author "elmue" wird allerdings auch im Header der PN532.cpp genannt, die in der "offiziellen" Firmware für Vedran's Platine auf github verfügbar ist. Im Code selbst scheint DesFire schon implementiert zu sein. Die Frage ist nur, ob dies dann nur mit einem PN532-Reader funktioniert, bzw. ob man das auch für Wiegand-Reader verfügbar machen kann. Ich werde einmal versuchen elmü/elmue ausfindig zu machen. Er ist/war ja auch im Microcontroller-Forum unterwegs und scheint Deutsch zu sprechen...

tomster

OK, hab gerade eine Rückmeldung auf eine Anfrage an i-keys erhalten.
Der von mir verwendete und im ersten Post verlinkte Reader kommt in den Specs wohl etwas "großspurig" daher:
Zitat:
Lesbare Transpondertypen:
13,56 Mhz
MIFARE® Classic 1k, 4k, 4byte oder 7byte
MIFARE® Desfire, EV1 , 2k, 4k, 8k
MIFARE® Ultralight
NTAG 203, 213

Das Dickgedruckte bedeutet, dass bei Verwendung eines DesFire-Fobs lediglich dessen Abwärtskompatibilität nach Mifare Classic genutzt wird. Sprich, es wird tatsächlich nur die UID ausgelesen und übertragen. Mehr kann der Leser nicht. Plöd...

mba

ich habe das als Grundlage genommen
http://www.codeproject.com/Articles/1096861/DIY-electronic-RFID-Door-Lock-with-Battery-Backup
und in meinen Bus integriert damit das über FHEM steuerbar wird.
Nach erfolgreicher Authentifizierung wird entsprechend ein Danalock und/oder der Türöffner gesteuert.

grüße
Marco
Tinkerboard für FHEM, Modbus RTU via RS485 mit Arduino Slaves, ZWAVE mit Razberry Modul

Mumpitz

Zitat von: tomster am 16 November 2018, 16:06:04
Servus zusammen!

Bei meiner Recherche zum Einbau einer Zutrittskontrolle bei mir zu Hause, bin ich auf ein paar Komponenten gestossen, die ich Euch nicht vorenthalten möchte. Vielleicht sind diese ja - auch in Teilen - für den Einen oder Anderen von Euch interessant. Bislang ist das zwar Alles nur Theorie, aber ich hoffe in den nächsten Tagen schon eine Rückmeldung aus der Praxis geben zu können.

Prinzipiell bin ich von folgenden Features/ Anforderungen ausgegangen:

- kein proprietäres Baumarkt-Komplettsystem
- einfache Nach-/Rückrüstbarkeit (bei mir Mietshaus)
- möglichst keine Kabel in der Tür verlegen zu müssen
- Standalone-Lösung (damit es auch ohne FHEM funktioniert), dennoch die Möglichkeit der Anbindung an FHEM (z.B. MQTT)
- keinen "Schlüssel-dreh-Aufsatz" zum Ver-/Entriegeln der Türe (finde ich "unprofessionell" und nicht sonderlich elegant)
- Möglichkeit die Türe auch mit Schlüssel entsperren zu können (mein bestehendes Schloss ist nicht beidseitig schließend -> Nuki & Co scheidet aus)
- Panikfunktion des Schlosses (bei Nuki, Homematic, Eqiva & Co. dauert mir das Entriegeln im Panikfall zu lange)
- automatische Verriegelung der Tür beim Gehen/ nach dem Eintreten
- Verwendung von Komponenten, die eine Systemschnittstelle besitzen (z.B. Wiegand, um nach Gusto/ Geldbeutel flexibel zu bleiben)
- keine Cloud-Lösung 

Ich möchte ausdrücklich betonen, dass ich hier nicht Werbung für bestimmte Hersteller mache. Alle genannten Hersteller und Produkte habe ich deshalb gewählt, weil sie für mich am Passendsten erschienen. Auch wurde mir von keinem Hersteller irgendein Rabatt gewährt, damit ich hier deren Produkte nenne! Ich hab sie einfach gekauft.


Ich habe mich (nicht zuletzt durch einige Inspirationen hier aus dem Forum) für eine Kombination aus
Leser mit Wiegand-Schnittstelle <-> ESP-basierter Auswerteinheit <-> elektrischem Schlosseinsatz
entschieden.
Ich muss allerdings zugeben, dass ich dabei nicht unbedingt immer die günstigsten Komponenten ausgewählt habe. Ich wollte eine Lösung, die nicht auf den ersten Blick nach einer Nachrüst-Baumarkt-Lösung aussieht.

Zutatenliste:

1. RFID-Leser:
"Sebury sTouch Mifare"
https://www.i-keys.de/de/zutrittskontrollsysteme/stand-alone-geraete/code-tastatur/zutrittskontrolle-stouch-standalone-w-w.html

Anmerkung: Dieser Leser kann "nur" das Mifare Classic Verfahren (kopierbare UIDs)! Das kann ein Sicherheitsrisiko bedeuten.

2. Auswerteinheit:
"ESP RFID Relay-Board" des Entwicklers "Vedran" auf Tindie (entweder per dessen Software oder ESPEasy-basierter Eigenlösung)
https://www.tindie.com/products/nardev/esp-rfid-relay-board-12v-for-esp8266-board/#

2.1 Software:
https://github.com/esprfid/esp-rfid oder eben "zu Fuß" über ESPEasy. Mal schauen.

3. Motorschloss:
Einsteckschloss "Südmetall ÜLock" mit 868-MHz-Anbindung über I/O-Modul desselben Herstellers
https://www.suedmetall-schliesssysteme.com/produkte/uelock-b-battery/vollblatt/

https://www.suedmetall-schliesssysteme.com/fileadmin/user_upload/Datenblatt_%C3%9CLock_IO_Modul.pdf

Prinzipiell ist damit eigentlich schon alles beeinander.

Herzstück wird das ESP-Board von Vedran sein. Er hat darauf eigentlich alles untergebracht, um Wiegand-basierte Leseeinheiten ohne externe Levelshifter oder Spannungswandler am ESP betreiben zu können. Noch dazu wird das gesamte ZuKo-System mit einer einzigen 12V-Zuleitung versorgt. Der ESP übernimmt dabei die Auswertung der vom Leser gesendeten Codes und gibt bei positiver Zugangsberechtigung über ein Relais-Schaltsignal den Öffnungsbefehl an das Motorschloss weiter. Das Relay-Board bietet auch die Möglichkeit einen Verriegelungskontakt als Rückmeldung anzubinden und/oder evtl. in der Leseeinheit verbaute LEDs, Klingeltaster, etc. anzuschließen.
Optional können natürlich auch alle Events via MQTT und WiFi an FHEM gesendet werden. Ob man das aus Sicherheitsgründen aber unterlässt, muss jeder für sich selbst entscheiden.

In meinem Fall landet der Relaisausgang am I/O-Modul des ÜLock-Systems. Dieses wiederum sendet dann den Öffnungsbefehl via 868-MHz an das Einsteckschloss. Im Normalzustand ist an diesem Schloss der Aussendrücker mechanisch entkoppelt. Nach dem entsprechenden Befehl fährt eine motorisch betriebene "Nuss" ein und stellt einen mechanischen Schluss des zweigeteilten Drückerstifts her. Dann kann man die Türe durch Betätigen des Aussendrückers einfach öffnen. Sollte einmal der ESP aussteigen kann man immer noch das Schloss von aussen mit einem Schlüssel öffnen. Dabei muss man allerdings, etwas anders als vielleicht gewohnt, den Schlüssel ~ 45° in Aufsperrrichtung drehen und gleichzeitig den Drücker betätigen. Vorausgesetzt natürlich, dass nicht die Batterien im Einsteckschloss leer sind. Hierfür gibt es aber einen "Batt-low"-Kontakt am I/O-Modul.

Das Schloss hat zudem eine automatische Verriegelung. Dabei fährt die Falle nach dem Schließen der Türe noch ein paar Milimeter aus. Versicherungstechnisch gilt dann die Türe als verriegelt, auch wenn dies nicht wie bei einem "normalen" Schloss über den separaten Schließriegel erfolgt. Im Vergleich zu Nuki & Co dauert es aber nicht ein paar Sekunden um das Schloß zu ver-/entriegeln, sondern geht ruckzuck.

Da der innere Drücker "fest" mit dem Schloss verbunden ist, kann man die Tür von innen jederzeit öffnen, ohne erst einen Schlüssel drehen zu müssen/lassen (Panikfunktion).

Mehr zu meinem Setup, wenn sämtliche Komponenten bei mir eingetroffen sind und ich einen Testaufbau fertig habe.

Hallo tomster

Ich bin zur Zeit an der Evaluation einer Auswerungseinheit für einen Wiegand Reader. Ich möchte den Reader zusammen mit einem Nuki betreiben.

Diesbezüglich habe ich zwei Fragen:

Ich finde den Controller von Vedran sehr cool. Lässt sich damit:
A) ein Potential freie Tasterschnittstelle anschliessen und so zb per HM fhem eine Mitteilung zukommen lassen?
B) kann der Controller z.b einen http Befehl absetzen um das Nuki direkt anzusteuern?
C) einen Befehl absetzen an fhem, welcher Benutzer sich erfolgreich am Leser verifiziert hat?

Weiter möchte ich in einer zweiten Phase noch eine weitere Eingangstür Smart machen. Könnte die Config einfach auf einen zweiten Controller übertragen werden oder müssen am zweiten Controller alle Benutzer neu eingelernt werden?

Besten Dank für deine hilfe

tomster

Servus Mumpitz,
Aus dem Stand kann ich Deine Fragen nicht beantworten. Noch dazu sind derzeit sämtliche Komponenten in Umzugskisten verpackt (Büroumzug). Ich glaube aber zu wissen, in welcher Kiste sie sich befinden. Vielleicht kann ich heut oder morgen aber noch schnell vorbei fahren.

tomster

Ich komme leider gerade nicht an das Teil hin. Ist doch zu gut versteckt irgendwo in den Umzugskartons. Ich versuch aber trotzdem einmal was zu Deinen Fragen zu sagen:
ZitatA) ein Potential freie Tasterschnittstelle anschliessen und so zb per HM fhem eine Mitteilung zukommen lassen?
Aus Vedrans Dokumentation kann ich nicht herauslesen, dass einer der Pins einen potentialfreien Kontakt bereitstellt. Er formuliert den Passus dazu aber in etwas unverständlichem Englisch...
Vielleicht schreibst Du ihn aber einfach Mal an und fragst nach.
ZitatB) kann der Controller z.b einen http Befehl absetzen um das Nuki direkt anzusteuern?
Der Sketch sieht dieses Setup nicht direkt vor. Du müsstest wohl entweder im Code des Sketchs etwas ändern, oder den Umweg über MQTT->FHEM->HTTP-Befehl gehen. MQTT kann der Sketch out-of-the-box.
ZitatC) einen Befehl absetzen an fhem, welcher Benutzer sich erfolgreich am Leser verifiziert hat?
Ich hab das Board schon länger nicht mehr angeschlossen (Projekt ruht wegen anderer Projekte) und kann mich nicht mehr erinnern was alles über MQTT gesendet wird, aber der Source Code lässt vermuten, dass der "Benutzer" auch dabei ist ;-)
...
void mqtt_publish_access(time_t accesstime, String const &isknown, String const &type, String const &user, String const &uid) {
...

Mumpitz

Zitat von: tomster am 31 Mai 2019, 09:25:14
Ich komme leider gerade nicht an das Teil hin. Ist doch zu gut versteckt irgendwo in den Umzugskartons. Ich versuch aber trotzdem einmal was zu Deinen Fragen zu sagen:Aus Vedrans Dokumentation kann ich nicht herauslesen, dass einer der Pins einen potentialfreien Kontakt bereitstellt. Er formuliert den Passus dazu aber in etwas unverständlichem Englisch...
Vielleicht schreibst Du ihn aber einfach Mal an und fragst nach.Der Sketch sieht dieses Setup nicht direkt vor. Du müsstest wohl entweder im Code des Sketchs etwas ändern, oder den Umweg über MQTT->FHEM->HTTP-Befehl gehen. MQTT kann der Sketch out-of-the-box.Ich hab das Board schon länger nicht mehr angeschlossen (Projekt ruht wegen anderer Projekte) und kann mich nicht mehr erinnern was alles über MQTT gesendet wird, aber der Source Code lässt vermuten, dass der "Benutzer" auch dabei ist ;-)
...
void mqtt_publish_access(time_t accesstime, String const &isknown, String const &type, String const &user, String const &uid) {
...


Hallo tomster

Besten Dank für deine Hilfe trotz Umzugsstress! Merci!

Ich werde Verdan mal anfragen und an dieser Stelle berichten. Wär halt schon cool wenn das ganze nicht von fhem abhängig ist und der NodeMCU direkt mit dem Nuki kommunizieren würde!

Gruss vom Gardasee


Gesendet von iPad mit Tapatalk

Mumpitz

Zitat von: tomster am 31 Mai 2019, 09:25:14
Ich komme leider gerade nicht an das Teil hin. Ist doch zu gut versteckt irgendwo in den Umzugskartons. Ich versuch aber trotzdem einmal was zu Deinen Fragen zu sagen:Aus Vedrans Dokumentation kann ich nicht herauslesen, dass einer der Pins einen potentialfreien Kontakt bereitstellt. Er formuliert den Passus dazu aber in etwas unverständlichem Englisch...
Vielleicht schreibst Du ihn aber einfach Mal an und fragst nach.Der Sketch sieht dieses Setup nicht direkt vor. Du müsstest wohl entweder im Code des Sketchs etwas ändern, oder den Umweg über MQTT->FHEM->HTTP-Befehl gehen. MQTT kann der Sketch out-of-the-box.Ich hab das Board schon länger nicht mehr angeschlossen (Projekt ruht wegen anderer Projekte) und kann mich nicht mehr erinnern was alles über MQTT gesendet wird, aber der Source Code lässt vermuten, dass der "Benutzer" auch dabei ist ;-)
...
void mqtt_publish_access(time_t accesstime, String const &isknown, String const &type, String const &user, String const &uid) {
...


Hallo nochmals

so, ich habe nun meinen Testaufbau vor mir liegen. das Projekt ist auf einem Wemos D1 mini geflasht und funktioniert. Über die Testmöglichkeit schaltet das Relay und die Fernbedienung übermittelt den Befehl.
Nun habe ich heute meinen Sebury F007EM-II dazu installiert. Aber ich komme mit dem Ding nicht zu recht. Die Kontrollleute oben blinkt die ganze Zeit rot. Ich habe einen RFID Tag sowie einen Fingern von mir angelernt. Sobald diese hingehalten werden, hört das rote Blinken auf und die LED leuchtet kurz grün. Wenn ein nicht angelernter Tag hingehaltn wird, wird er nicht grün sondern bleibt rot. Das anlernen scheint funktioniert zu haben. Aber eben, es blinkt die ganze Zeit rot, da kann was nicht stimmen.

In der ESP-RFID Software kommt überhaupt nichts an. Das Access Log ist immer abolut leer. Es ist eingestellt, das GPIO 12 (D0) und GPIO 14 (D1) sind. DO ist dementsprechend am Wemos auf D6 und D1 auf D7 angeschlossen.

Hast du mir einen Tipp was ich tun kann???

tomster

Ich kenne zwar den von Dir verwendeten Leser nicht genau, aber das klingt so, als wäre die Blinkerei korrekt. Zumindest gemäß den Angaben in der Bedienungsanleitung:
Stromsparmodus       Rotblinkt langsam
Standby                     Rot blinkt langsam

Zum leeren Log hab ich nur eine Vermutung:
Kann es sein, dass Du den Reader entweder in einem "Standalone-Modus" oder im "falschen" Wiegand-Modus betreibst?
Mein Sebury Tastenschloss hat ein relativ kompliziertes Menü, in dem man die jeweiligen Einstellungen so macht, wie früher bei den ersten Handies (#*123#). Damit kann man dann einzelne Funktionen umschalten. Unter Anderem den Betriebsmodus (z.B. Wiegand 26/37) oder die LEDs an/aus.
Hast Du Deinen Finger und den RFID-Tag am Reader selbst oder an Vedrans Modul "angelernt"? Ich vermute Ersteres...