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

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

Vorheriges Thema - Nächstes Thema

tomster

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.

Papaloewe

Super, das gefällt mir.

Was müsste man denn für so ein Motorschloss auf den Tisch legen?

Papa Romeo

Wie schon per PM...wenn du Unterstützung brauchst...gerne
...die richtige Lötspitzentemperatur prüft man zwischen Daumen und Zeigefinger.
...überlasse niemals etwas einer Software, das du hardwaremässig erreichen kannst.
...unvorsichtige Elektriker werden schnell zu leitenden Angestellten.
und...never change a running System...no Updates if not necessary

tomster

#3
Zitat von: Papaloewe am 16 November 2018, 16:41:07
Was müsste man denn für so ein Motorschloss auf den Tisch legen?

Der Preis hängt ein bisschen davon ab, ob man die Rohrrahmen- oder Vollblattversion braucht. Erstere ist wohl etwas teurer.
Ich bin aus beruflichen Gründen über die Schlösser gestolpert und hab bislang nur einen Musterständer geordert. Der kostet € 390 netto.
Unser Kunde wollte das Schloss erst selbst ausprobieren, darum dieser "Umweg". Das Muster kann ich aber zurückgeben und dann entsprechend passende ÜLocks bestellen. Da ordere ich dann meins mit.

Im Onlineshop von Hornbach gibt es aber ein ÜLock-Set (Schloss + Handsender + Beschläge) für € 325.
Musst nur schauen, ob die technischen Daten (Dornmaß, etc.) auf deine Tür passen.  In einem anderen Onlineshop hab ich das Schloss alleine (allerdings mit Wunschmassen bestellbar) für ~ € 360 gesehen.

Das I/O-Modul liegt so bei ~ € 110.

Wenn man lieber bastelt (sprich sich das I/O-Modul sparen möchte), sollte man auch einfach an den Handsender ein paar Kabel anlöten können und diesen über die Relais des o.g. ESP-Moduls oder z.B. einen Homematic 8-fach Switch ansteuern können.

Ich hab aber in der von Papa Romeo angesprochenen PM auch schon "wunschgeträumt" selbst hier im FHEM-Kollektiv eine ESP/Wiegand/RFM69-Platine im Unterputzdosenformat zu entwickeln, die das 868 MHz-Protokoll des Schlosses spricht. Damit könnte man sich das I/O-Modul auch sparen. Aber bis dahin wäre es sicher noch ein weiter Weg; auch wenn Vedran die Dateien seines Boards auf Github als "Vorlage" veröffentlicht hat.

Der von Südmetall verwendete Handsender scheint eine hundsordinäre OEM-Fernbedienung zu sein. Sie schaut genauso aus wie die hier:
https://www.piwa.info/default/15-kanal-dickert-handsender-868-3-mhz-linear-code.html

tomster

#4
Auch wenn noch nicht alle Komponenten bei mir eingetroffen sind, schon einmal ein kurzer Zwischenstand:

Ich hab die von Vedran/ seinen Co-Devs bereitgestellten Demo-Version des ESP-GUIs ( https://bitadvise.com/esp-rfid/ ) einmal ein bisschen angetestet. Prinzipiell gefällt sie mir schon so gut, dass ich auf das Zusammenschustern einer eigenen ESPEasy-Config verzichten werde. Alle (für mich) relevanten Konfigurationsmöglichkeiten sind bereits implementiert.
So gibt es eine komfortable User-Verwaltung, bei der man auch einen Zeitablauf der jeweiligen UID angeben kann. Ideal für Handwerker oder den Besuch von Mutti zum Blumengießen während des Urlaubs.
Prima finde ich auch die Möglichkeit WiFi nach einer gewissen Zeit inaktiv setzen zu können. Erst bei Lesen eines Admin-Codes am Reader wird das WiFi wieder angeschaltet.

Einzig das Handling des Doorstatus-Kontakts, respektive dessen Konfig-Möglichkeit im GUI hat, sich mir noch nicht erschlossen.

Der Sebury-Leser (ich hab die Mifare-Variante bestellt) ist heute bei mir angekommen. Die erste Amtshandlung war jedoch einen Streifen Isolierband hinten auf den Piezo-Piepser zu Kleben. Das Ding ist unangenehm laut und leider nur digital leiser zu drehen (an oder aus).

Ohne Vedrans Board kann ich jedoch noch nicht arg viel mehr damit Probieren. Nur soviel: anscheinend erkennt der Leser auch das NFC meines Smartphones. Zumindest quittiert die im Leser verbaute LED, dass irgendwas gelesen wurde. Ich kenn mich mich RFID bislang noch überhaupt nicht aus, aber wenn ich künftig die Haustüre auch mit dem Telefon öffnen könnte wär das ein Addon-Feature mit dem ich nicht gerechnet habe. Meine Kids vergessen nämlich fortwährend ihre Schlüssel zu Hause, aber niemals (i.W. NIEMALS) das Smartphone ;-)

Das Touch-Display spricht recht gut an. Ich vermute allerdings, dass es ratsam wäre, ein paar "Fake-Fingerabdrücke" auf alle Ziffern zu verteilen, damit man auf dem Glas nicht gleich erkennen kann aus welchen Ziffern sich hinterlegte Codes zusammensetzen.

Anfang kommender Woche sollte auch auch das Vedran-Board bei mir eintreffen. Dann werde ich eine erste Luftverkabelung durchführen.

Papaloewe

Ich habe den Code einmal testweise auf einen Wemos D1 mini geflasht.
Leider ist die Version 0.9 zur Zeit nicht brauchbar, man kann die Wifi-Config nicht ändern.
Nimm also erst einmal die 0.8.1 , die funktioniert soweit.
Ich vermisse nur noch die Möglichkeit immer wiederkehrende Zeiten festzulegen.
Z.B. kommt ide Putzfrau jeden Mittwoch Vormittag und soll ansonsten keinen Zutritt bekommen.
Vielleicht mache ich mal einen Vorschlag.

Gruß Thomas

tomster

Danke für den Versionshinweis!

Das mit dem Putzfee-Modus ist richtig. Dieses Feature braucht es noch!

tomster

So, Vedran's Board ist heute angekommen. Schaut sauber aus!
Jetzt nur noch die Bauteile auflöten und die Firmware aufspielen. Weitere Tests gibts dann im Laufe der Woche.

tomster

Zitat von: Papaloewe am 21 November 2018, 18:07:53
Leider ist die Version 0.9 zur Zeit nicht brauchbar, man kann die Wifi-Config nicht ändern.
Nimm also erst einmal die 0.8.1 , die funktioniert soweit.

Hmm, ja da scheint etwas im Argen zu liegen...

Nach dem erstmaligen Flashen (V0.9.0) hat sich mein ESP brav im AP mode gemeldet. Nach Anmeldung konnte ich problemlos mein SSID auswählen und nach Reboot hat sich der ESP zunächst auch brav verbunden. Dummerweise (das ist mir bislang noch nie passiert) hat der DHCP-Server meiner Fritzbox anscheinend die IP-Adresse doppelt vergeben. OK, IP im DHCP auf der Fritte manuell geändert und Reboot. Wieder hatte ich problemlos eine Verbindung zum ESP. Also, abstecken und den Wiegand-Leser und 12V angeschlossen. Neustart und: Nix. der ESP kommt nicht mehr hoch; auch nach mehrmaligen reboots nicht.
Auch ein Neuflashen hat nix gebracht. Also ein "leeres Image" geflasht und nochmal von vorne. Diesmal habe ich testweise das Gastnetz der Fritte angegeben. Verbind seither, auch nach mehreren Reboots einwandfrei.
Vermutung:
Der Sketch hat ein Problem mit längeren SSID-Namen. Mein eigentliches Netz hat 17 Stellen. Das Gastnetz nur 8.

Allerdings kann ich fast keine Einstellungen vornehmen. Allerdings erst, wenn ich unten auf das gelbe "Flag" klicke und manuelle Save & Reboote. User hinzufügen geht problemlos. Wird auch alles erkannt und das Relais zieht an. Leider "zu gut". Erst ein Reboot lässt es wieder abfallen...

Zudem kann ich nach einiger Betriebszeit im GUI nicht mehr alle Punkte aufrufen. Logs gehen nicht mehr und User auch nicht. Ewig "Please wait...".

Ich werd mich Mal ein bissl mit Vedran austauschen. Gehen die o.g. Punkte alle in V0.8.1?


Papaloewe

Zitat von: tomster am 03 Dezember 2018, 13:04:58
So, Vedran's Board ist heute angekommen. Schaut sauber aus!
Jetzt nur noch die Bauteile auflöten und die Firmware aufspielen. Weitere Tests gibts dann im Laufe der Woche.

Wo gab es denn das Gehäuse?
Habe ich dummerweise beim Bestellen wohl übersehen. >:(

tomster

Gehäuse gab's im Tindieshop als Option (wie Du wohl wohl leider zu spät gesehen hast)

Ich bin nun auf die 0.8.1 gegangen. Scheint soweit alles zu funktionieren.

Der sTouch-Leser erkennt die Mifare-Tags, und schickt die ID brav an Vedrans Platine/Omer's sketch. Bei entsprechender Berechtigung zieht das Relais kurz an und das Funkmodul von Südmetall funkt ein "Tür auf!" an das Schloss. Ich bin drin! *freu*

Konfigurationsaufwand? Minimal, wenn man Mal vom Flashen des ESP und ein paar Kabeln absieht (Platine gibt's auch gelötet, is aber kein Hexenwerk).

Am sTouch:

Ich habe nicht alle Kabel angeschlossen, weil z.B. bei Anklemmen der LED-Litze (braun) der ESP nicht mehr starten wollte.
Links Kabelfarbe Reader, => rechts Schraubklemme an der Platine
rot => VIN
schwarz => GND
hellgrün => D0
weiß => D1

Den Klingeltaster hab ich derzeit noch nicht angeschlossen, weil ich nicht weiß ob ich am ESP das WiFi ganzzeitig aktiviert lassen will.

Die Konfiguration des Readers erfolgt durch Eingaben an der PIN-Tastatur.

1. Manager Code eingeben, um in den Programmiermodus zu wechseln (default: 888888):
*888888#
LED blinkt einmal grün auf und dann rot

2. Leser auf Wiegand-Modus stellen:
710#
LED blinkt erst hellgrün und nach Eingabe von # einmal kurz dunkelgrün

3. (optional) PIN-Codeeingabe (4-6-stellig; # beendet Eingabe) aktivieren.
730#
LED blinkt erst hellgrün und nach Eingabe von # einmal kurz dunkelgrün

4. (optional) Keypadbeleuchtung nur bei Bedarf:
832#
LED blinkt erst hellgrün und nach Eingabe von # einmal kurz dunkelgrün

5. Programmiermodus verlassen:
**
LED ist wieder weiß

6. Manager Code ändern:
*888888#[DeinCode(4-6-stellig)]#[DeinCode(4-6-stellig)]#

Platine

An Vedrans Platine muss man auf der Unterseite 2 Lötbrücken setzen:

1. Spannung zum Flashen mit USB-TTL
a. Entweder eine Brücke zwischen 5V und Mittelpad => Programmerspannung 5V
b. oder eine Brücke zwischen Mittelpad und 3V => Programmerspannung 3.3V

2. Lötbrücke Relay-Power um das Relais auf der Platine mit den 12V Versorgungsspannung anzusteuern

(optional)
Je nach Anwendungsfall kann man die beiden Schraubterminals "Button in" und "Door status" ebenfalls auf der Unterseite mittels Lötpads konfigurieren (Beschreibung in Vedrans PDF).

Jetzt werd ich mir ein Schloss mit den passenden Maßen für meine Haustür bestellen und dann geht's erstmal ans Testen (vorallem AF bei Frau, Kindern und der Putzfee).

So long,
Tom

tomster

Nur der Vollständigkeit halber:

Es geht auch mit den NFC-Chips im Handy. Zumindest mein Nokia wird einwandfrei erkannt. Allerdings muss man erst den Screen anmachen (Homescreen ohne Entsperrung reicht). Bei ausgeschaltetem Display ist NFC augenscheinlich nicht aktiv.

DAS sollte auch meine Frau und Kinder überzeugen!


sbiermann

Wie sieht es mit der Sicherheit bei den ganzen Teil aus? Sicherlich wird Fenster aufbrechen oder Tür vermutlich noch schneller gehen, aber ein einfachen RFID Chip lässt sich ja simple kopieren. Auch ein Angriffsszenario über die 868MHz wären denkbar, da die Hersteller für die Türschlösser ja nicht gerade für Sicherheit bekannt sind und gerne mal Sicherheitslücken einbauen.

Mal ne andere Frage, hat jemand sowas schon mal mit einen Kastenschloss, wie dies hier: https://static.opo.de/Gruppe63/63.098.17_2013120206_l.jpg realisiert?

tomster

Huiuiui. Sicherheit - ein gaaaanz schwer zu greifender Begriff (und eigentlich nicht originäres Thema des Threads hier...)

Es kommt nämlich immer darauf an, welche "Art" von Sicherheit man erreichen will; die ist ja nahezu beliebig steigerbar. IMHO gibt es (zu) viele Sicherheiten. Gefühlte Sicherheit, (versicherungs-)technische Sicherheit, Einbruchssicherheit, und, und, und.

In meiner "alten Burg" ist eine relativ dünne Haustüre mit einem Schloß mit Einfachverriegelung verbaut. Aufgehebelt ist die sicher schnell; wahrscheinlich sogar noch schneller als die Fenster hinter dem Haus eingeworfen sind. Aus versicherungstechnischer Sicht ist das aber (fast) egal, solange die Haustüre ordnungsgemäß versperrt ist. Und Letzteres machen wir - ehrlich gestanden - nicht immer, zumindest tagsüber nicht. OK, wir sind aber auch nur selten alle den ganzen Tag außer Haus.

Da es sich aber um ein Mietshaus handelt habe ich nach einer Lösung gesucht die

a. eine Verbesserung der (in erster Linie versicherungstechnischen) Sicherheit bietet und
b. ohne größeren Eingriff in den Bestand, bzw. zugleich rückrüstbar

verbaut werden kann. Im Idealfall erhöht sich durch die Maßnahme sogar auch noch der Komfort (auch wieder so ein schwer zu greifender Begriff). Ob sich daraus aber überhaupt eine Erhöhung der Sicherheit im Sinne eines Schutzes gegen Einbruch ergeben kann, wage ich - bei meinem Haus - zu Bezweifeln. Hierfür wäre es vielleicht ratsamer lieber das Haus zu wechseln ;-)

Das Haustürschloss aber ist mit ziemlicher Sicherheit nicht das schwächste Glied in meiner "Sicherheitskette" (sic!).

Ein selbstversperrendes Schloß, ggfls. mit Panikfunktion, wäre für meine Belange wohl ausreichend gewesen. Dadurch ist die Tür -auch versicherungstechnisch- immer versperrt und ich kann sie mit meinem normalen Schlüssel öffnen. Den "klassischen" Typus Einbrecher (Stein->Scheibe->drin) werde ich aber auch mit dieser Maßnahme wohl nur bedingt verschrecken.

In wie weit ich nun aber durch das Verbauen eines RFID-Lesers und eines Funkmoduls vielleicht vermehrt den Einbrecher V2.0 anlocke, der mit Funkscanner und Kartenkopierer um die Häuser schleicht, kann ich nicht einschätzen. Ich behaupte aber einfach Mal frech, dass dieser Phänotyp in meinen Breiten noch relativ wenig verbreitet ist. Kann sich aber natürlich alles noch ändern, wenn sich z.B. in Zukunft die Steinpreise drastisch erhöhen (pun intended).

Ich glaube aber dennoch, dass "mein System" den Vergleich mit all den Nukis, EQ3'en und Danalocks nicht scheuen muss. Aushebeln lässt sich mit entsprechender Kenntnis der Materie so ziemlich jede Schließart (zumindest im privaten Bereich) - und wenn es nur die Brute Force Methode "Stein-Scheibe-drin" ist.

Drum erzähle ich immer und überall, dass unser Haus so schäbig wäre, dass jeder Einbrecher wohl aus Mitleid eher etwas bei uns zurücklassen würde, als irgendwas mitzunehmen. Ist vielleicht nicht die "sicherste" Methode zur Einbruchsprävention, aber zumindest schadet sie auch nix ;-)

Zum Thema Kastenschloss kann ich leider nix sagen. Wenn ich es richtig verstehe dann sind das Zusatzschlösser, oder meinst Du die Dinger die bei Oma an der Tür vom Kohlenkeller waren?

sbiermann

Ich meine so ein Schloss wie auf dem Foto zu sehen ist. Das hängt innen an der Tür, weil die Tür einfach zu dünn ist für ein Steckschloss. Als Schlüssel ist ein Buntbartschlüssel von fast 10cm Länge notwendig. Die Tür und das Schloss sind mindestens schon 70 Jahre alt, vielleicht auch noch älter.

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

Mumpitz

Zitat von: tomster am 11 Juli 2019, 10:28:06
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...
Bin zur Zeit in den Ferien, aber vor den Ferien noch ein grosses Stück weiter gekommen. Das Problem war, dass der Sebury die beiden Wiegand Ausgänge mit 5V speist. Der Wemos benötigt aber 3.3V. Ich habe daher einen Levelshifter installiert und nun rennt es!

Es ist richtig, die Finger müssen auf dem Sebury und dem esp angelernt werden. Ansonsten wird er nicht grün und kommt von aussen keine Bestätigung.

Was mich stört und absolut unnötig finde ist das permanente rote blinken!

Nach den Ferien werde ich den Testaufbau fertigstellen und anschliessend in die Produktion überführen. Werde danach meinen Aufbau posten!

Onkel.Tom


Hallo zusammen,

habe bei mir den "ESP RFID Relay-Board" des Entwicklers "Vedran", geflasht mit Firmware Easyesp "mega-20191028" und daran den Wiegand-RFID reader Sebury (https://www.i-keys.de/de/Zutrittskontrollsysteme/Stand-Alone-Geraete/sKey-SA-W-w-Mifare.html) angeschlossen, den ich wie oben beschrieben in den Wiegand-Modus/34-Bit versetzt habe.

Leider bekomme ich im Devices-Bereich von Easyesp keine Tagdaten angezeigt, wenn ich einen RFID am reader vorbeiziehe.
Mit der Standard-Firmware von "Vedran" hat das noch geklappt, so daß ich einen Verkabellungsfehler als eher unwahrscheinlich ansehen würde.

Ich vermute stattdessen eine falsche Einstellung bei easyesp.
Meine Einstellungen sind angefügt.

Über jeden Tip bin ich dankbar.



Cybers

#32
du hast keine GPIO angegeben. Die stehen bei dir auf "none".

Gruß, Sascha
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

Onkel.Tom

Hallo,

diese Einstellungen hatte ich auch schon in Verdacht und hatte auch schon diverse Kombis durchprobiert, leider alle erfolglos.

Kann mir jemand sagen, wie die Einstellungen bei ,,Vedran's" Board genau sein müssten ?

Cybers

du hast dem Board (ESPEasy) nicht gesagt an welchem GPIO du den Reader angeschlossen hast. So kann das nicht klappen. Probier mal oben statt "none" -> "D8" und darunter statt "none" -> "D1"
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

Onkel.Tom


Onkel.Tom


Habe jetzt unter dem Reiter Hardware die bisher dort unter I2C gesetzten GPIO auf none gesetzt.
Damit konnte ich dann im Reiter Devices die GPIO für den Sensor wie vorgeschlagen auf D8 und D1 setzen - leider nur kein Erfolg  :-[, es werden weiterhin keine Tag-Daten angezeigt.

Noch weitere Ideen / Tipps ?

SamNitro

(Intel-Nuc Proxmox) (Homematic) (EnOcean) (CUL868) (CUL433) (Zigbee2MQTT) (ESP8266) (Echo) (DUOFERN)

Cybers

Dein RFID-Reader müsste eine grüne und eine weiße Leitung haben. Wo sind die bei deinem Board angeschlossen?
FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

Onkel.Tom



@ SamNitro:
Habe ich eingestellt, leider weiterhin ohne Erfolg.

@Cybers:
grün --> D0
weiß --> D1

siehe 1. Bild

Wenn ich einen RFID-Chip am reader vorbeiführe und dessen LED kurz von weiß auf grün umschaltet, dann müßte doch im Devices-Reiter in der Spalte Values der RFID-Inhalt anstelle der Null angezeigt werden, oder ?  (tut er nur leider nicht  :-[)

Cybers

FHEM 6.2 auf Raspberry PI 4 / Smartvisu
Eltako Serie 14: FAM14, FGW14-USB, FSB14, FSR14-4x, FSR14-2x, FDG14, FTS14-EM in Kombination mit Jung F50 24V Tastern
1-Wire Temperatursensoren
aus alter Zeit:
Gott sei Dank nur noch 3 Homematic Jalousie- & Schaltaktoren! Wer sich mit Funk auskennt, legt Kabel

Onkel.Tom

Nach "endlosem" try and error läuft es endlich !!   :) :) :)

@Cybers, Dein Tipp war richtig:
D0 -> GPIO 4
D1 -> GPIO 5

Bei der Firmware bin ich zurück auf mega-20181231.

I2C GPIO habe ich auf none eingestellt.
Das Ganze mit Wiegand 34.

Ufff !

Euch allen vielen Dank für die Hilfe !


bloodybeginner

#42
Hi,

ich habe mir auch mal das Board von Nardev besorgt. Zusammen mit ESPEASY erhalte ich jedoch einen Bootloop des verbauten ESPs.
Hat jemand eine Idee?


okay.... das neue nardev board benutyt andere gpios 12/13 ist jetzt angesagt

// bb

Jan007

Hallo

ich habe auch die Firmware auf einen NodeMCU und einen Wemos D1 mini an einen Rfid/Fingerreader per Wiegand angeschlossen und am Wemos D1 geht gar nichts, am NodeMCU geht es soweit ganz gut.

Ich nutze den ESP nur zum lesen der ID´s und verarbeite die Berechtigungen in Fhem per MQTT an ein ABUS Z-Wave Schloss

Das Problem ist, das der ESP nach ein paar Tagen kaum noch ins Wlan aufzunehmen ist und dann alle 2-4 Stunden nur noch als ACS per Handy erreicht werden kann, wo er sich nach ein paar stunden wieder abmeldet... Das ist als Türöffner eine ganz blöde Eigenschaft :-(
Ich habe diverse Firmware Versionen getestet 1.02-1.33 und den Patch von (https://github.com/esprfid/esp-rfid/issues/250) aber überall das gleiche Phänomen.

Läuft bei euch das Teil Stabil? oder ist der ESP defekt?

LG

Jan