Zutrittssteuerung - Wiegand to FHEM

Begonnen von nugat1, 15 September 2015, 22:43:27

Vorheriges Thema - Nächstes Thema

nugat1

Hallo,

durch "mitlesen" hier im Forum, habe ich bereits schon viel im Bereich Hausautomatisierung bei mir erreicht. Auch die viel zitierte Suchfunktion konnte fast alle meine Problem lösen.  :D
Nur bei meinem aktuellen Projekt, habe ich keine Lösung gefunden.
Ziel ist es einen Fingerprint-Sensor in FHEM so zu integrieren, dass ich auch auswerten kann, wer seinen Finger benutzt bzw. welcher Finger benutzt wird.
Dies hat folgende Vorteile:
- es kann zeitgesteuert Zutritt gewährt werden
- man kann (angelernte) Personen einfach sperren oder temporär zulassen
- ich kann Finger für verschiedene Aufgaben verwenden, z.B.: Zeigefinger Tür öffnen, Mittelfinger Tür verschließen, Ringfinger Licht schalten, ...

Da ich nun für mich eine Lösung gefunden habe, möchte ich das Wissen teilen und bin gern auch für eure Ideen & Verbesserungsvorschläge offen. ;)

Die Auswertung der verschiedenen Finger habe ich auf Basis der Wiegandschnittstelle realisiert. Damit ist es auch möglich diese Lösung auf Codeschlösser oder RFID Leser, welche Wiegand-fähig sind, zu portieren.

Zu meiner Hardware:
- Keymatic für die Tür
- Wiegand-fähigen Fingerprint Sensor - aufgrund der positiven Erfahrungen anderer Forumsmitglieder hab ich mich für den Sebury F2-2 entschieden
- raspberry pi - zur Auswertung Wiegand Signal
- FHEM auf banana pi
- 2x HMLAN mittels vccu
Komponenten sind via Gigabit-LAN verbunden (außer ein HMLAN - der über dLAN)

Software und Verkabelung sind basierend auf folgenden Projekt - PiDoorMan:
http://tonigor.com/pidoorman/
Von dieser Anleitung wurden nur Step 1 und Step 5 benutzt.

Nun hatte ich die Wiegend-ID auf dem Raspberry, sie musste nur noch in FHEM übertragen werden.

Dafür nutze ich einen dummy, der mittel HTTP-GET Befehl gesetzt wird.
Damit ich dies im Code von PiDoorMan machen kann, habe ich diese Aufgabe mittels des libcurl moduls hinzuprogrammiert.
Dazu wurde der Code wie folgt erweitert / verändert:

void printBits()
{
    // Prints out the results
    printf ("Read %d bits\n", bitCount) ; fflush (stdout) ;
printf ("Facility Code: %d\n", facilityCode) ; fflush (stdout) ;
    printf ("TagID: %d\n\n", cardCode) ; fflush (stdout) ;

    // HTTPS
char URL[200];
sprintf(URL, "https://fhem:8089/fhem?cmd=set+Fingerprint+%d", cardCode);

CURL *curl;
CURLcode res;

curl_global_init(CURL_GLOBAL_DEFAULT);

curl = curl_easy_init();
if(curl) {
curl_easy_setopt(curl, CURLOPT_URL, URL);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 1);
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 1);
curl_easy_setopt(curl, CURLOPT_CAINFO, "/home/pi/fhem.crt");
curl_easy_setopt(curl, CURLOPT_HTTPAUTH, (long)CURLAUTH_ANY);
curl_easy_setopt(curl, CURLOPT_USERPWD, "username:password");

/* Perform the request, res will get the return code */
res = curl_easy_perform(curl);
/* Check for errors */
if(res != CURLE_OK)
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));

/* always cleanup */
curl_easy_cleanup(curl);
   
}       

return;
}


Compileren muss man es nun mit folgenden Befehl: cc -o wiegand wiegand.c -L/usr/local/lib -lwiringPi -lpthread -lcurl

Wichtig war mir auch das Thema Sicherheit, desshalb HTTPS und User/Password Authentifizierung.
Dafür habe ich auch eine eigene Fhem Website erstellt:


define WEBfingerprint FHEMWEB 8089 global
attr WEBfingerprint HTTPS 1
attr WEBfingerprint basicAuth xxxxxxxxxxxxxxxxxxxxxxxxxx
attr WEBfingerprint allowfrom 192.168.x.x
attr WEBfingerprint allowedCommands set


Gibt es zum Thema Sicherheit von eurer Seite noch Anregungen etwas zu verbessern?


Ausgewertet wird derzeit nur mit einem simplen notify. Hier will ich auf alle Fälle noch mehr machen (wie bereits oben beschrieben)

define notify_Fingerprint notify Fingerprint {\
if($EVENT eq "xxxxxxxx")  { fhem("set keyMatic lock") }\
if($EVENT eq "xxxxxxxy")  { fhem("set keyMatic lock") }\
if($EVENT eq "xxxxxxyy")  { fhem("set keyMatic unlock") }\
if($EVENT eq "xxxxxyyy")  { fhem("set keyMatic unlock") }\
}


Erstaunlicherweise gibt es nach erfolgreicher Authentifizierung am Fingerpint keine Verzögerung bis die keymatic was tut - das passiert gefühlt, trotz dieser vielen beteiligten Komponenten, in Echtzeit.

Ich habe dieses Konstrukt bereits mehrere Wochen am Schreibtisch getestet. Seit dem WE ist es nun im Echt-Betrieb.
Somit fehlt noch die Langzeiterfahrung. :) (Schlüssel habe ich notfalls auch dabei  ;) )

Grüße

Rince

ZitatSomit fehlt noch die Langzeiterfahrung.
Und? Wie funktioniert es?
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

nugat1

Hallo,

nach einem Monat Betrieb sind die Erfahrungen nur positiv.  :)
Erfahrungen zur fhem Anbindung:
Bisher hat alles immer funktioniert. Sobald der Fingerprint den jeweiligen Finger positiv erkennt, fängt die Keymatic sofort und ohne jegliche Verzögerung an zu arbeiten.
Ich hatte es in der bisherigen Nutzung nur 2 mal, das es eine Sekunde gedauert hat, bevor was passiert. Wahrscheinlich hatte da der Banana Pi auf dem fhem läuft grad etwas zu tun  ;)

Erfahrungen zum Fingerprint als solcher:
Frauen- und Kinderfinger werden bei kalten Temperaturen erst garnicht als Finger erkannt  :P (Es gibt weder ein positiv noch negativ Signal vom Fingerprint)
-> Aber nach einen kurzen Aufwärmen der Hände durch reinpusten funktioniert es dann problemlos
Ich habe damit übrigens gar kein Problem, meine Finger werden in ca. 80 % beim 1. Mal erkannt, aber so gut wie immer beim 2. Mal.

Ein Nachteil an diesem Konstrukt ist, dass es nicht funktioniert, wenn fhem down ist --> dies ist aber bisher nie eingetreten.

Was ich bisher richtig super finde, das ich halt auch beim Verlassen zuschließen kann.
Und weiterhin bin ich völlig frei, welche anderen Schaltaufgaben ich den verbleibenden Fingern zuweise . :D

Ich werden demnächst noch eine USV einbauen, somit funktioniert das alles auch, falls mal kein Strom da ist.

Rince

Das klingt gut.
Werde wohl ein kleines ESP8266 Evaluationsboard damit beauftragen.

Besonders cool finde ich ja, das man dann schön in fhem Zeitprofile anlegen kann, wer wann Zutritt bekommt. Und das fhem, wenn ich das Haus betrete, schon mal die Kaffemaschine anwerfen wird.

Muss mir jetzt Gedanken machen, wie ich den Sensor außen mit Strom versorge, bzw. wie ich innen effektiv die Leitungen verstecken kann. Lehrrohre sind da wohl keine, und die Wand aufschlitzen ist jetzt auch nicht meins  ;)
Wer zu meinen Posts eine Frage schreibt und auf eine Antwort wartet, ist hiermit herzlich eingeladen mich per PN darauf aufmerksam zu machen. (Bitte mit Link zum betreffenden Thread)

dengbert

Hallo nugat1,
ich bin gerade auf der Suche nach genau der Möglichkeit, die Du bereits realisiert hast.
Mein Vorteil: Ich bin bereits Besitzer des Sebury F2-2 mit Wiegand Protokoll.
Ebenfalls fhem und paspberrys sind mir mehr als geläufig.
Meine Vorstellung ist es, da zwischen meiner fhem und der Haustür einige Meter dazwischen sind,
einen zusätzlichen rasperry zur Auswertung der Wiegand-Daten durchzuführen. Diese dann per WLAN übertragen.

Meine "Noch"-Anfängerfragen:
1) Wie genau hast Du die Zehnerdiode zur Wiegand-Leitung angeschlossen?
Kannst Du davon ein Foto posten? Wo genau wird die D0/D1 Leitung angeschlossen? Am Punkt Breakout-Connector (Bild auf pidoorman)?
2) Step1 ist alles logisch und nachvollziehbar. Aber Step6? Was genau hast Du da gemacht, oder meinst Du mit Step6 die Verarbeitung der Daten in fhem?

Über ein Feedback würde ich mich freuen.
Vielleicht geht die Konstellation bei weiteren Usern dann ja in Serie? ;-)

Gruß dengbert

nugat1

#5
Mittlerweile ist diese Lösung ja schon einige Zeit in Betrieb und es funktioniert immer noch hervorragend und das ohne Ausfälle!! :)
Es ist auch noch eine weitere Keymatic dazugekommen, nun kann ich mit einem Finger die Haustür zuschließen und parallel die Nebeneingangstür der Garage aufschließen und das Garagentor öffnen ;D

@dengbert:
Anbei zwei Bilder des Aufbaus.
Habe die Zenerdiode habe ich in Reihe mit Wiederstand zusammengelötet und das ganze ist mit einer Lüsterklemme zum Fingerprint verbunden. Zwischen der Zenerdiode und dem Wiederstand geht das Kabel zum Raspberry ab. (Dies geht sicherlich um einiges "schöner" aber es funktioniert  ;) )
Oh das mit Step 6 ist ein Tippfehler. Ich meinte Step 5 - run on boot.
Damit funktioniert das alles auch, falls mal kurz der Strom weg war oder der raspberry mal gebootet werden muss.

Eine Herausforderung ist es den ganzen Aufbau gegen einen Stromausfall zu sichern. Habe schon überlegt eine kleine USV hinzustellen, aber Aufgrund des meist hohen Eigenstrombedarfs habe ich das wieder verworfen. Habe jetzt überlegt eine Powerbank zu nehmen und mit einem Step-up Converter die 12v für den Fingerprint rauszuholen.
Vielleicht hat da ja noch jemand eine Idee...

Jan007

Hallo,

erstmal Vielen Dank für die gute Arbeit bis jetzt.

Gibt es da eine etwas genauere Anleitung?
Folgende Probleme der Reihe nach:
- Part C: the C code (http://tonigor.com/pidoorman/) brauch ich das? bzw. was genau muss ich ändern (Damit ich dies im Code von PiDoorMan machen kann, habe ich diese Aufgabe mittels des libcurl moduls hinzuprogrammiert.
Dazu wurde der Code wie folgt erweitert / verändert:)

- Wenn ich ./wiegand ausführe (wenn ich den Punkt weglasse, wie in der Beschreibung steht, geht es nicht)

Wiegand test v0.1
Written for Raspberry Pi
By Ben Kent
11/08/2012

Use standard site code for 26bit numbers (Y/N)?
y

Ready.
Present card:

Unknown format

wird sofort mit Unknown format bestätigt :-(

-was ist  2x HMLAN mittels vccu?

Ich habe seit ca. 1 Woche mit verschieden Einstellungen Versucht den PiDoorMan irgendwie in gang zu bekommen, aber ohne Erfolg. (Hardware 330 Wiederstan und 3,3VZehnerdiode/Raspberry mit aktuellen Raspian steht soweit)

Die Beschreibungen im Netzt sind einfach zu Stichpunkthaltig und wenn man nicht als Profi unterwegs ist, kommt man mit Code-Schnipsel ohne Ziel einfach nicht weiter.

Vielleicht hat jemand Zeit eine Detailliertere Schritt für Schritt Anleitung zu erstellen, wo auch diverse Ordner und Dateinamen erwähnt sind bzw. Beispieldateien oder Bilder.

Vielen Dank für Eure Mühe.

Gruß Jan


dengbert

Hallo Jan,
also ich habe die Kombi Raspi und Fingerprint verworfen.
Habe dafür einen ESP8266 von Olimex mit aufgebautem Relais besorgt, dort das ESP8266.nu Software drauf, Wiegand, Protokoll ausgewählt, Eingänge mit der Zehnerdiodenschaltung angeschlossen, MQTT nach kriwanek Anleitung installiert.
Wichtig war, dass der ESP routiniert, am besten so alle 50 Sekunden, etwas auf dem MQTT sendet, Systemressourcen oder sowas. Ansonsten gibt es einen Disconnect am MQTT Broker. Die Auswirkungen zeigen sich beim Fingerprint lesen.
Wenn eine erfolgreiche Lesung an den MQTT Broker gesendet werden soll, kann diese ins Nirvana gehen. Erst die zweite oder dritte Lesung ist dann erfolgreich an FHEM zugestellt worden.
Mit dem Relais onBoard konnte ich dann die Türentriegelung anstoßen, ebenfalls über MQTT, von FHEM aus.

@nugat1:
Dazu hatte ich mir auch Gedanken gemacht. Nur halte ich einen Stromausfall für sehr unwahrscheinlich im Bezug zur gleichzeitigen Notwendigkeit der elektronischen Türöffnung. Also Notfallkonzept = Schlüssel  ;)

Grüße

Brockmann

Weiß jemand von euch, wie lange das Kabel vom Fingerabdruck-/Kartenleser zum Raspberry Pi maximal sein darf?
Ich habe einen Raspberry Pi in der Nähe der Tür, der ohnehin 24/7 läuft. Aber das Kabel dorthin wäre effektiv vermutlich ca. 10 m lang.
Kann man das machen, ist es zumindest einen Versuch wert oder kann man so eine Länge von vorneherein vergessen?

dengbert

Hallo Brockmann,
sollte kein Problem sein. Ich würde es versuchen.

Brockmann

Kann mir als Elektronik-Laie vielleicht jemand bei der Auswahl behilflich sein?
Ich brauche ja 3V3 Zener-Dioden und 330R-Widerstände.
Jetzt habe ich mal bei reichelt geschaut und da gibt es jeweils mehrere bzw. viele Varianten.

Die Zener-Dioden unterscheiden sich beim Ptot-Wert (0,5 oder 1,3 Watt). Ist das egal oder was ist empfehlenswert?
Bei den Widerständen unterscheidet sich die Nennlast.

Der Physik-Unterricht ist lange her und ich verstehe die physikalischen Zusammenhänger dahinter nicht wirklich, deshalb wäre ich für eine Empfehlung dankbar, mit welchen Bauteilen ich auf der sicheren Seite bin.

dengbert

Also ich habe die 0,5 Watt Zehner Dioden. Bei den Widerständen kannst du auch die kleinsten nehmen.
Bei mir läuft die Schaltung seit über einem Jahr störungsfrei.

Brockmann

Zitat von: dengbert am 04 August 2016, 23:42:50
Also ich habe die 0,5 Watt Zehner Dioden. Bei den Widerständen kannst du auch die kleinsten nehmen.
Bei mir läuft die Schaltung seit über einem Jahr störungsfrei.
Danke!  :)

Benni

Anscheinend gibt es die Seite http://tonigor.com/pidoorman/ nicht mehr :(

Hat da jemand was aktuelles?

Über den Google-Cache lässt sich die Seite zwar noch aufrufen, allerdings fehlen dort die Grafiken/Schaltbilder.


dengbert

Es gibt ja nicht nur Google...
Probier es mal mit archive.org
Gruß dengbert



2meter_pdm

Hey Leute,
falls es jemanden interessiert , ich habe das mit einem Arduino gemacht.Ich habe das Sketch von der Seite https://blog.thesen.eu/teil-1-rfid-codeschloss-fuer-den-keymatic-abus-funk-tuerschlossantrieb-ersatz-fuer-km300-cac-cft-1000/ genommen,ein Lan Modul auf den Arduino  gehangen und mir die Daten via HTTP-Get an einem Dummy in Fhem schicken lassen.Geht seit 5Wochen ohne Probleme und funktioniert auch wenn Fhem mal off ist.

Benni

Zitat von: 2meter_pdm am 26 Mai 2017, 21:10:23
Hey Leute,
falls es jemanden interessiert , ich habe das mit einem Arduino gemacht.Ich habe das Sketch von der Seite https://blog.thesen.eu/teil-1-rfid-codeschloss-fuer-den-keymatic-abus-funk-tuerschlossantrieb-ersatz-fuer-km300-cac-cft-1000/ genommen,ein Lan Modul auf den Arduino  gehangen und mir die Daten via HTTP-Get an einem Dummy in Fhem schicken lassen.Geht seit 5Wochen ohne Probleme und funktioniert auch wenn Fhem mal off ist.

Ich hab das bei mir inzwischen mit nem WeMos D1 Mini und ESPEasy (kann Wiegand out of the box) gelöst. (Ist dann halt WLAN)

Rennt seit mehreren Wochen sehr zuverlässig!

mod25

Zitat von: Benni am 26 Mai 2017, 21:22:51
Ich hab das bei mir inzwischen mit nem WeMos D1 Mini und ESPEasy (kann Wiegand out of the box) gelöst. (Ist dann halt WLAN)

Rennt seit mehreren Wochen sehr zuverlässig!

Hallo Benni,
kannst du Bilder von dem Aufbau machen und zur Verfügung stellen?
Hast du eigentlich auch den F2-2 Fingerprint RFID Reader im Einsatz?
Wie ist der Weg dann vom ESPEasy zu fhem per mqtt ? und ist in deinem Aufbau auch das Verschließen mit drin?

Danke,
mod25

Benni

Zitat von: mod25 am 30 Mai 2017, 11:57:43
Hallo Benni,
kannst du Bilder von dem Aufbau machen und zur Verfügung stellen?
Hast du eigentlich auch den F2-2 Fingerprint RFID Reader im Einsatz?
Wie ist der Weg dann vom ESPEasy zu fhem per mqtt ? und ist in deinem Aufbau auch das Verschließen mit drin?

Hallo mod25,

evtl. komme ich am WE mal dazu ein paar Bilder zu machen und den Aufbau zu dokumentieren (steht für meine eigene Doku ja sowieso noch aus   ::))
Dass ich den F2-2 im Einsatz habe kannst du ja meiner Signatur etnehemen. Bin bisher sehr zufrieden damit.
Die Anbindung an FHEM läuft über das ESPEasy-Modul: https://fhem.de/commandref.html#ESPEasy
Ver-, bzw. Entriegeln habe ich bei mir am Kellereingang mit drin, an der Haustüre habe ich das aber über die Anwesenheitserkennung gelöst. Im Prinzip habe ich das ganze bei mir so ausgelegt, dass ich für jeden Fingerabdruck oder jede RFID eine beliebige FHEM-Aktion ( Entriegeln, Licht, Alarmanlage, ...) auslösen kann.

Ich muss das echt mal dokumentieren (wenn das blos nicht immer so zeitaufwändig wäre ;) )

Gruß Benni.

Benni

#21
So! Zwischenzeitlich hatte ich etwas Zeit ein paar Fotos zu machen und etwas zu Zeichnen.  8)

Hier also nochmal:

Verbaut habe ich bei mir einmal an der Kellertüre und einmal an der Haustüre jeweils einen Sebury F2-2 Fingerprint/RFID-Kombisensor. Genutzt wird aktuell aber nur der Fingerprint, kein RFID.
Die eigentliche Auswertung der Fingerabdrücke findet direkt im F2-2 statt und dieser sendet dann per Wiegand-Protokoll das zugeordnete Personen-Tag weiter. Dazu sind die Fingerabdrücke und die Personen direkt im F2-2 hinterlegt und müssen mit der mitgelieferten Windows-Software an diesen übertragen werden. Die selbe Konfiguration kann übrigens mit der Software auch auf mehrere F2-2 übertragen werden.

Zur Öffnung der Tür wird entweder die verbaute KeyMatic (verriegeln/entriegeln) verwendet, bzw. der Türöffner, der dazu von FHEM aus über einen Homematic hm-lc-sw4-wm geschaltet wird.

Zur Abnahme der Wiegand-Daten vom F2-2 hängt daran ein ESP8266 (WeMos D1 mini) der mit ESPEasy ausgestattet ist. ESPEasy kann Wiegand Out-Of-The Box. Die empfangenen Daten (der jeweils erkannte Tag) werden dann per FHEM-ESPEasy-Modul an FHEM gesendet, wo diese bspw. per notify weiterverarbeitet werden.

Verschaltet habe ich das bei mir, wie in angehängtem Schaltplan. Sorry für die vielleicht  etwas sehr laienhafte Darstellung aber ich bin eigentlich kein Elektroniker und so verstehe ich es wenigstens und kann es später wieder nachvollziehen.
Vielleicht macht man das so auch gar nicht, und es "fehlen" noch irgendwelche Widerstände o.ä. Wie auch immer, aber auf jeden Fall funktioniert das bei mir in Zweifacher Ausführung seit einigen Monaten absolut zuverlässig.

Eine gute 12V Spannungsversorgung war bei mir bereits vorhanden, daher habe ich die auch zur Versorgung der gesamten Schaltung hergenommen.

Aufgebaut ist das bei mir in beiden Fällen derzeit noch auf Experimentierboards, irgendwann werd ich das aber mal noch anständig auf einer Platine zusammenlöten ;)

Hier noch ein paar Links zu den von mir verwendeten Zusatzkomponenten:

Level Converter 3,3V <-> 5V bidirektional:
http://www.ebay.de/itm/Pegelwandler-4-Kanal-I2C-IIC-Logic-Level-Converter-BiDirektional-5V-3-3V-Arduino-/152409796871

DC DC Converter 12V -> 5V:
http://www.ebay.de/itm/172510509927

Sebury F2-2:
https://www.i-keys.de/de/f2-2.html

Homematic 4-fach Aktor
https://www.elv.de/homematic-funk-schaltaktor-4-fach-hm-lc-sw4-wm.html



Brockmann

Wollte mich nur bedanken.

Ich hatte schon über ein Jahr einen Fingerprint/RFID-Reader von Sebury hier liegen, aber bislang erst vorsichtig verschiedene Möglichkeiten erkundet, diesen mit FHEM zu verbinden.
Aber nachdem Benni hier eine quasi schlüsselfertige Lösung präsentiert hat, deren Umsetzung ich mir zutraute, bin ich den beschriebenen Weg gegangen und abgesehen von den üblichen Schwierigkeiten und Wirrungen für einen interessierten Elektronik-Laien hat alles gut geklappt.
Ich habe alles gleich auf eine Lochrasterplatine gelötet. War meine allererste, deshalb darf ich sie auch keinem zeigen ;), aber sie funktioniert. Dafür habe ich es jetzt schön kompakt und robust.

Nur einen kleinen Haken habe ich festgestellt: Wenn das ganze stromlos war (bspw. nach Stromausfall) wird der erste Code nicht vom Reader an den Wemos übermittelt. Vermutlich wird die Verbindung bei der Gelegenheit erst initialisiert. Ab dem zweiten Code klappt es dann aber zuverlässig.
Aber so oft fällt der Strom ja glücklicherweise auch nicht aus..

Benni

Positives Feedback hat was  :)
Dankeschön!

Bei Gelegenheit werde ich auch mal noch meine FHEM-seitige Schlüsselverwaltung dazu vorstellen. Aber im Moment habe ich noch ein paar andere Baustellen  ;D

Mumpitz

Da warte ich gespannt darauf. Bin mir am überlegen genau diese Lösung 1:1 umzusetzen!

Papaloewe

#25
Hallo Benni,

deine Lösung gefällt mir sehr und ich werde sie vermutlich auch einsetzen.
Ich stehe aber nicht so auf Fingerprint, daher die Frage, ob diese Sebury-Leser auch funktionieren müssten:

https://www.i-keys.de/de/Zutrittskontrollsysteme/Stand-Alone-Geraete/sKey-Standalone-W-w.html

Ich sehe eigentlich keinen Hinderungsgrund. Was meinst du?

Eigentlich bräuchte man auch nur den reinen Leser:
https://www.i-keys.de/de/Zutrittskontrollsysteme/Leser-fuer-Controller/EM4102-Uni/sKey-Leser-R-w.html

aber schaden tut der andere für 5€ mehr auch nicht, oder?

Danke für die Anregung Jungs.  :)

Gruß Thomas

P.S.: Gibt es so etwas auch für die Unterputzmontage?

Benni

Ja, die müssten auch gehen. Wichtig ist, dass die eben Wiegand können.


mod25

#27
Zitat von: Benni am 12 Juni 2017, 22:02:15
So! Zwischenzeitlich hatte ich etwas Zeit ein paar Fotos zu machen und etwas zu Zeichnen.  8)

Hier also nochmal:

Verbaut habe ich bei mir einmal an der Kellertüre und einmal an der Haustüre jeweils einen Sebury F2-2 Fingerprint/RFID-Kombisensor. Genutzt wird aktuell aber nur der Fingerprint, kein RFID.
Die eigentliche Auswertung der Fingerabdrücke findet direkt im F2-2 statt und dieser sendet dann per Wiegand-Protokoll das zugeordnete Personen-Tag weiter. Dazu sind die Fingerabdrücke und die Personen direkt im F2-2 hinterlegt und müssen mit der mitgelieferten Windows-Software an diesen übertragen werden. Die selbe Konfiguration kann übrigens mit der Software auch auf mehrere F2-2 übertragen werden.

Zur Öffnung der Tür wird entweder die verbaute KeyMatic (verriegeln/entriegeln) verwendet, bzw. der Türöffner, der dazu von FHEM aus über einen Homematic hm-lc-sw4-wm geschaltet wird.

Zur Abnahme der Wiegand-Daten vom F2-2 hängt daran ein ESP8266 (WeMos D1 mini) der mit ESPEasy ausgestattet ist. ESPEasy kann Wiegand Out-Of-The Box. Die empfangenen Daten (der jeweils erkannte Tag) werden dann per FHEM-ESPEasy-Modul an FHEM gesendet, wo diese bspw. per notify weiterverarbeitet werden.

Verschaltet habe ich das bei mir, wie in angehängtem Schaltplan. Sorry für die vielleicht  etwas sehr laienhafte Darstellung aber ich bin eigentlich kein Elektroniker und so verstehe ich es wenigstens und kann es später wieder nachvollziehen.
Vielleicht macht man das so auch gar nicht, und es "fehlen" noch irgendwelche Widerstände o.ä. Wie auch immer, aber auf jeden Fall funktioniert das bei mir in Zweifacher Ausführung seit einigen Monaten absolut zuverlässig.

Eine gute 12V Spannungsversorgung war bei mir bereits vorhanden, daher habe ich die auch zur Versorgung der gesamten Schaltung hergenommen.

Aufgebaut ist das bei mir in beiden Fällen derzeit noch auf Experimentierboards, irgendwann werd ich das aber mal noch anständig auf einer Platine zusammenlöten ;)

Hier noch ein paar Links zu den von mir verwendeten Zusatzkomponenten:

Level Converter 3,3V <-> 5V bidirektional:
http://www.ebay.de/itm/Pegelwandler-4-Kanal-I2C-IIC-Logic-Level-Converter-BiDirektional-5V-3-3V-Arduino-/152409796871

DC DC Converter 12V -> 5V:
http://www.ebay.de/itm/172510509927

Sebury F2-2:
https://www.i-keys.de/de/f2-2.html

Homematic 4-fach Aktor
https://www.elv.de/homematic-funk-schaltaktor-4-fach-hm-lc-sw4-wm.html

Hallo Benni,
Super Job danke für deine Erklärung.
Bei mir läuft es zur zeit nicht so glatt, mal klappt die Hardware mal nicht. Dann habe ich versucht per doif "set Tuer open" dies hat auch immer nur einmal funktioniert (ich musste immer clearreadings ausführung) damit es wieder funktioniert.... Heute funktioniert es nicht (nur am USB Port des PCs gehts).

Jetzt habe ich mir den Levelconverter gekauft in der hoffnung das es somit zuverlässiger läuft.

Jetzt habe ich noch drei Fragen damit ich es endlich lauffähig habe:
1. beim F2-2 müssen da nicht zweimal GND angebracht werden, einmal für die Stromversorgung und einmal für die Wiegand Anschlüsse?
2. Welches Netzteil nutzt du (Ampere usw.) wäre toll wenn du mir eine Empfehlung aussprechen kannst (meine Anbindung ist ca. 10 Meter lang)
3. Kannst du deine Umsetzung von Fhem posten inkl. Fingerhandling?

Vielen Dank,
und happy fheming
mod25


Benni

Zitat von: mod25 am 10 September 2017, 13:08:51
1. beim F2-2 müssen da nicht zweimal GND angebracht werden, einmal für die Stromversorgung und einmal für die Wiegand Anschlüsse?

Nö! Das sind doch Datenleitungen, die liefern Hi und Low.

Zitat von: mod25 am 10 September 2017, 13:08:51
2. Welches Netzteil nutzt du (Ampere usw.) wäre toll wenn du mir eine Empfehlung aussprechen kannst (meine Anbindung ist ca. 10 Meter lang)

Bin gerade nicht vor Ort. Schaue ich nach, wenn ich wieder da bin! min. 10m habe ich auch, das ist kein Problem!

Zitat von: mod25 am 10 September 2017, 13:08:51
3. Kannst du deine Umsetzung von Fhem posten inkl. Fingerhandling?

Mach ich noch!  Versprochen! ;)

mod25

Zitat von: Benni am 12 September 2017, 15:47:45
Nö! Das sind doch Datenleitungen, die liefern Hi und Low.

Bin gerade nicht vor Ort. Schaue ich nach, wenn ich wieder da bin! min. 10m habe ich auch, das ist kein Problem!

Mach ich noch!  Versprochen! ;)

Ich hab noch ein paar Phänomene und kann es noch nicht ganz eingrenzen.
Sobald der F2-2 Stromlos ist funktioniert die Erkennung nicht mehr zwar erkennt der Näherungssensor die Annäherung aber keine Fehl oder Gut Erkennung funktioniert.
Wenn ich es dann öfter mal Stromlos gemacht habe tut das F2-2 wieder das was es soll. Hierbei vermute ich die Stromversorgung (1 LED Netzteil 12V 0.5A und ein Router Netzteil 12V 1.2A) das die die Ursache dafür ist.

Auch ist die Erkennung der Finger sehr bescheiden mal auf Anhieb mal gar nicht, meine Erwartung ist eventuell bei diesem Gerät etwas zu hoch oder?

Meine Finger Erkennung habe ich per notify realisiert ein Vergleich zu deine Realisierung wäre super vielen dank dafür schon mal.

mod25

FrankieSOC

Hey Benni,

mit Hilfe deines Schaltplanes habe ich diesen RFID Reader https://www.i-keys.de/de/zutrittskontrollsysteme/leser-fuer-controller/mifare/a58m-mini.html aufgebaut und mit ESPEasy bekomme ich die Tags in Fhem angezeigt. Danke!

Leider weiß ich nun nicht weiter, wie ich mit den Daten intern arbeiten kann. Ziel ist es:
RFID bekannt -> Keymatic aufschließen
RFID unbekannt -> nichts

Das Abschließen habe ich über eine Anwesenheitskontrolle gemacht. Ich niemand mehr im Umkreis X Meter, wird nach 5 Min abgeschlossen.

Hast du einen Tipp für mich, wie du das mit deinen Fingerabdrücken in FHEM handhabst?

Viele Grüße
Frank

Benni

Leider bin ich bisher noch nicht dazu gekommen, das hier mal noch zu veröffentlichen.  :-[

Ich werde schauen, dass ich meine Lösung mal noch dieses WE zusammenschreibe und hier poste.

FrankieSOC

das wäre toll  :D

Mein doif will nicht so richtig klappen...
([ESPEasy_Eingang_Wiegand] eq "Tag: XXXX") (set HM_535E4E open)

Es funktioniert immer nur einmal, erst nachdem ich einen falschen Code benutzt habe, klappt es wieder.

Viele Grüße  ;)

HeikoE



Zitat von: FrankieSOC am 13 Oktober 2017, 17:41:06
das wäre toll  :D

Mein doif will nicht so richtig klappen...
([ESPEasy_Eingang_Wiegand] eq "Tag: XXXX") (set HM_535E4E open)

Es funktioniert immer nur einmal, erst nachdem ich einen falschen Code benutzt habe, klappt es wieder.

Viele Grüße  ;)

Hallo FrankieSOC,
BEI DOIF gibt's ein Attribut 'do always'. Bin kein DOIF Experte, aber vielleicht hilft das.
Gruß Heiko

Benni


FrankieSOC

Benni, da bin ich drauf gespannt.  8)

Das mit dem do always werde ich trotzdem mal testen.

Benni

#36
Also, trotz des herrlichen sommerlichen Wetters am vergangenen Wochenende, hatte ich doch die Zeit, meine Schlüsselverwaltung für die Präsentation hier zusammenzuschreiben:

Ein paar Dummies, ein (!) notify (und kein DOIF ;D), etwas Perl-Code mehr ist nicht nötig!

Zutrittsteuerung - Tag (Schlüssel) -  Behandlung in FHEM

Wie weiter oben beschrieben ist meine Wiegand-Zuttrittsteuerung so eingerichtet, dass ich für jeden Finger (erst mal egal von welcher Person) einen separaten Tag erhalte.
Dazu ist in meinen Sebury F2-2 jeder Finger (oder auch RFID-Tag) quasi als eigene Person hinterlegt. Hintergrund ist, dass ich mit jedem Finger prinzipiell unterschiedliche aktionen durführen können möchte.
Weiterhin ist es so, dass ich nicht nur einen F2-2 im Einsatz habe, sondern derzeit 2 Stück, nämlich einen an der Haupteingangstür und einen an der Kellereingangstür. Demnächst kommt vllt. sogar noch ein 3. am Garagentor dazu.

Um eine Zuordnung für mögliche Einfache Abschaltungen einzelner Schlüssel, bzw. Zuordnung von Aktionen zu haben, habe ich mir über Dummies (ich weiß "Wieso so viele Dummies ;) ) einige logische Devices, bzw. Device-Gruppen eingerichtet.
Diese Device-Gruppen beschreibe ich im folgenden:

Schlüssel/Tag-Devices (Tag):

Für jeden Tag (egal ob RFID oder Fingerprint) habe ich mir ein entsprechendes logisches Tag-Device angelegt:

Beispieldefinition Tag:


define tagBenni.LZF dummy
attr tagBenni.LZF userattr tagid tagowner tagmapping:textField-long
attr tagBenni.LZF devStateIcon on:ios-on-green off:ios-off
attr tagBenni.LZF group Key
attr tagBenni.LZF icon access_keypad_1
attr tagBenni.LZF room Zutritt
attr tagBenni.LZF setList on off
attr tagBenni.LZF tagid 1234
attr tagBenni.LZF tagmapping espdHaustuer:OpenHaustuer
espdKellertuer:ToggleKellertuer
attr tagBenni.LZF tagowner ownBenni
attr tagBenni.LZF webCmd :


Das Tag-Device bekommt, wie man oben sieht folgende user-Attribute (userattr):

   - tagid         = die Tag-ID, die auch vom ESPEasy-Device geliefert wird.
   - tagowner      = Name des zugeordneten Schlüsselbesitzers (s.u.)
   - tagmapping   = Aktionszuordnung (Erklärung folgt ganz unten)

Innerhalb dieses Tag-Devices wird angegeben, welchem Owner er zugeordnet ist (tagowner) und welche Aktion für welche Türstation ausgeführt werden soll, wenn der Tag (tagid) genutzt wird (tagmapping).
Die anderen tag-Attribute sind eher von informativem als funktionalem Charakter und sind denke ich selbsterklärend, bzw. wird deren Verwendung ggf. später im Code noch ersichtlich.

Der Status des Device bestimmt dann ob der Schlüssel aktiv (on) oder inaktiv (off) ist.

Schlüssel-Besitzer-Devices (KeyOwner):

Ein Schlüssel (Key=Tag) muss bei mir immer genau einem Schlüsselbesitzer zugeordnet sein.
Dafür gibt es diese Device-Klasse.

Beispieldefinition KeyOwner:


define ownBenni dummy
attr ownBenni userattr ownerName
attr ownBenni devStateIcon on:ios-on-green .*:ios-off
attr ownBenni group KeyOwner
attr ownBenni icon user_unknown
attr ownBenni ownerName Benni
attr ownBenni room Zutritt
attr ownBenni setList on off
attr ownBenni webCmd :


Das Schlüsselbesitzer-Device bekommte folgendes User-Attribut (userattr):

   - ownerName = Ein (beliebiger) Name für den Schlüsselbesitzer

Der state (on/off) bestimmt dann, ob der Schlüsselbesitzer aktiv (on) oder inaktiv (off) ist.
Wichtig, damit der Schlüsselbesitzer als solcher auch erkannt wird ist eben, dass das Attribut ownerName auch mit einem Wert belegt ist (Der Wert selbst ist dabei grundsätzlich unerheblich).

Was erreiche ich damit:

    - Übersichtlickeit über die einzelnen definierten Schlüssel, deren Besitzer
    - Übesichtlichkeit über den Zustand der einzelnen Schlüssel (aktiv/inaktiv)

    Ich kann nun also bspw. jeden Schlüssel einzeln aktivieren oder deaktiviern.
    Ebenso kann eich einen Schlüsselbesitzer aktivieren oder deaktivieren, damit sind dann
    auch gleichzeitig alle, ihm zugeordneten Schlüssel entsprechend aktiv oder inaktiv.
    Und ich kann je nach dem an welcher Türstation welcher Schlüssel eingesetzt wird, unterschiedlich auf diesen reagieren.

   Ich kann auch relativ Bequem eine zeitliche Steuerung für die einzelnen Schlüssel oder Schlüsselbesitzer einrichten (einfaches at).
   So kann ich bspw. die Fingerabdrücke für meine Urlaubs-Blumenversorger genau für den Zeitraum des Urlaubs aktivieren.
   Oder ich mache die Wirksamkeit von Schlüsseln von der Anwesenheit abhängig, oder, oder, oder ....

Man könnte sich noch überlegen, ob man auch logische Devices für die einzelnen Türstationen einrichten will.
Ich habe mir das aber gespart. Ich kann bei mir direkt die Stromversorgung zu den einzelnen F2-2 physikalisch schalten und somit bei Bedarf einzelne oder alle Türstationen deaktivieren.

Wie das ganze nun im Detail funktioniert im Folgenden:

Ich habe für jeden meiner Sebury F2-2 einen eigenen ESP der über ESPEasy angebunden ist (s. Beschreibung im Post weiter oben).
Wird nun ein Tag gesendet, so wird von diesen Device u.a. ein Event für das Reading tag erzeugt (so ist das in der ESP-Konfiguration benannt. siehe im Post weiter oben)
Dieses Event wird von einem Notify aufgefangen:

Meine ESPEasy-Devices sind dazu, wie bereits in der Tag-Definition im tagmapping zu sehen, wie folgt benannt:

    - espdHaustuer
    - espdKellertuer

Somit komme ich für beide mit einem einzigen notify aus, das wie folgt definiert ist:


define nyEspDoors notify esp.*tuer.tag.* {\
tagAction($EVTPART1,$NAME);;\
}
attr nyEspDoors devStateIcon inactive:ios-off:active .*:ios-on-blue:inactive
attr nyEspDoors room Zutritt


(Evtl. könnte/sollte man die regex  genau (!) auf die beiden Devices einschränken)

Dieses notify wiederum ruft nun die eigentliche Kern-Funktion tagAction, die entscheidet, ob und was nun passieren soll.
Dieser Funktion wird der tag (also nur die isolierte tag-Id, die vom F2-2 gesendet wird) und der Name des ESPEasy-Device (also der regeistrierenden Türstation) übergeben.
Letztendlich splittet sich das Ganze in mehrere Unterfunktionen auf, deshalb habe ich wegen der Übersichtlichkeit dafür eine eigene 99_MySimpleTagUtils.pm angelegt, man kann die aber natürlich auch alle in der 99_myUtils.pm ablegen.

Im folgenden nun also die 99_MySimpleTagUtils.pm mit vielen Kommentaren :)


##############################################
# $Id: 99_MySimpleTagUtils.pm 7570 2017-10-15 17:00:00Z Benni $
#

package main;

use strict;
use warnings;
use POSIX;

sub MySimpleTagUtils_Initialize($$) {
  my ($hash) = @_;
}

sub tagGetTags($;$) {
#Mit dieser Funktion kann ein Array abgerufen werden, das die Namen
#aller Schlüsseldevices mit bestimmten IDs (regex) und einem bestimmten
#Status (on/off) haben

#Übergeben wird die regEx für die tagID(s) und den tag-Status.
#Beides wird in entsprechende Variablen gepackt.
my ($tagId,$tagState)=@_;

#Wurde für die regex der tagID nichts angegeben, wird undef an die aufrufende
#Funktion zurückgeliefett und die Verarbeitung ist hier zu Ende
return undef if(!defined $tagId);

#Es sollen keine leeren tagIDs berücksichtigt werden, daher wird die regex
#im Falle von .* so angepasst, dass auf jeden Fall Devices mit belegtem (.+)
#tagid-Attribut gefiltert wird
$tagId='.+' if($tagId eq '.*');

#Wird für tagstate nichts angegeben, so soll nach beliebigem Status
#gefiltert werden (egal ob on oder off)
$tagState='(on|off)' if(!defined($tagState));

#Nun wird das devspec anhand der bis hierher zusammengestellten
#Filter zusammengesetzt und ausgeführt.
my $devspec="tagid=$tagId:FILTER=state=$tagState";
my @tags=devspec2array($devspec);

#Jetzt sollte als Ergebnis ein Array mit den gefundenen Devicenamen
#vorliegen....
my $tags=@tags;
if(int($tags)==1) {
#... falls nicht, wird undef zurückt gegeben
return undef if(!$defs{$tags[0]});
}
return @tags;
}

sub tagGetTagById($) {
#Es wird das Tag-Device zur übergebenen tagID ermittelt

#Übergeben wird die tagID (nicht als regex!), die packen wir in eine Variable
my ($tagid)=@_;

#Wir nutzen die Funktion tagGetTags und lassen uns alle tagDevices zurückgeben
#und zwar unabhängig vom aktiv-Zustand
my @tags=tagGetTags('.+');

#Das zurückgelieferte Array durchsuchen wir nach der übergebenen tagID
foreach my $tagdev (@tags) {
#Ist die tagID im aktuell durchsuchten tagDevice eingetragen, so
#haben wir das Device gefunden und geben den Namen zurück.
#Weiter müssen wir auch nicht suchen und die Verarbeitung
#endet hier.
return $tagdev if(AttrVal($tagdev,'tagid',undef) eq $tagid);
}

#wurden alle möglichen tag-Deveices abgeklappert und die gesuchte tagID
#nicht gefunden, dann laden wir hier und wir geben undef zurück, weil
#wir nichts gefunden haben.
return undef;
}

sub tagIsValidTag($) {
    #Überprüfen, ob der übergebene Schlüssel (tag/tagID) gültig ist.
    #0=ungültig / 1=gültig

   
#Die tagID wird übergeben, diese packen wir in eine Variable
    my ($tagid)=@_;

    #Wurde evtl. gar keine tagID übergeben, so kann diese auch nicht gültig
    #sein und damit sind wir hier schon fertig und geben 0 (=ungültig)
    #an die aufrufende Funktion zurück.
return 0 if(!$tagid);

    #über die Funktion tagGetTags lassen wir uns alle Tags mit der angegebenen
    #tagID die den Status 'on' (=aktiv) haben ermitteln
    #(Diese Funktion behandelt die tagID eigentlich als regex)
my @tags=tagGetTags($tagid,'on');

    #Konnte nicht genau eine tagID gefunden werden (also keine, oder mehr als eine),
    #so ist die tagID ebenfalls nicht gültig und wir sind hier fertig und geben 0
    #an die aufrufende Funktion zurück.
my $tagcount=@tags;
return 0 if($tagcount!=1);

    #Zur tagID, die an sich, wie wir wissen nun soweit gültig ist
    #(-> sie existiert und ist aktiv)
    #Das von tagGetTags zurügckgebene Array enthält somit genau 1 Element und
    #das ist der Name des Tag-Device und aus diesem ....
my $tagdev=$tags[0];
    # ... holen wir uns nun den Namen zugeordnete KeyOwner-Device
my $owner=AttrVal($tagdev,'tagowner',undef);

    #Abschließend muss nun noch geprüft werden, ob der Schlüsselbesitzer
    #auch gültig ist. Das Ergebnis dieser Prüfung bestimmt dann letztendlich die
    #Gesamtgültigkeit des Schlüssels (tag)
return tagIsValidOwner($owner);
}

sub tagIsValidOwner($) {
#Es wird überprüft, ob ein Owner-Device existiert und aktiv (on) ist.
#Ist das der Fall, so wird 1 an die aufrufende Funktion zurückgeliefert,
#ansonsten 0.

#Es wird der Name des gesuchten KeyOwner-Devices übergeben, der wird
#in eine entsprechende Variable gepackt.
my ($owner)=@_;

#Existiert kein KeyOwnerDevice mit angegebenem Namen, so kann dies
#auch nicht gültig sein und es wird 0 an die aufrüfende Funktion zurück
#geliefert und die Verarbeitung ist hier zu Ende
return 0 if(!$defs{$owner});

#Hier wird geprüft, ob es sich überhaupt um ein KeyOwnder-Device
#handelt, dazu wird das Attribut für den KeyOwner-Namen abgefragt
#Ist dies nicht gesetzt, so ist das Device kein gültiges KeyOwner-Device
#Die Verarbeitung Endet in diesem Fall hier und  es wird 0 an die
#aufrufende Funktion zurückgeliefert.
return 0 if(!AttrVal($owner,'ownerName',undef));

#Bis hierher waren alle Überprüfungen erfolgreich, also muss
#noch der Status (state) des Device geprüft werden. Steht dieser
#auf 'on', so ist das KeyOwner-Device gültig und es kann 1
#zurück geliefert werden.
return 1 if(ReadingsVal($owner,'state','off') eq 'on');

#Sollte die Verarbeitung bis hier kommen (stat ist nicht 'on'),
#so liegt letztendlich kein gültiges KeyOwner-Device vor und es wir
#0 an die aufrufende Funktion zurückgeliefert.
return 0;
}

sub tagAction($$) {
#Übergeben werden die tagID und die Quelle (=Name der Türstation)
#diese Informationen packen wir zunächst mal in eigene Variablen
my ($tagid,$source)=@_;

#Jetzt wird durch die Funktion tagIsValidTag geprüft, ob der übergebene Tag
#gültig ist. Die Definition der Gültigkeit -> siehe tagIsValidTag
my $tagvalid=tagIsValidTag($tagid);

#Im Log soll auf jeden Fall der Tag und die ermittelte Gültigkeit eingetragen werden:
my $validtxt='invalid';
$validtxt='valid' if($tagvalid);
Log3 'tagAction',3,"Source: $source - Tag: $tagid -> $validtxt";

#Wenn der Tag gültig ist, muss als nächstes Ermittelt werden, was denn nun ausgeführt werden soll
if($tagvalid) {

#Dazu holen wir uns anhand des übermittelten Tags (tagid) das entsprechende logische Tag-/Schlüssel-Device
my $tagdev=tagGetTagById($tagid);

#Dann lassen wir uns die eigentliche Aktion aus dem Device geben (siehe tagGetAction)
my $action=tagGetAction($tagdev,$source);

#Das Ergebnis für die ermittelte Aktion tragen wir auch ins Log ein
Log3 'tagAction',3,"Tag-Device: $tagdev -> Action: $action";

#Und wenn tatsächlich eine Aktion ermittelt werden konnte, so wird versucht, diese auszuführen.
#Auch das Ergebnis des Ausführungsversuchs wird ins Log eintegtagen.
if($action) {
Log3 'tagAction',3,'Trying to execute action...';
eval($action);
Log3 'tagAction',3,$@ if($@);
}

}
return undef;
}

sub tagGetAction($$) {
    #Es wird aus dem Übergebenen tag-Device und der Quelle (Türstation)
    #die entsprechende Aktion aus dem Reading tagmapping des tag-device
    #extrahiert

    #Der Name des tag-Device und die Quelle werden übergeben und in entsprechende
    #Variablen gepackt
my ($tag,$source)=@_;

my $actions=AttrVal($tag,'tagmapping',undef);

return undef if(!$actions);

    #Jetzt haben wir alle Zeilen aus tagmapping und die Zeilen werden nun
    #einzeln darauf überprüft, ob sie für die Quelle einen Eintrag haben
my @actionmap=split(/\n/,$actions);

foreach my $action (@actionmap) {
my($actsrc,$action)=split(/:/,$action,2);
        #Es wurde ein Eintrag für die gesuchte Quelle gefunden.
        #Damit sind wir fertig und geben diesen an die aufrufende FUnktion
        #zurück
return $action if($actsrc eq $source);
}

    #Es konnte keine Aktion zur Quelle gefunden werden
return undef;
}

1;


So, damit hätten wir nun alles an Code zusammen.

Was fehlt jetzt noch?
Genau! Bisher haben wir noch keine Aktionen definiert. Wir haben zwar im Beispiel-KeyDevice ein
entsprechendes Mapping eingetragen, allerdings haben wir noch keine Umsetzung.

Das Mapping (tagmapping) im o.g. Tag-/Key-Device ist im Beispiel mit folgendem Inhalt belegt:


espdHaustuer:OpenHaustuer
espdKellertuer:ToggleKellertuer


Jede Zeile im angegebenen Attribut definiert eine Aktion und zwar immer in Zuordnung zur Quelle (Türstation)
Also wird für den Tag, wenn er von Türstation (ESPEasy-Device) 'espdHaustuer' kommt die Aktion 'OpenHaustuer' ausgeführt.
Kommt der Tag jedoch von der Türstation 'espdKellertuer', so wird die Aktion 'ToggleKellertuer' ausgeführt.
'OpenHaustuer' und 'ToggleKellertuer' sind einfach 2 Funktionen in der 99_myUtils.pm, die bei mir entsprechenden Aktionen, an den jeweiligen KeyMatics ausführt.

Beide als Beispiel mal im Folgenden, die müssen natürlich auf die jeweilige Umgebung angepasst werden.


sub OpenHaustuer() {
#Wenn der aktuelle Status KeyMatic der Haustür 'entriegelt' ist,
#wird der Aktor für den Türöffner (Summer) kurz aktiviert
fhem('set aktTueroeffner on-for-timer 0.5') if(Value('KeyMatic_Haustuer') =~/unlock/);
}



sub ToggleKellertuer() {
#Die Kellertuer kann von innen und außen per Klinke geöffnet werden,
#daher wird hier einfach die KeyMatic zwischen den zuständen verriegelt und entriegelt getoggelt

#Es wird erst noch geprüft, ob die Tür an sich geschlossen ist. Dazu wird der ebenfalls
#vorhandene Tür-/Fenster-Kontakt geprüft
if(Value('tkKellertuer') eq 'closed') {
if(Value('KeyMatic_Kellertuere') eq 'locked') {
fhem('set KeyMatic_Kellertuere unlock');
} else {
fhem('set KeyMatic_Kellertuere lock');
}
}
}


Man kann das sicher auch noch kompakter aufbauen, v.a. was die "vielen" zusätzlichen Dummies anbelangt, aber ich finde so ist die Verwaltund der einzelnen Schlüssel deutlich übersichtlicher.
Eventuell habe ich irgendwann noch mal die nötige Zeit und Lust, dann packe ich das Ganze mal noch ein ein separates Modul mit dem dann die komplette Verwaltung zusammengefasst werden kann (ähnl. pahs Alarmanlage) und mit dem dann auch die Dummies wegfallen würden.
Im Moment funktioniert das für mich aber ganz gut und mir gefällt auch, dass das quasi mit elementaren FHEM-Bausteinen umgesetzt ist.

Viel Spaß damit!

gb#

Update 17.10.2017 19:00:

Im Code von 99_MySimpleTagUtils.pm war noch ein kleiner Bug in der sub tagGetTags. Dort muss die Zeile

$tagState="('on'|'off')" if(!defined($tagState));


durch


$tagState='(on|off)' if(!defined($tagState));


ersetzt werden (im Listing oben ist das inzwischen korrigiert)


FrankieSOC

Hallo Benni,

damit hatte ich nicht gerechnet, gefällt mir gut, vielen Dank.
Leider merke ich, wie schnell ich an meine "grenzen" komme.

Ich habe mit einem "tag" und einem "owner" zum Testen gestartet.
Internals:
   NAME       tagFrank.LZF
   NR         211
   STATE      on
   TYPE       dummy
   READINGS:
     2017-10-16 12:38:25   state           on
Attributes:
   devStateIcon on:ios-on-green off:ios-off
   group      Key
   icon       access_keypad_1
   room       Zutritt
   setList    on off
   tagid      1419114678
   tagmapping espdHaustuer:OpenHaustuer
   tagowner   ownFrank
   userattr   tagid tagowner tagmapping:textField-long
   webCmd     :


Das notify musste ich anpassen.
espdHaustuer {\
tagAction($EVTPART1,$NAME);;\
}


Der Perl-Code "MySimpleTagUtils" und "sub OpenHaustuer" ist eingetragen und angepasst.
sub OpenHaustuer() {
fhem('set HM_535E4E open')


Wenn ich jetzt den in der "tagid" definierten Code scanne, wird der "tag" in fhem beim "espdHaustuer" angezeigt, aber nichts passiert.

Im Logfile finde ich folgende Einträge.
Source: espdHaustuer - Tag: 1419114678 -> valid
Tag-Device:  -> Action:

Wenn ich einen falschen Code scanne.
Source: espdHaustuer - Tag: 2479659275 -> invalid

Wenn der ESP nach ein paar Minuten in absent geht, bekomme ich folgende Meldung.
Source: espdHaustuer - Tag: absent -> invalid
ERROR evaluating my $NAME='espdHaustuer';my $EVENT='absent';my $EVTPART0='absent';my $TYPE='ESPEasy';my $SELF='nyEspDoors';{ tagAction($EVTPART1,$NAME);; }: Global symbol "$EVTPART1" requires explicit package name at (eval 94413) line 1.
nyEspDoors return value: Global symbol "$EVTPART1" requires explicit package name at (eval 94413) line 1
.


Wo muss ich suchen?

Viele Grüße
Frank


Benni

#38
Zitat von: FrankieSOC am 17 Oktober 2017, 12:56:28
Wo muss ich suchen?

Ich glaube, da ist noch ein kleiner Bug drin. :-\
Ich bin dran  ;) ....


So, der Bug ist raus und im Listing im Post oben korrigiert und dort auch als Update beschrieben:

Zitat von: Benni am 16 Oktober 2017, 07:55:59
Update 17.10.2017 19:00:

Im Code von 99_MySimpleTagUtils.pm war noch ein kleiner Bug in der sub tagGetTags. Dort muss die Zeile

$tagState="('on'|'off')" if(!defined($tagState));


durch


$tagState='(on|off)' if(!defined($tagState));


ersetzt werden (im Listing oben ist das inzwischen korrigiert)



Das zweite, davon unabhängige Problem:

Zitat von: FrankieSOC am 17 Oktober 2017, 12:56:28
Wenn der ESP nach ein paar Minuten in absent geht, bekomme ich folgende Meldung.

das ist eine Folge davon:

Zitat von: FrankieSOC am 17 Oktober 2017, 12:56:28
Das notify musste ich anpassen.
espdHaustuer {\
tagAction($EVTPART1,$NAME);;\
}


Dein notify ist zu großzügig und greift alle (!) events ab, die von espdHaustuer erzeugt werden. Das sollte aber bei dir auch funktionieren:

espdHaustuer.tag.* {\
tagAction($EVTPART1,$NAME);;\
}


Ich gehe dabei davon aus, dass das Reading und der Event der in espdHaustuer erzeugt werden 'tag' heißt.




FrankieSOC

Mit der Anleitung kann man gut arbeiten.  :)

Diesen Fehler hätte ich nie gefunden...  :o
vielen Dank für suche, es hat direkt nach der Änderung geklappt.

Das "notify" hab ich nach deinem Hinweis angepasst, nun sind keine Fehlermeldung im logfile.

Eine Sache klappt noch nicht wie es soll.
Wenn ich den richtigen "tag" scanne, wird der Befehl nach 1 1/2 Minuten noch ein zweites mal gestarte.
2017.10.17 21:46:30.461 3: Source: espdHaustuer - Tag: 1419114678 -> valid
2017.10.17 21:46:30.461 3: Tag-Device: tagFrank.LZF -> Action: OpenHaustuer
2017.10.17 21:46:30.461 3: Trying to execute action...
2017.10.17 21:46:30.462 3: CUL_HM set HM_535E4E open
2017.10.17 21:46:30.465 3: Source: espdHaustuer - Tag: 1419114678 -> valid
2017.10.17 21:46:30.465 3: Tag-Device: tagFrank.LZF -> Action: OpenHaustuer
2017.10.17 21:46:30.465 3: Trying to execute action...
2017.10.17 21:46:30.466 3: CUL_HM set HM_535E4E open
2017.10.17 21:48:53.093 3: Source: espdHaustuer - Tag: 1419114678 -> valid
2017.10.17 21:48:53.094 3: Tag-Device: tagFrank.LZF -> Action: OpenHaustuer
2017.10.17 21:48:53.094 3: Trying to execute action...
2017.10.17 21:48:53.094 3: CUL_HM set HM_535E4E open


Im readings vom espdHaustuer, sieht man das der code 21:46 gescannt wurde und dann im 21:48 durch den Änderung "present" der Vorgang ein zweites mal gestartet wurde.
READINGS
Presence present 2017-10-17 21:48:53
State tag: 1419114678 2017-10-17 21:48:53
Tag 1419114678 2017-10-17 21:46:30


Hast du diese Phänomen auch schon beobachtet?

schöne Abend und Grüße
Frank

Benni

Stimmt!
Das hatte ich anfangs auch.

Ich habe am ESPEasy-Device das Attribut presenceCheck auf 0 gesetzt. Damit hatte sich das dann glaube ich erledigt.

FrankieSOC

#41
cool  8) Danke Benni, klappt.

hat doch nicht geklappt. "presenceCheck 0"

Nun sind es aber 5 Minuten  ???

state
tag: 1419114678 2017-10-18 15:09:32
tag  1419114678 2017-10-18 15:04:31

diese Attributes sind gesetzt.

   IODev      espBridge
   Interval   300
   group      ESPEasy Device
   presenceCheck 0
   readingSwitchText 1
   room       ESPEasy,Zutritt
   setState   3

Zeig mal deine? ;D

Benni

Zitat von: FrankieSOC am 18 Oktober 2017, 10:02:36
Zeig mal deine? ;D

Bitteschön:


Attributes:
   DbLogExclude .*
   IODev      espBridge
   Interval   0
   event-min-interval tag:10
   event-on-change-reading tag
   event-on-update-reading tag
   group      ESPEasy Device
   presenceCheck 0
   readingSwitchText 1
   room       ESPEasy
   setState   3


Dann wird's wohl Interval sein.
Selber experimentieren ist übrigens immer noch elaubt ;)

zentis666

Hallo!
Ich hab die von  Benni vorgestellte Lösung nachgebaut und mein altes SBoard Steuergerät ersetzt, funktioniert super, vielen Dank dafür!
Nun möchte ich eine Benachrichtigung per Telegram verschicken wenn ein Tag verwendet wurde.
In der 99_MySimpleTagUtils.pm werden die Variablen $owner und $tagdev für Besitzer und Tag-Device genutzt,
diese würde ich dafür gern benutzen. Die Variablen werden aber nicht aufgelöst sondern es wird dann
"Türöffnung von $owner mit $tagdev"
übertragen.

In der 99_myUtils.pm hab ich folgendes:

sub OpenHaustuer() {
#Öffen Keymatic und Statusmeldung per Telegram
fhem('set Keymatic open');
fhem('set telegram message Türöffnung von $owner mit $tagdev')
}


Was mache ich falsch? Tippfehler? Ich hab schon alles mögliche versucht, finde aber keine Lösung,

Gruß
Sven
--
FHEM auf Debian VM - ESXi 6.0 Intel Nuc i5 4th Gen, Homematic auf HMCCU - RaspberryMatic auf Raspberry PI 3,
EM1000 & FS20 über CUNO,  IT über Arduino Firmata, MiLight über WLAN-nRF Gateway, Ebus, 1Wire, diverse Squeezeboxen, Dreambox 920UHD, Homebridge

Brockmann

Zitat von: zentis666 am 17 Dezember 2017, 18:06:47
Was mache ich falsch? Tippfehler? Ich hab schon alles mögliche versucht, finde aber keine Lösung,
Schon mal doppelte Anführungszeichen ("...$variable...") probiert?

Benni

Zitat von: Brockmann am 17 Dezember 2017, 18:37:31
Schon mal doppelte Anführungszeichen ("...$variable...") probiert?

Im Prinzip nicht ganz verkehrt, aber ....

Die sub OpenHaustuer() kennt die beiden Variablen ja gar nicht! Man müsste die Varaiblen also erst mal an die sub weitergeben oder dort ermitteln, so dass sie damit arbeiten kann. Eine Varaiblenübergabe habe ich in meiner Schlüsselverwaltung derzeit für die Actions aber gar nicht vorgesehen.

Das könnte man aber einrichten, indem man in der sub tagAction die Ausführung der Action im eval entsprechend erweitert.

Aber ....

auch die sub tagAction kennt die Variablen $owner und $tagdev nicht derzeit nicht.

Da müsste man einiges anders lösen, als es derzeit gelöst ist.
Mal sehen, vielleicht habe ich später mal noch Zeit und Muse dazu, dann bastel ich was.

gb#


mod25

vielleicht könnt ihr mir bei folgenden Hardware Problem helfen.

Seid dem Wochenende nachdem ich versucht habe mein Kabelsalat im Keller zu sortieren beept die Sebury F2-2 nur noch als ob eine negativ Erkennung stattfindet.
Manchmal sofort 2-3 hintereinander manchmal mit mehreren Sekunden Abstand. nachdem ich gedacht habe das ich da eventuelle eine brücke im kabel habe habe ich diese nicht gefunden. dieses Problem tritt auch auf wenn ich nur die Stromversorgung anschließe ohne Belegung der Data0 und Data1 (GND) der Wiegand Schaltung.

Habe ich das Gerät gehimmelt oder hat dies eine andere Ursache leider hatte ich noch keine Möglichkeit es an einem PC anzuschließen.

vielen Dank für eure Hilfe.
mod25


Benni

Zitat von: mod25 am 18 Dezember 2017, 07:57:08
dieses Problem tritt auch auf wenn ich nur die Stromversorgung anschließe ohne Belegung der Data0 und Data1 (GND) der Wiegand Schaltung.

Keine ausreichende oder fehlerhafte Stromversorgung?
Mal eine andere, leistungsfähigere Quelle versuchen.

gb#

mod25

#48
Zitat von: Benni am 18 Dezember 2017, 08:07:18
Keine ausreichende oder fehlerhafte Stromversorgung?
Mal eine andere, leistungsfähigere Quelle versuchen.

gb#

sorry hatte ich vergessen zu schreiben das Netzteil womit das ganze funktionierte habe ich bereits gewchselt wobei ob dieses Leistungsfähiger bezweifle ich hat aber den selben effekt.

bzgl. der stromversorgung habe ich vermutlich schon immer meine Probleme gehabt, aber jetzt verhält es sich ganz anders.

zur Verkabelung noch folgende Infos.
der Fingerscanner ist am Briefkasten montiert welcher per Cat6 oder doch 7 Leitung angebunden ist.  diese Leitung (max 10 Meter)  geht direkt in den Keller in eine CAT 6 Patch panel (8 Port) und auf den Port habe ich ein RJ45 Leitung mit offen liegenden adern an meinem pi 3 angeschlossen. Wie gesagt es hat schon mal funktioniert.

Was mich aber total daran störte wo es funktioniert hat, war die erkennung des fingers der 50/50 war. Mal hat er es erkannt mal nicht. Kann dies auch die Stromversorgung sein bzw. meine Verkabelung.

Vielen Dank für deine/eure Hilfe 

zentis666

Zitat von: Benni am 18 Dezember 2017, 06:45:03

Die sub OpenHaustuer() kennt die beiden Variablen ja gar nicht! Man müsste die Varaiblen also erst mal an die sub weitergeben oder dort ermitteln, so dass sie damit arbeiten kann. Eine Varaiblenübergabe habe ich in meiner Schlüsselverwaltung derzeit für die Actions aber gar nicht vorgesehen.

Das könnte man aber einrichten, indem man in der sub tagAction die Ausführung der Action im eval entsprechend erweitert.

Aber ....

auch die sub tagAction kennt die Variablen $owner und $tagdev nicht derzeit nicht.

Da müsste man einiges anders lösen, als es derzeit gelöst ist.
Mal sehen, vielleicht habe ich später mal noch Zeit und Muse dazu, dann bastel ich was.

gb#
Hallo Benni,
an der Variablenübergabe hab ich mich gestern auch schon versucht, da komme ich aber Perl-mäßig an meine Grenzen.

Wäre super wenn Du da was zur Verfügung stellen könntest, schon mal Danke für die Unterstützung!

Grüße
Sven




Gesendet von iPhone mit Tapatalk
--
FHEM auf Debian VM - ESXi 6.0 Intel Nuc i5 4th Gen, Homematic auf HMCCU - RaspberryMatic auf Raspberry PI 3,
EM1000 & FS20 über CUNO,  IT über Arduino Firmata, MiLight über WLAN-nRF Gateway, Ebus, 1Wire, diverse Squeezeboxen, Dreambox 920UHD, Homebridge

Papaloewe

Hallo Benni, hallo Leute,

vielen Dank für diese Idee, welche jetzt bei mir weitestgehend auch super läuft.
Solange keine Keymatic im Spiel ist, sondern nur ein Relais (elektr. Türfalle) direkt vom ESP angesteuert wird, könnte die Auswertung doch auch direkt auf dem ESP erfolgen.
Dadurch hätte man vermutlich eine noch schnellere Reaktion!

Kennst sich jemand mit den "Rules" auf dem ESP aus und könnte mir mal so einen Codeschnipsel vorschlagen?

Danke & Gruß
Thomas

zentis666

Zitat von: Papaloewe am 18 Dezember 2017, 10:10:46
Hallo Benni, hallo Leute,

vielen Dank für diese Idee, welche jetzt bei mir weitestgehend auch super läuft.
Solange keine Keymatic im Spiel ist, sondern nur ein Relais (elektr. Türfalle) direkt vom ESP angesteuert wird, könnte die Auswertung doch auch direkt auf dem ESP erfolgen.
Dadurch hätte man vermutlich eine noch schnellere Reaktion!

Kennst sich jemand mit den "Rules" auf dem ESP aus und könnte mir mal so einen Codeschnipsel vorschlagen?

Danke & Gruß
Thomas
Hallo Thomas,

Kennst Du das?
https://www.letscontrolit.com/wiki/index.php/Tutorial_Rules

Gruß
Sven


Gesendet von iPhone mit Tapatalk
--
FHEM auf Debian VM - ESXi 6.0 Intel Nuc i5 4th Gen, Homematic auf HMCCU - RaspberryMatic auf Raspberry PI 3,
EM1000 & FS20 über CUNO,  IT über Arduino Firmata, MiLight über WLAN-nRF Gateway, Ebus, 1Wire, diverse Squeezeboxen, Dreambox 920UHD, Homebridge

Papaloewe

Ah super, damit komme ich klar.
Danke.

zentis666

Hallo,

ich hab zuerst gedacht mein Nachbau von Bennis Lösung funktioniert problemlos,
bin gerade nach Hause gekommen und bin nicht reingekommen :-(

Die Schaltung funktioniert soweit und die Tag-ID wird auch im Event-Monitor brav angezeigt
2017-12-18 17:11:24 ESPEasy ESPEasy_ESP_Door_Haustuer Tag: xxxxxxxx

Ich hab dann in der 99_myutils
sub OpenHaustuer() {
#Öffen Keymatic und
#Statusmeldung per Telegram
fhem('set Keymatic open');
fhem("set telegram message Türöffnung")
}

eingefügt so dass ich eine Nachricht bekomme wenn geöffnet wird.
Wenn es nicht funktioniert wird auch keine Telegram Nachricht geschickt,
anscheinend wird das Notify nicht immer ausgeführt !?

Kurz darauf nochmal probiert und dann ging es wieder... telegram hat mir ne Nachricht geschickt.

Mein notify:
ESPEasy_ESP_Door_Haustuer.Tag.* {\
tagAction($EVTPART1,$NAME);;
}


Woran kann das denn liegen?
Grüsse
Sven
--
FHEM auf Debian VM - ESXi 6.0 Intel Nuc i5 4th Gen, Homematic auf HMCCU - RaspberryMatic auf Raspberry PI 3,
EM1000 & FS20 über CUNO,  IT über Arduino Firmata, MiLight über WLAN-nRF Gateway, Ebus, 1Wire, diverse Squeezeboxen, Dreambox 920UHD, Homebridge

Benni

Zu wenig Information!

Steht denn irgendwas im Log?
Wie sehen die beteiligten (list) Devices aus?

Mit deiner Änderung erfährst du übrigens gar nicht, ob das notify ausgeführt wird, oder nicht, sondern lediglich, ob OpenHaustuer() ausgeführt wird oder nicht.
Wenn du wissen willst, ob das notify ausgeführt wird, solltest du auch aus dem notify heraus loggen, und dort möglichst am Anfang und nicht am Ende, wer weiß was bis dahin schon alles schief gegangen ist ;).

gb#


zentis666

Zitat von: Benni am 18 Dezember 2017, 19:40:48
Zu wenig Information!
gb#

Hi Benni,
hast ja recht ;-)
Im log steht wenns nicht funktioniert:
2017.12.18 18:00:12 3: Source: ESPEasy_ESP_Door_Haustuer - Tag: xxxxxxxx -> valid
2017.12.18 18:00:12 3: Tag-Device: tagSven1.LZF -> Action: OpenHaustuer($tagdev)
2017.12.18 18:00:12 3: Trying to execute action...
2017.12.18 18:00:12 3: Too many arguments for main::OpenHaustuer at (eval 6016) line 1, near "$tagdev)


Ich hab den Fehler gefunden: waren Reste meiner Versuche zur Variablenübergabe,

Grüsse
Sven
--
FHEM auf Debian VM - ESXi 6.0 Intel Nuc i5 4th Gen, Homematic auf HMCCU - RaspberryMatic auf Raspberry PI 3,
EM1000 & FS20 über CUNO,  IT über Arduino Firmata, MiLight über WLAN-nRF Gateway, Ebus, 1Wire, diverse Squeezeboxen, Dreambox 920UHD, Homebridge

Roger79

Hallo Benni,

super Sache und gute Beschreibung.
Ich hänge zur Zeit bei der Auswahl des ESP und der Installation.

Bei dem großen Versandhändler habe ich folgenden gefunden:
https://www.amazon.de/dp/B0754N794H/?coliid=I1RN1BI429CJZE&colid=1GIWI8L6K0ZHG&psc=0
Kann ich diesen verwenden?

Verstehe ich es richtig, dass dieser nicht mit ESPEasy sondern mit NodeMCU. D.h. dieser muss dann noch irgendwie mit ESPEasy geflasht werden.
Hast du hier einen Tipp wie dies am besten gemacht wird?

Wenn der dann gefalsht ist muss dieser noch ins W-LAN integriert werden. Muss dann noch etwas eingerichtet werden, außer in Fhem?

Vielen Dank für die Hilfe.
weazle13

Papaloewe

#57
Du verwechseltst da etwas, aber der Reihe nach.

Es gibt verschiedene Boards mit dem ESP8266 Chip.
Zum einen das NodeMCU und dann verwende ich selber sehr gerne das Wemos D1 Board, welches auch über den Link angeboten wird, aber viel zu teuer ist. Normalpreis ca. 4€, wenn ich mich noch richtig erinnere.

Dann muß darauf eine Software, die sog. Firmware, geladen werden.
Das ist in diesem Fall ESPEasy, welche einmalig auf das Board geflash werden muss.
Danach erfolgt die einmalige Einbindung in dein WLAN, die Konfiguration über die WEB-Oberfläche von ESPEasy und danach erst die Integration ins FHEM, was schon fast automatisch funktioniert.

Viel Erfolg und wir haben alle einmal angefangen, aber am Anfang steht der Fleiß sich einzulesen.

MfG
Thomas

P.S.: Ich sehe gerade der Preis im Link gilt für 3 Stück! Dann relativiert sich meine Aussage oben natürlich.

Roger79

Hallo Thomas,

vielen Dank für die sehr schnelle Antwort. Das hat mir schon mal geholfen.
Dann werde ich mal an das Projekt herantrauen.

Gruß
Roger

Benni

Hallo Roger,

siehtst du, hier gibt's noch mehr hilfsbereite Menschen.  ;)

Ich selbst arbeite auch gerne mit WeMos D1 Mini, bzw. baugleichen Nachbauten, die bekommt man teilweise auch recht günstig in der Bucht, gerne auch mal in 5er oder 10er Packs. Wenn man Zeit hat kann man die natürlich auch direkt in China bestellen.

Zum Thema ESPEasy und Flashen der Software auf das ESP-Board, kannst du bspw. hier mal anfangen zu lesen:

https://www.letscontrolit.com/wiki/index.php/ESPEasy#Get_started


gb#

f-zappa

Moin,
ich plane nun auch einen RFID-Leser an meiner Eingangstür, habe aber noch Sicherheitsbedenken.

Ich habe meine Anforderungen erst mal so definiert:
- robuste, wetterbeständige Außeneinheit mit RFID-Reader, Keypad und integrierter Klingeltaste
- Anschlussleitungen physikalisch von FHEM (bzw anderer Elektronik) entkoppelt
- Direkte Weitergabe gelesener Karten und eingegebener Codes in FHEM (Reader ohne eigene Intelligenz)
- RFID-Medien nicht ohne weiteres kopierbar (zB DESfire o.ä.)
- bezahlbar

Grundsätzlich finde ich den hier beschriebenen Weg Reader->Wiegand->ESP8266->FHEM vernünftig und die Sebury-Reader machen zumindestens auf den Fotos einen ganz guten Eindruck.

Aber wie sieht es mit meiner Forderung nach nicht kopierbaren RFID-Chips aus? Die MIFARE-Geräte von Sebury können zwar auch DESFIRE-Medien lesen, aber ausgewertet doch nur die UID der Karte - und ist auch die schon kryptografisch geschützt oder nur die eigentlichen Dateninhalte, die ja hier eh nicht gelesen werden?  Vielleicht kann mich jemand erleuchten oder hat einen Link zu diesem Thema für mich, ich habe selbst auch nach mehreren Anläufen nichts verständliches dazu gefunden.

Gruß, Uli


Benni

Hallo Uli,

wenn du sowieso eine Leseeinheit mit Keypad UND RFID verwenden möchtest, kannst du ja nach dem "hat-ein" und "kennt-ein" - Prinzip verfahren: Nur wer im Besitz eines gültigen RFID-Tags ist und dazu den passenden Code kennt und eingeben kann, darf rein.
Das ist schon relativ sicher.

Ich nutze bei mir bisher auch nur die Fingerprints. Die werden vom Sebury F2-2 selbst erkannt und zugeordnet (sind also einmalig dort angelernt worden) und m.E. relativ kopiersicher.

Ich sehe das immer noch so: So lange sich die (Haus-) Technik nicht leichter austricksen lässt, als ein Stein mit einer Glasscheibe (oder ein großer Schraubendreher an einem Fenster) funktioniert, wird sich kein normaler Einbrecher die Mühe machen und versuchen die Technik zu überlisten.

gb#

f-zappa

Zitat von: Benni am 11 Mai 2018, 14:03:33
wenn du sowieso eine Leseeinheit mit Keypad UND RFID verwenden möchtest, kannst du ja nach dem "hat-ein" und "kennt-ein" - Prinzip verfahren: Nur wer im Besitz eines gültigen RFID-Tags ist und dazu den passenden Code kennt und eingeben kann, darf rein.

Ich würde aber gern flexibel entscheiden, wann man beides braucht und wann die Karte allein reicht (zB nachts nur mit Code, bestimmte Karten nur mit Code, andere Karten schließen unter bestimmten Bedingungen auch ohne Codeeingabe, ...)

Selbst mit obligatorischem Code würde ich mich aber nicht wohl fühlen, wenn die Zutrittskarte unbemerkt kopiert werden kann.

laserrichi

Zitat von: f-zappa am 11 Mai 2018, 14:23:58
Ich würde aber gern flexibel entscheiden, wann man beides braucht und wann die Karte allein reicht (zB nachts nur mit Code, bestimmte Karten nur mit Code, andere Karten schließen unter bestimmten Bedingungen auch ohne Codeeingabe, ...)

Selbst mit obligatorischem Code würde ich mich aber nicht wohl fühlen, wenn die Zutrittskarte unbemerkt kopiert werden kann.

Hallo, das kannst du ja selbst individuell in FHEM gestalten, mit doif oder notifys. Ich habe einen Sebury Touch Key  mit RFID, über Wigand an einen ESP der mir einfach nur die Nummern in Fhem sendet. PIN ist 4 stellig, und RFID 7stellig
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

HeikoE



Zitat von: f-zappa am 11 Mai 2018, 11:37:28
...
- RFID-Medien nicht ohne weiteres kopierbar (zB DESfire o.ä.)
...

Daran ist mein Wunsch nach so einer Türstation bisher auch gescheitert. Nur die Karten-ID zu verwenden, ist mir ebenfalls zu unsicher. Eine Nutzung der verschlüsselbaren Daten der Mifare-Karten habe ich noch nicht gefunden, und eine eigene Umsetzung scheitert derzeit am Zeitmangel.
Gruß Heiko

benz_freak

#65
Hallo zusammen,
ich plane auch das mit ESPeasy zu bauen mit RFID TAG und Pincode Eingabe. Pincode möchte ich z.B. Licht schalten RFID+ Code Tür öffnen.

Wie macht ihr das mit ein Pincode?
Wenn der Pin/RFID Controller auf Reader only steht wird doch jeder Tastendruck einzeln übertragen oder?
Bei den RFIDs kommt der CODE/TAG ja mit einmal an FHEM an.
Oder hab ich ein Denkfehler?

MFG Benny

laserrichi

Hallo Benny,

bei RFID wird der code gleich übertragen, das stimmt soweit.
Bei der Pin Eingabe wird die ganze Nummer übertragen wenn die # gedrückt wird.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

benz_freak

Hallo laserrichi,
Danke für die schnelle antwort hab gerade alles Bestellt.

Hat jemand schon Code + RFID in FHEM umgesetzt für die Freigabe der Tür oder habt ihr alle den Fingerprint im Einsatz.

MFG Benny

benz_freak

Mahlzeit zusammen,
Hardware ist gestern gekommen also schnell den Löter raus und testen.
Die Hardware funktioniert soweit glaube ich. Habe aber mit der ESPeasy Version Probleme.
Habe gestern 3 Verschiedene ausprobiert bei einer Läuft das mit den RFID aber keine Code Eingabe möglich. Bei einer anderen Version geht kein RFID aber Code Eingabe allerdings wird nicht der Code übertragen den ich eingebe. Bei der 3 ging garnichts oder es war schon zu spät für mich.

Welcher Version benutzt ihr und hat jemand eine Tipp für mich was es sein könnte.

Dankeschön

MFG Benny

f-zappa

Zitat von: benz_freak am 17 Juli 2018, 12:11:20
Hardware ist gestern gekommen also schnell den Löter raus und testen.
Hi Benny, ich kann zwar leider nichts zur Problemlösung beitragen, aber mich würde mal interessieren, für was für einen Leser du dich entschieden hast.
Gruß, Uli

benz_freak

Hallo Uli,
hier mal die Auflistung der Hardware:

Codeschloss aus der Bucht 60 € (siehe Anhang)
D1 MINI - ESP8266 ESP12 NodeMcu 6 €
I2C 5V-3.3V 4 Kanal Level Shifter Konverter Pegelwandler Arduino 1 €
Original Wemos 7-24V 1A DC Power Shield 4,50 €
Kleinteile: Draht, Platine, Leiterplatten-Anschlussklemmen, Netzteil 12V

f-zappa

Zitat von: benz_freak am 17 Juli 2018, 13:14:45
Codeschloss aus der Bucht 60 € (siehe Anhang)
Interessantes Teil, und der Hersteller hat auch welche mit eingebautem Klingelknopf (AC60-ID finde ich hübsch). Aber was für Anschlüsse hat das Ding hinten und kann man mit der Dokumentation was anfangen?

tpm88

Zitat von: benz_freak am 09 Juli 2018, 14:21:29
Hat jemand schon Code + RFID in FHEM umgesetzt für die Freigabe der Tür oder habt ihr alle den Fingerprint im Einsatz.

Ich habe einen I-Keys Reader ( Code und RFID ) im Einsatz. Die Kopplung an FHEM habe ich via USB mit diesem Modul realisert: https://www.i-keys.de/de/Zutrittskontrollsysteme/Zubehoer/Wiegand-Modul-USB-Converter.html
Relativ teuer - dafür unabhängig von WLAN.

Damit kann ich sowohl die RFID Tags als auch Codes ( Tastendrücke ) via ECMD in FHEM auslesen. Da sich die RFID Tags bekanntlich relativ leicht kopieren lassen, setze ich für die Türöffnung auf eine Kombination aus RFID und Tastaturcode.
Test FHEM Server on RPi, CUL_HM
Prod FHEM Server on Odroid HC1, HM-USB, JeeLink
Devices: diverse HM, IT1500, 1wire, LaCrosse, MQTT

Cybers

Zitat von: benz_freak am 17 Juli 2018, 13:14:45
Hallo Uli,
hier mal die Auflistung der Hardware:

Codeschloss aus der Bucht 60 € (siehe Anhang)
D1 MINI - ESP8266 ESP12 NodeMcu 6 €
I2C 5V-3.3V 4 Kanal Level Shifter Konverter Pegelwandler Arduino 1 €
Original Wemos 7-24V 1A DC Power Shield 4,50 €
Kleinteile: Draht, Platine, Leiterplatten-Anschlussklemmen, Netzteil 12V

Dieses Codeschloss habe ich mir auch geholt. Allerdings bekomme ich sowohl in Fhem als auch in EspEasy falsche Werte angezeigt. wenn ich im Codeschloss 56 eingeben bekomme ich z.B. 88 angezeigt. Da scheint was mit der Auswertung nicht zu stimmen. Grundsätzlich habe ich den gleichen Aufbau wie du. Welche EspEasy-Version nutzt du, bzw. was hast du wo eingestellt. Ich habe sowohl Wiegand 26 als auch 34 versucht. Die RFID-Tags werden auch nicht übertragen.
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

benz_freak

Zitat von: Cybers am 17 Juli 2018, 21:22:10
Dieses Codeschloss habe ich mir auch geholt. Allerdings bekomme ich sowohl in Fhem als auch in EspEasy falsche Werte angezeigt. wenn ich im Codeschloss 56 eingeben bekomme ich z.B. 88 angezeigt. Da scheint was mit der Auswertung nicht zu stimmen. Grundsätzlich habe ich den gleichen Aufbau wie du. Welche EspEasy-Version nutzt du, bzw. was hast du wo eingestellt. Ich habe sowohl Wiegand 26 als auch 34 versucht. Die RFID-Tags werden auch nicht übertragen.
Gruß, Sascha

Hi Sascha,
Danke für die Info so ist es bei mir auch. Mit einer alten ESPeasy Version geht RFID aber ob die Richtig übertragen werden bezweifel ich. Verdrahtung ist also Okay. Jetzt müssen wir uns noch um die Software kümmern da scheint ja der Bug zu sein.
Werde aber erst nächste Woche mich damit beschäftigen können.
MfG Benny

laserrichi

#75
Also ich habe bei mir die Sebury im Einsatz, daher kann ich vermutlich nicht viel beitragen.

Benutze aktuell GIT version: v2.0-20180306

Ich verwende 26bit  und als 1st Gpio  GPIO-2  und als 2nd Gpio  GPIO-0
kann mich dunkel erinnern das hier 1 und 2 verdreht war, und deswegen auch solch seltsame Effekte hatte. (Zahlen ewig lang)
Wichtig ist das auch am Reader der Code 26 oder 34 gesetzt wird. Und nehmt mal 26, das geht zumindest bei mir :-)

RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Cybers

In EspEasy kann ich bei meiner Version nicht einstellen ob ich den 26- oder 34-Bitmode nutzen möchte. Das Codeschloss selber habe ich schon in beiden Modi versucht.
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

laserrichi

@ Sascha welche Version nutzt du ? Klingt nach R120 oder R147... 
Dann solltest du mal auf die Mega  gehen, auch wenns hier noch experimental steht, die läuft schon bei mir stabil mit Wiegand, 1wire, und anderen dingen.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

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

laserrichi

lol... murphys Gesetz, habe sie bei mir ausprobiert, und tatsächlich ist wohl durch die designänderung ein Fehler drin.

bekomme eine Fehlermeldung genau an der Stelle wo normal die Auswahl ist: Bug in PLUGIN_WEBFORM_LOAD, should not append to string, use addHtml() instead

nimm mal eine ältere Version, wo das Design noch nicht geändert wurde, aus April oder so.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Cybers

Den Fehler habe ich gelesen, konnte ihn jedoch nicht zuordnen, da ich nicht wußte was nicht angezeigt wird. Da ich zur Zeit im Urlaub bin, kann ich gerade nichts testen. Probiere aber mal dir Firmware per VPN und IPad zu ändern. Danke schon mal für den Ansatz...
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

Cybers

#81
ich hatte letzte Woche einen Issue auf Git eröffnet, und auf heutige Nachfrage wurde der Bug dann heute gefixed:
Hier der Link zur geänderten _P008_RFID.ino von EspEasy: https://github.com/letscontrolit/ESPEasy/blob/ddad026a2b238abe7252721966738e27d13c7450/src/_P008_RFID.ino
Vielleicht kann es mit der Version einer testen. Ich komme aus dem Urlaub aktuell nicht auf mein System um es aufspielen zu können.
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

Cybers

Mit der EspEasy-Version vom 15.08.2018 läuft das Wiegand-Device ohne Fehlermeldung und man kann zwischen 26 und 34 Bits wählen.
Die Übertragung der Transponder-ID klappt auch ohne Probleme, allerdings werden die Eingaben des Keypads falsch übermittelt: aus 1801 wird 6145, aus 2412 wird 9234 - das kann aber nicht am Wiegand-Modul von EspEasy liegen, da die Tag-IDs ja richtig übertragen werden. Das ganze ist jetzt nur bedingt schlimm, da man ja die "falschen Zahlen" für den Code-Abgleich in Fhem eintragen kann. Den "richtigen Zahlencode" kann man in ein weiteres Reading stecken, um ihn nicht zu vergessen.
Werden denn bei denen, die ein anderes Keypad nutzen, die richtigen Zahlen übertragen?
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

laserrichi

also mit dem Sebury kommen die Codes richtig an.
Als ich solch falsche Zahlen hatte, waren die Datenleitungen bei mir verdreht. Aber wenn die Codes für die RFID richtig ankommen kann man das eigentlich ausschließen.
Ich verwende mega-20180405  mit dem core 2_3_0, und die läuft.
RaspberryPi 4 Bullseye,Homematic,Z-Wave,Rademacher Duofern,Signalduino,Fritz7590,ESPEasy,Tasmota,Robonect,Kameras,1-Wire,Modbus,Solar,Maranz,VU+,ulanzi tc001 mit awtrix light

Cybers

so, nach vielem Lesen und recherchieren: Die Eingabe in das Keypad erfolgt scheinbar in HEX, die Übertragung über Wiegand zu EspEasy und Fhem erfolgt aber dann Dezimal. Wenn ich die übertragene Zahl dann wieder von Dezimal nach Hex umrechne, dann bekomme ich wieder meinen eingegeben Code.
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

ChrisW

okay ist nun schon was älter hier aber gibt es nun eine einfache möglichkeit ein Wiegand in FHEM zu bekommen ? Möchte mit den Sensor F6-3 zulegen: https://www.i-keys.de/de/Zutrittskontrollsysteme/Stand-Alone-Geraete/Fingerprint/F6-3.html

Da steht Wiegand 26bit Datenausgang für Türcontroller.
Somit müsste ich das doch irgendwie in FHEM bekomen um das  Auszuweiter / weiter zu verwerten.

Danke
Raspberry PI3 mit allem möglichen.

Papaloewe

Das kannst du einfach mit ESPeasy anbinden.
Gab es schon mal hier im Forum, einfach mal suchen. ;-)

f-zappa

Hat eigentlich inzwischen jemand was neues bzgl. DESfire oder anderen Verschlüsselungsmöglichkeiten herausgefunden?

ChrisW

#88
Zitat von: Papaloewe am 07 Mai 2019, 11:18:49
Das kannst du einfach mit ESPeasy anbinden.
Gab es schon mal hier im Forum, einfach mal suchen. ;-)

Vielen Dank für die Info. Das schaut ja wirklich Reiswert aus diese Lösung. Aber zu ESPeasy findet man ja echt viel. Hast du zufällig einen genaueren Link wie das mit Wiegand damit funktioniert. Hatte mit solch einem Teil noch nichts zu tun bisher ;) ESPeasy soll ja nur eine GUI sein?!

Ah doch noch selbst etwas gutes gefunden : https://forum.fhem.de/index.php/topic,41124.msg647383.html#msg647383
Raspberry PI3 mit allem möglichen.


Cybers

Zitat von: ChrisW am 07 Mai 2019, 12:19:13
Ah doch noch selbst etwas gutes gefunden : https://forum.fhem.de/index.php/topic,41124.msg647383.html#msg647383

Ich habe es so aufgebaut und es läuft bei mir seit etwa einem 3/4 Jahr problemlos. Mit EspEasy gibt es keine Probleme. Einzig diese HEX/Dezimal-Geschichte hat mich einiges an Nerven gekostet.

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

ChrisW

Hm der link pidoorman geht nicht mehr. Hab mein wiegand terminal nun. Was muss ich beachten wenn ich den an mein esp mit espeasy anschließen will? An welchen Pins muss was? Bzw. Terminal und esp sind separat mit Strom versorgt
Raspberry PI3 mit allem möglichen.

ChrisW

hm auch damit geht es nicht .. signal vom fingerprint kommt damit gehe ich
grün HV2 und weiss HV1 auf der anderen seite gehe ich grün LV2 und weiss lv 1

3,3 schließe ich an LV GND von 3,3 auf GND
5v mache ich auf HV und das GND auf GND

Dann gehe ich im D1 auf d6 mit grün und d7 mit weiss auch unter easyesp so eingestellt.
Habe auch schon grün D3 und weiss d4 versucht. Aber da ist ein Ausrufezeichen hinter. D4 hat auch etwas mit der LED wohl zu tun.

Leider geht es nicht hab nun wie auch immer mal Tag: 5614253
da stehen. Ändert sich aber nicht

weiss nicht mehr weiter vll wirklich esp kaputt werde wohl mal nen 2. testen müssen
Raspberry PI3 mit allem möglichen.

ChrisW

Also Update .. es klappt nicht auch mit dem anderen Gerät es kommt wohl nichts an. Ab und zu sehe ich im Log ein reset byte mit einer zahl 2-9...
Wie kann ich mir anzeigen lassen ob an den Pinnen überhaupt was ankommt. Multimeter erfasst das nicht zu kurz
Raspberry PI3 mit allem möglichen.

Brockmann

Zitat von: ChrisW am 19 Mai 2019, 08:12:58
Bzw. Terminal und esp sind separat mit Strom versorgt
Nach meinem Verständnis müssen Terminal und ESP ein gemeinsames GND haben?
Bin da aber auch überwiegend Laie. Ich habe mich bei meiner Umsetzung nach dem Schema hier gerichtet:
https://forum.fhem.de/index.php/topic,41124.msg647383.html#msg647383

ChrisW

hmm bin für anregungen immer offen. Hatte gedacht das wäre egal. Nur wie soll ich das Realisieren ?
Ich habe einmal ESP = USB Power
Levelshifter = Netzteil was 3 V rechts und 5v Links ausgibt
Und dann noch das 12v vom Fingerprint.

Also wird das GND dann Vom 12v netzteil genommen ? Außer am ESP wird schwer oder rkann ich da GND noch zusätzlich mit dranmachen am GND Punkt ?
Raspberry PI3 mit allem möglichen.

Cybers

alle GND-Anschlüsse müssen an einem Punkt zusammengefasst werden.

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

ChrisW

Klappt alle gemeinsame GND und D3 und D4 musste ich nehmen. Die anderen pinne gingen nicht
Danke
Raspberry PI3 mit allem möglichen.