[OpenKNX-Ready] Zutrittskontrolle mit Fingerprint / Fingerabdruck

[abtools]

Guten Abend zusammen,

nach einer freundlichen Meldung eines Bugs durch bambam haben wir soeben Firmware-Version 0.10 als Hotfix-Release veröffentlicht:
https://github.com/OpenKNX/OAM-AccessControl/releases

Grundsätzlich bezieht sich der gemeldete Fehler lediglich auf die Touch-Frontplatine ohne NFC, aber wir empfehlen diese neue Firmware-Version zumindest für alle neuen Installationen zu verwenden.

Selbstverständlich ist diese auch für bestehenden Installationen in der ETS ohne komplette Neuparametrisierung update-fähig.

Installation der neuen Firmware und Bau der neuen KNXprod wie immer am einfachsten mit der OpenKNX Toolbox.

Und bei Fragen natürlich gerne jederzeit hier im Forum oder direkt bei mir per E-Mail melden. :-)

Währenddessen arbeiten wir weiterhin an der bereits erwähnten Keypad-Unterstützung mit einem größeren Feature-Update.

Viele Grüße
Andreas

[bambam]

Sorry, ich nochmal... ist aber der letzte Post für heute!

Hallo André,

Wäre auch meine Erwartung und teste ich bei nächster Gelegenheit.

Andreas, wenn du dann gerade dabei bist, könntest du bitte noch folgendes prüfen? Wenn ich mehr als 6 Finger(ID >5) anlerne, dann bekomme ich immer einen Fehler wenn ich die ID's mit Finger-ID suchen zurück lesen will. Der Finger ist aber angelernt und der FP Sensor signalisiert auch, dass er den Finger mit der ID kennt und gibt die 6 auf dem KO 41 zurück.

Ich kann nach dem Anlernen auch in der Applikation den Namen für ID 6 ändern, aber beim Zurücklesen bekomme ich immer den Fehler "Gerät antwortet nicht".
Erst wenn ich in der ETS ID 6 lösche, funktioniert es wieder(wie im Screenshot zu sehen ist). Ich habe auch schon mal alle Finger gelöscht und neu angelernt. Es kam aber immer die selbe Fehlermeldung ab bei ID >5.

Ich bin ja bestimmt nicht der erste, der mehr als 6 Finger anlernen möchte? Vermutlich hängt das mit einer bestimmten Parameter Kombination bei mir zusammen.
Daher schicke ich dir auch mal meine Export-Strings per Mail.

P.S. ich hab das jetzt nur mit der 0.9 getestet.



Screenshot 2025-09-18 232109.png

[Seehaeusle]

Guten Tag zusammen,

Ich lesen schon länger mit. Jetzt läuft unsere Sanierunf aktuell und ich würde gerne mehrere Fingerprints verbauen. Dabei einen an der Haustür neben einer Doorbird. Ich würde dabei gerne die Tür direkt an den FP über das Relais (ohne Schaltaktor) schliessen und zugleich die Tür über die Doorbird öffnen lassen, sodass ich die Tür auch in Kombination mit einer Innenstation bzw über die App öffnen kann. Ist das möglich bzw muss das Relais vom FP dann an die Doorbird und diese dann an das Schloss?

[mumpf]

Hier muss Andreas nichts testen. Das ist so... Habt von deiner APDU ab. Ich bin aber unterwegs und kann das erst heute Abend erklären.

Gruß, Waldemar

[abtools]

Hallo zusammen,

offenbar lebt das Forum nun endlich wieder. :-)

Die Antwort von mumpf bezog sich wohl eher auf einen Betrag weiter oben.
Da überlasse ich dann gerne auch Waldemar noch die weitere Erklärung dazu, die er gestern Abend aufgrund ausgefallenen Forums vermutlich nicht mehr liefern konnte.

In der Zwischenzeit hierzu:

Ich lesen schon länger mit. Jetzt läuft unsere Sanierunf aktuell und ich würde gerne mehrere Fingerprints verbauen. Dabei einen an der Haustür neben einer Doorbird. Ich würde dabei gerne die Tür direkt an den FP über das Relais (ohne Schaltaktor) schliessen und zugleich die Tür über die Doorbird öffnen lassen, sodass ich die Tür auch in Kombination mit einer Innenstation bzw über die App öffnen kann. Ist das möglich bzw muss das Relais vom FP dann an die Doorbird und diese dann an das Schloss?

Ehrlich gesagt kenne ich Doorbird selbst nicht und kann daher auch nur wenig dazu sagen.

Du kannst beim Fingerprint auf jeden Fall die optionale Binäreingangs-/Relais-Platine mitbestellen und hast dann "lokal" (direkt auch beim Fingerprint) einen Relais-Ausgang und 4 Binäreingänge zur freien Verfügung.

Aber ob/wie du diese mit Doorbird "koppeln" kannst, kann ich dir nicht sagen - ggf. haben andere dazu bereits Erfahrung.

Viele Grüße
Andreas

[abtools]

Hallo André,

das habe ich nun auch getestet:

Ich hab mal eine Frage zum KO 24: Scan - Zutrittsdaten. Wird das von euch überhaupt verwendet? Ich bekomme nämlich nach einem Scan immer "00 00 00 00"
Ich hätte da jetzt erwartet, dass ich aus dem Ergebnis sowas wie ID3 gültig o.ä. bekomme. Dafür gibt es aber auch die KO's 40+41.

Screenshot 2025-09-18 221323.png

Zunächst einmal muss ich sagen, dass alles, was ich auf deinem Screenshot sehe, korrekt aussieht:
Bei "Permission=False" wurde offenbar kein gültiger (= zuvor angelernter) Finger erkannt und somit kann logischerweise auch keine ID ausgegeben werden - ist ja schließlich kein bekannter Finger.

Dennoch ist mir beim Testen aufgefallen, dass die Zutrittsdaten mit Firmware 0.10 tatsächlich nicht auf das KO ausgegeben werden - das habe ich soeben mit Version 0.10.1 gefixed. Diese bekommst du wie immer auf GitHub oder über die OpenKNX Toolbox.

Bitte teste es doch nochmals mit Firmware-Version 0.10.1.
Wenn du dann auch einen bekannten Finger verwendest, solltest du entsprechende Zutrittsdaten auf KO 24 ausgegeben sehen.

Viele Grüße
Andreas

[mumpf]

Andreas, wenn du dann gerade dabei bist, könntest du bitte noch folgendes prüfen?

Hi André,
was da passiert, ist kein Fehler - zumindest nicht von uns:-) Das hat was mit der ETS-Kommunikation zu tun und ist ein sehr kompliziertes Thema.
Bei den Telegrammlängen, die zur Verfügung stehen (theoretisch 254 Byte, wir nutzen nur 240) bekomme ich ein Suchergebnis von 7 Fingern hin. Wenn mehr Finger auf dem Gerät gespeichert sind, werden die ersten 7 gefundenen Finger dargestellt und es kommt ein Hinweis, dass mehr da sind und man die Filterkriterien weiter einengen muss.
Was bei Dir passiert, ist leider eine Lücke in der ETS (ich will nicht Bug sagen), die wir so nicht erwartet hatten. Ich muss weiter ausholen:
Die Telegrammlängen sind nicht konstant. Jedes IP-Interface, jeder Router, jeder LK - die können alle unterschiedliche Telegrammlängen. Manche werben dafür, dass sie jetzt Secure-fähig sind, manche sprechen von Long Frames, aber alle machen "irgendwas" <=254. Der Begriff ist APDU.
Wenn die ETS ein Gerät programmieren will, dann geht das grob gesagt folgendermaßen (Gerät hat die PA 2.3.4, ETS hat den Tunnel 1.1.250 von der Schnittstelle 1.1.5):

• ETS Fragt die Schnittstelle 1.1.5 (die stellt den Tunnel 1.1.250 bereit) nach der APDU, bekommt z.B. 220 zurück, das ist die bisher ermittelte APDU
• Um zu 2.3.4 zu kommen, muss sie jetzt den LK 1.1.0 nach der APDU fragen => 254, neue APDU ist MIN(254, 220) = 220
• Das nächste Gerät auf dem Weg zu 2.3.4 ist z.B. der Router 1.0.0, dessen APDU ist 160, neue APDU ist MIN(160, 220) = 160
• Das nächste Gerät auf dem Weg zu 2.3.4 ist z.B. der Router 2.0.0, dessen APDU ist 160, neue APDU ist MIN(160, 160) = 160
• Das nächste Gerät auf dem Weg zu 2.3.4 ist z.B. der LK 2.3.0, dessen APDU ist 213, neue APDU ist MIN(213, 160) = 160
• Jetzt wird noch das Gerät 2.3.4 nach seiner APDU gefragt, ist 63, die sich ergebende APDU ist dann MIN(63, 160) = 63.

Jetzt weiß die ETS, dass sie zum programmieren nur Telegramme der Maximallänge 63 nutzen darf. Und das tut sie auch. Alle längeren Pakete werden in 63 Byte-Päckchen geteilt und so die Kommunikation garantiert (Das Beispiel zeigt übrigens auch, warum Topologie so wichtig ist, bei falscher Topologie könnte nämlich eine falsche APDU ermittelt werden und dann geht gar nichts).

Warum erzähle ich das alles? Weil wir im Log der ETS gesehen haben, dass sie genau diese Ermittlung auch für die Kommunikation bei JavaScript macht und wir davon ausgingen, dass damit auch die Paketierung vorgenommen wird --> das ist aber leider nicht der Fall. Und noch schlimmer: Wir bekommen in JavaScript keine Information darüber, welche APDU zur Verfügung steht. Das selber zu ermitteln geht von JS aus nicht bzw. nur als große Krücke. Und natürlich findet man so was erst raus, nachdem es fertig implementiert und rausgerollt ist, denn wir haben alle Geräte mit großer APDU > 240 Byte.

Alle Schritte oben selber zu machen ist ein irrer Aufwand - trotzdem sprechen wir darüber, ob und wie wir das hinbekommen können. Das blöde ist, dass man noch nicht mal eine Fehlermeldung im JavaScript bekommt, wenn die APDU nicht stimmt, die ETS bricht einfach ab (wie bei Dir).

Was bleibt Dir übrig? Du musst - wenn so ein Fehler kommt - die Suchanfrage stärker einschränken, dass max. 6 Einträge zurückkommen. Ich bekomme einfach keine (programmatische) Kontrolle mehr, wenn die APDU überschritten wird, ich kann hier nichts machen.
Die einzige andere Möglichkeit, die ich sehe, ist die Suchfunktion wieder auszubauen. Aber da ich die selber sehr gerne nutze, will ich das nicht. Und wenn wir es wirklich schaffen, die Paketierung selber zu machen, werden wir natürlich umstellen.

Gruß, Waldemar

[bambam]

Hallo Waldemar, ich komme seit gestern mobil nicht mehr in Forum rein, daher kann ich erst jetzt antworten.

Vielen Dank für deine ausführliche Erklärung des Ablaufs und der Problematik mit dem APDU. Ich denke, dass ich das auch halbwegs verstanden habe, aber das wirst du ja gleich an meinen Fragen dazu merken

Da die Abfrage der ID's bei mir nur mit 6 Fingern funktioniert, habe ich eine APDU von <240, was die ETS aber scheinbar nicht korrekt ermittelt. Meine Topo hier im Testaufbau ist dabei recht simpel, da nur eine Linie mit USB-IF und in der Konfig der USB-Schnittstelle sehe ich eine ADPU von 220. Da ich keine Koppler und Router habe, hätte ich jetzt erwartet, dass die ETS die APDU MIN korrekt erkennen sollte und das Paket entsprechen aufteilt.

Aber davon mal angesehen, wenn ich das nun so machen möchte, wie du es beschrieben hast und die Abfrage der ID's einschränken will um zu vermeiden, dass mehr als 6 ID's gefunden werden, dann kann ich das bei neu angelernten Fingern(also bei denen ich noch keinen Namen vergeben habe) ja nur so machen, dass ich erst für die ID den Namen ändere und dann in der Suche gezielt nur nach ID 6, oder den Namen suche? Weil wenn ich nach ID 6 suche, bevor ich einen Namen vergeben habe, dann bekomme ich die Meldung "Person zu Finger ID 6 nicht gefunden". Wenn ich aber nur <7 Finger angelernt habe, dann bekomme ich in der Liste auch Einträge von ID's für die ich noch keinen Namen vergeben habe und weiß dann zumindest welche ID's ich habe.

Sehe ich dass aber richtig, dass es auf Grund der beschrieben Problematik mit der APDU nicht möglich ist, dass ich bei mehr als 6 Fingern in der ETS eine komplette Liste der bekannten ID's anzeigen lassen kann? Ich kann dann nur noch gezielt eine ID Nr. oder einen Namen abfragen. Oder welche Möglichkeiten habe ich noch bei den Filtern? ID 5-10 kann ich ja nicht eingeben.

Viele Grüße André

Screenshot 2025-09-20 124704.png

[bambam]

Zunächst einmal muss ich sagen, dass alles, was ich auf deinem Screenshot sehe, korrekt aussieht:
Bei "Permission=False" wurde offenbar kein gültiger (= zuvor angelernter) Finger erkannt und somit kann logischerweise auch keine ID ausgegeben werden - ist ja schließlich kein bekannter Finger.

In dem Fall war war es aber ein bekannter Finger, der auch korrekt erkannt wurde.

Dennoch ist mir beim Testen aufgefallen, dass die Zutrittsdaten mit Firmware 0.10 tatsächlich nicht auf das KO ausgegeben werden - das habe ich soeben mit Version 0.10.1 gefixed. Diese bekommst du wie immer auf GitHub oder über die OpenKNX Toolbox.

Ich habe eben die 0.10.1 getestet und nun funktioniert auch die Touch-Platine ohne NFC und auf KO kommen auch passende Werte und nicht nur 00 00 00 00.

Hier mal die Ausgabe bei einem gültigen Scan von ID 2. Passt das mit der 0 bei Index of acess identification code = 0 ?


Screenshot 2025-09-20 132351.png

Danke für beiden Hot-Fixes.


P.S. In der ToolBox wurde mir die 0.10.1 nicht angezeigt, auch nicht als Pre-Release.

[abtools]

Hallo André,

Ich habe eben die 0.10.1 getestet und nun funktioniert auch die Touch-Platine ohne NFC und auf KO kommen auch passende Werte und nicht nur 00 00 00 00.

Sehr gut!

Hier mal die Ausgabe bei einem gültigen Scan von ID 2. Passt das mit der 0 bei Index of acess identification code = 0 ?

Screenshot 2025-09-20 132351.png

Das sieht alles korrekt aus, ja.

Das "access identification code"-Feld können wir hier nicht verwenden, das ist zu kurz.
Die ID wird daher über die 6 "access identification code"-Felder ausgegeben. Somit findest du die ID "2" in "Feld5".

Hättest du z. B. ID "143", wäre "Feld3=1", "Feld4=4" und "Feld5=3".

Danke für beiden Hot-Fixes.

Gerne!

P.S. In der ToolBox wurde mir die 0.10.1 nicht angezeigt, auch nicht als Pre-Release.

Stimmt, aber nicht mehr lange. ;-)
Das Update des Toolbox-Caches erfolgt aktuell einmal täglich, glaube so gegen 15 Uhr.

Viele Grüße
Andreas