[OpenKNX-Ready] Zutrittskontrolle mit Fingerprint / Fingerabdruck

[Mabalero]

Diejenigen, die Probleme mit der Erkennung des Auflegens des Fingers haben, habt ihr die R503 bei Andreas gekauft?

Habe mir auch einen schwarzen FP mitbestellt, diesen aber wieder ausgebaut und einen andere R503 (welcher problemlos lief und ich für das DIY FrickelzeugsDoorbell Projekt gebraucht habe) eingebaut. Seitdem keine Probleme.

Vielleicht gibt es ja eine Fehlerhafte Charge o.Ä.

Mit freundlichen Grüßen

[traxanos]

noch eine Bitte: Kann eine "Totzeit" implementiert werden

Ich denke das ist ein Nebeneffekt von der fortlaufenden Auswertung. Vorher gabs es ein Touchevent das die Verarbeitung genau 1mal ermöglicht hatte. Wenn man aber eine Totzeit einbaut, sollte die FingerID mit beachten. Ich legen gerne 2 finger direkt hintereinder auf. Grage öffnen + Haustüre. Da wäre eine Totzeit von 3s mies wenn die FingerID nicht beachtet würde

[traxanos]

edit: ist der Wert "aus" für "drücken" und "ein" für "loslassen" des Buttons (Rohdaten) so gewollt? Hätte ich andersrum erwartet...

kann der touchsensor überhaupt zwischen drücken und loslassen unterscheiden? ich vermute nicht kann es aber nicht testen weil meine hw gerade nicht funktioniert.

Ich denke das daher auch der virtuellbutton nicht geht. es benötigt zuverlässig Press(EIN) und Release(AUS) Events. Wenn du nur Umschalten möchtest, ist der VirtualButton auch oversized Das macht man am besten direkt mit dem Logikmodul. Dann ist auch egal ob ein EIN oder AUS kommt.

[TabSel]

stimmt

[mumpf]

Das macht keinen Sinn, das ist alles schon in der Logik drin und kann seit Jahren genutzt werden.

Gruß, Waldemar

[TabSel]

...Wir werden in zukünftigen Versionen ermöglichen, in Common ganze Module auszublenden, damit die, die man nicht braucht, auch keinen Platz im UI "verschwenden". Da das aber die Infrastruktur (also alle Module) beeinflusst, wird das erst was, wenn wir den nächsten "größeren" Wurf machen....

vielleicht überlegt Ihr aber auch diese Teile/Kanäle schlicht zu "virtualisieren"? Also "virtuelle Schaltkanäle", "virtuelle Binäreingänge", und die Ein-/Ausgänge via "KO" oder "Hardware" abzubilden? Wenn Ihr dann den virtuellen Schaltkanal mit ausgefuchsten Features erweitert, z.B. Treppenhauslichtfunktion", dann könnten z.B. Uralt-Schaltaktoren auch einfach "upgedated" werden...

Nur eine Idee....

[mumpf]

Kann eine "Totzeit" implementiert werden nach erfolgreicher Ausführung/Authorisierung einer Aktion bei fortlaufender Erkennung?

Gutes Feedback, bisher ist mir das nicht aufgefallen, aber ich hab auch dieses Szenario noch nicht gehabt.
Workaround: Hinter die Aktion einen Logikkanal hängen, mit einem Treppenlicht 3 Sekunden, bei erneutem EIN Treppenlichtzeit verlängern.

Gruß, Waldemar

[mumpf]

Hi,

Ich hätte erwartet dass sowohl die Rohdaten wie auch der Virtual Button senden...

Ich auch. Ich hatte das auch in meinem Test gesehen, ich schau mir das nochmal an. Workaround: Du machst beim Taster "Externes KO" und verbindest die Rohdaten-GA mit dem externen KO des Tasters.

ist der Wert "aus" für "drücken" und "ein" für "loslassen" des Buttons (Rohdaten) so gewollt? Hätte ich andersrum erwartet...

Da müssen wir traxanos fragen, das Taster-Modul hat er gemacht .

ich habe keine Relais-Zusatzplatine, allerdings hab ich die Kanäle "Schaltaktor" und "Binäreingänge".

Wir machen nicht für jede mögliche Hardwarekombi eine eigene Applikation. Da es DIY ist, weiß der User, was für Hardware er hat (wie Du ja auch) und ich unterstelle mal die geistige Reife, dann zu erkennen, dass man dann diese Applikationsteile nicht nutzen kann .

Ist das so gewollt?

Ja

Kann ich (und wofür) diese Kanäle nutzen ohne die Zusatzplatine?

Nein.

Wir werden in zukünftigen Versionen ermöglichen, in Common ganze Module auszublenden, damit die, die man nicht braucht, auch keinen Platz im UI "verschwenden". Da das aber die Infrastruktur (also alle Module) beeinflusst, wird das erst was, wenn wir den nächsten "größeren" Wurf machen.

Gruß, Waldemar

[TabSel]

noch eine Bitte: Kann eine "Totzeit" implementiert werden nach erfolgreicher Ausführung/Authorisierung einer Aktion bei fortlaufender Erkennung?

Grund:
Ein Scan/Aktion dauert in der Regel unter einer Sekunde (super!).
Wenn der Finger also ein bisschen länger auf dem Scanner liegt kann die Aktion schon auch mal ZWEI mal ausgeführt werden, was zu unerwünschtem Verhalten führen kann. Wenn eine Totzeit von 3 Sekunden parametrisiert werden könnte, in der der Scanner "tot" ist (also kein LED-Feedback, keine Aktionen senden), dann bleibt genug Zeit für die Geste ohne große Aufmerksamkeit auf den Scanner.

Ich gucke z.B. nicht auf das LED-Feedback des Scanners, sondern gucke auf das Rollo, weil ich auf das Auffahren warte während mein Finger aufliegt. Oft stoppt der Rollo gleich nach dem Verfahren wieder, weil die Aktion ein zweites mal ausgeführt wird (MDT SingleObjectControl).

Bei Scan "Bei Berührung" hab ich das Problem nicht, allerdings hab ich dann das bekannte Problem dass die Berührung oft nicht erkannt wird, weil ich halt oft auch Barfuß unterwegs bin *g*)

[TabSel]

[BUG] Virtual Button

Ich habe den Fingerprint mit LED/Touch Buttons. Ich benutze die Rohdaten der linken Taste (KO71), so wie einen Virtual Button dessen Eingang die linke Taste ist (KO1018):
image.png
image.png
Wenn ich auf den Button drücke werden die Rohdaten gesendet, nicht aber der Ausgang des Virtual Buttons:
image.png
Mache ich etwas falsch? Ich hätte erwartet dass sowohl die Rohdaten wie auch der Virtual Button senden...

edit: ist der Wert "aus" für "drücken" und "ein" für "loslassen" des Buttons (Rohdaten) so gewollt? Hätte ich andersrum erwartet...

edit2: ich habe keine Relais-Zusatzplatine, allerdings hab ich die Kanäle "Schaltaktor" und "Binäreingänge". Ist das so gewollt? Kann ich (und wofür) diese Kanäle nutzen ohne die Zusatzplatine?
Danke
Tab

[mumpf]

Mit der Relaisplatine kann ich doch solch einen elektrischen Türöffner schalten richtig? (So wäre zumindest mein Plan)
Kriegt die Platine dann Dauerspannung von einem externen 12V Netzteil und schaltet die dann durch?

Denn dann bräuchte ich ja entweder ein kleines UP Netzteil oder eine Versorgung aus der Verteilung. Dann würde ich das UP NT ggf direkt über einen Aktor der UV schalten damit das nicht dauerhaft am Strom hängt und bräuchte die Platine nicht?

Du hast hier unbewusst die Vorteile zusammengefasst, die ein FP direkt am KNX-Bus realisiert:

• Du kannst lokal über die Relaisplatine schalten und alles in der nähe der Tür machen
• Du kannst den FP aber auch einen ganz anderen Aktor schalten lassen, der ganz woanders verbaut ist, und entsprechend agieren

Abstrakt betrachtet wird das lokale Relais nämlich genau so über ein KO geschaltet wie auch ein externer Aktor. Man verknüpft einfach KOs über eine GA und schon klappt das.

Und für alle, die hier kritisch sind, weil wir noch kein Secure haben, kommt noch ein kleiner Vorteil, den das lokale Relais hat: Mit einem simplen Logikkanal kann man die Aktion vom FP mit dem lokalen Relais-KO verknüpfen, ohne GAs zu brauchen, also komplett ohne Buskommunikation. So kann man verhindern, dass das Relais von außen (also über den Bus) geschaltet werden kann.

Den Logikkanal könnt ihr folgendermaßen definieren (über Konfigurationstransfer):

OpenKNX,cv1,*:0x50/LOG:0x33/1§f~Name=Relais%20intern%20schalten§f~Kommentar=Schaltet%20das%20interne%20Relais%0A%20%20-%20es%20ist%20keine%20GA-Verkn%C3%BCpfung%20n%C3%B6tig%0A%20%20-%20es%20ist%20als%20ob%20es%20intern%20verdrahtet%20w%C3%A4re§f~Logic=2§f~NameInput1=Aktion%2C%20die%20das%20Relais%20schalten%20soll§f~E1=1§f~E1UseOtherKO=1§f~E1OtherKO:2=536§f~NameOutput=Schaltet%20internes%20Relais%20direkt§f~OOnKOSend=1§f~OOnKOSendNumber=91§f~OOffKOSend=1§f~OOffKOSendNumber=91§>Import: [OK]§>§>Eingang1->Bestehendes KO: §>   Hier die KO-Nr der Aktion eintragen, die schalten soll§>Es sind keine GA-Verknüpfungen nötig§;OpenKNX
​

Standardmäßig wird hier auf Kanal 1 importiert, ihr könnt aber auch einen anderen Logikkanal wählen. Bei Eingang1->Bestehendes KO" müsst ihr die KO-Nr vom Ausgang der Aktion eintragen, die schalten soll. Es sind keine GA-Verknüpfungen nötig.

Gruß, Waldemar

P.S.: Als Teaser: Ich habe schon erfolgreich eine FP-Firmware gebaut, die über eine Secure-GA kommunizieren konnte. Aber der Weg bis zu einer produktiven Firmware ist hier noch seeeehr lang! Ich wollte nur sagen, ich bin dran.

[henfri]

Naja, die 1500 Finger wollen auch erstmal eingelernt werden...
Ich denke, da geht die Lust eher aus.
Aber ich denke, es macht auch mehr Sinn mehrere Aktionen zu definieren und diese sperren zu können.
Im zweiten Schritt kann man jeder Aktion dann Finger zuordnen.

[kleinklausi]

Ist das für dich "dringend"?

Ist ja immer relativ. Ich hätte es gerne aus dem Kopf und voll produktiv - also nein, nicht wirklich dringend :-)

[mumpf]

Idee: Aktionen sperren

Natürlich, das ist naheliegend. Wir haben aber vor, sehr viele Aktionen zu erlauben (der R503Pro erlaubt 1500 Finger). da wird plötzlich jedes KO wertvoll. Und eine Sperre pro Aktion würde ein KO erfordern. Da werden wir noch Pro und Contra abwägen.

Bis dahin kann man ohne Probleme Aktionen dadurch sperren, dass man hinter die Aktion ein Logikkanal als TOR hängt und so eine Sperre realisiert.

Gruß, Waldemar

[abtools]

Hallo Moritz,

habe ich grad gemacht :-) Während der Sperre bleibt der LED Ring allerdings rot. abtools Andreas, die Sperre (roter LED Ring) scheint die LED Ring Steuerung über Objekt 37 nicht zu funktionieren.

Ich fürchte, da hast du Recht:
Aktuell sperrt die Sperre auch alle Aktionen von außerhalb; eigentlich wird im gesperrten Zustand gerade nur der "Sync" noch erlaubt, sonst allerdings nichts.

Im Prinzip sehe ich jetzt aber keinen Grund, warum man die externe Farbkontrolle nicht auch bei Sperre noch erlauben sollte - das kann ich also gerne entsprechend abändern.

Ist das für dich "dringend"? Dann könnte ich dafür nochmal zeitnah (heute oder morgen) ein kleines Firmware-Update nach schieben.
Ansonsten würde ich es einfach auf die ToDo-Liste für das nächste Update packen.

Viele Grüße
Andreas