[Firmware] Accesscontrol Extended

[mpl1337]

Hallo zusammen,

ich habe mich an eine Erweiterung des Access Controls gemacht. Dabei ist Folgendes entstanden:













Was wurde erweitert?

Der LED-Ring kann jetzt einer Aktion zugewiesen werden. Zusätzlich lässt er sich auch per KO von außen ansteuern, zum Beispiel für Rückmeldungen wie:

• Garagentor offen
• EMA unscharf
• sonstige Statusanzeigen

Aktuell sind 10 LED-Szenen möglich. Das sollte in den meisten Fällen ausreichen.

Außerdem können jetzt Finger/Tags/Aktionen/Zuweisungen direkt in der ETS ausgelesen und geschrieben werden. Finger und Tags können in der ETS auch gesperrt werden.

Zusätzlich gibt es ein Log für:

• Verwaltung
• Zutritt
• Fehler

Dieses kann ebenfalls in der ETS ausgelesen werden. Aktuell ist es auf 100 Einträge begrenzt, bei Bedarf wäre aber auch mehr möglich.

Neu dazugekommen ist außerdem ein UART-RFID-Scanner per Softserial, also eine China-Platine mit externer Antenne.

Was geht noch nicht?

Die Synchronisierung über mehrere Geräte ist aktuell noch nicht umgesetzt. Ich habe derzeit nur ein improvisiertes Gerät im Einsatz, bestehend aus einem Masifi-Sensormodul mit R503 und RFID-Platine. Sobald ich mir ein weiteres Gerät gönne, würde ich das nachführen.

Das Übernehmen von Fingern und Tags aus einem bestehenden Gerät ist nicht möglich (Flashbereiche wurden geändert). Finger und Tags müssten also neu eingelernt werden.

Den originalen NFC-Scanner konnte ich also nicht testen, da ich diesen nicht habe. Da der UART-Scanner aber als eigener Scanner behandelt wird und intern nur die UID weitergegeben wird, sollte der originale NFC-Scanner weiterhin funktionieren — inklusive der neuen Erweiterungen.

Zum Schluss noch ein HAS Addon

Mobile Ansicht:

image.png

image.png

image.png


Desktop:

image.pngimage.pngimage.png
Schlusswort

Ich stelle euch hier jeweils einen Build für das UP1 und für den AccessControl bereit.

Die ETS-knxprod erscheint nach dem Import unter dem Namen:

„OpenKNX: Zutrittskontroll-Extended“

In der ETS5 gibt es aktuell einen Darstellungsfehler.
Die Tabellen bleiben nach dem Auslesen leer, erst wenn man kurz zwischen zwei Tabs hin und her wechselt, werden die Inhalte angezeigt.

In der ETS6 tritt dieses Problem nicht auf. Falls jemand dafür eine Lösung kennt, gerne melden.

Die Kommunikations-KOs für Home Assistant werden in Home Assistant genauso benannt wie in der ETS.

Besondere Entitäten werden aktuell noch nicht bereitgestellt. Falls Bedarf besteht, könnte man später noch ein paar States mit Attributen per JSON ergänzen.


image.png
image.png
image.png
image.png
image.png



Spoiler:

image.png

[overkill]

Sehr coole Sache! Da steckt ja einiges an Arbeit drin, Hut ab!
Gibt es dazu auch ein Git-Repo und v.a.: willst Du das als Fork eigenständig weiterentwickeln oder in das Ursprungsprojekt zurückliefern, damit das noch mehr Anwendern zugute kommt?

[Ing-Dom]

Ohne inhaltlich reingeschaut zu haben, finde ich die Erweiterung für die Standard NFC Leser erstmal gut.

Ich hab aber ein Problem damit wenn die GPL Lizenzbedingungen verletzt werden, und das ist hier der Fall.
Du verteilst Binaries ohne die zugrunde liegenden Quellen.

Weiterhin sehen wir es als OpenKNX Team äußerst ungern, wenn unsere Applikationen außerhalb unseres Releaseschemas und unserer Repos veröffentlicht werden.
Das bringt die Versionierung durcheinander und hat das Potential das ETS Projekt der User zu zerschießen.
Daher ist der Downloadbeitrag erstmal gesperrt.

[mpl1337]

Sehr coole Sache! Da steckt ja einiges an Arbeit drin, Hut ab!
Gibt es dazu auch ein Git-Repo und v.a.: willst Du das als Fork eigenständig weiterentwickeln oder in das Ursprungsprojekt zurückliefern, damit das noch mehr Anwendern zugute kommt?

Ich hab die Original Hardware nicht, daher hab ich das erstmal nicht vor.

Du verteilst Binaries ohne die zugrunde liegenden Quellen.

Der Src liegt doch bei und die die ETS Produkdatenbank hat einen anderen Namen.

Aber gut, wenn es nicht gewünscht ist, dann einfach löschen

[Ing-Dom]

Der Src liegt doch bei

es liegt eine unvollständige Sammlung von Dateien bei, mutmaßlich die, die geändert wurden. Was genau aber die Basis ist, auf die sich diese Änderung und bezieht ist nicht klar.
Der übliche Weg ist der Fork der entsprechenden repos und commit der changes.
Was genau war den hier die Basis der Changes? In welcher Version wurden die anderen Module verwendet?

und die die ETS Produkdatenbank hat einen anderen Namen

Der Name ist Schall und Rauch. Relevant ist die ApplicationID und die ist gleich.

wenn es nicht gewünscht ist,

An sich sind Beiträge immer willkommen, es geht nur um die Art und Weise.
Was ist denn deine Vorstellung, was damit passiert wenn es nicht in den Hauptentwicklungszweig zurückfließt?
Es kaum sinnvoll nutzbar.. ohne Updates und Weiterentwicklungsmöglichkeit.

[overkill]

Ich hab die Original Hardware nicht, daher hab ich das erstmal nicht vor.

Schade! Über den Weg würdest Du ja auch Weiterentwicklungen wieder zurück bekommen, die Du ansonsten mühsam selbst mergen musst.

Aber gut, wenn es nicht gewünscht ist, dann einfach lösche

Das ist sicher nicht böse gemeint, das soll nur davor schützen, dass Leute ihr ETS-Projekt in einen Zustand bringen, der aufwendig wieder repariert werden muss. Ich sehe Deine Arbeit als wertvollen Beitrag zur Funktionserweiterung und würde das gerne auch nutzen. Aber dazu muss es über einen geordneten Weg ins Projekt einfließen.

[mpl1337]

Verstanden,

mein Fehler. War unüberlegt von mir und bleibt dann bis auf Weiteres bei mir alles.

[u20p17]

Was spricht denn gegen nen Pull Request von deinen Änderungen gegen die offizielle OpenKNX Repo? Finde es super wenn sich Leute an OpenSource Projekten beteiligen und damit den restlichen Entwicklern/Usern unterstützen

[uncelsam]

Ich finde deine Erweiterung auch echt interessant, wie aber schon von den anderen geschrieben, solltest Du dich allerdings an die Regeln von Openknx halten, und mit dem Team zusammen arbeiten, bisher wurde meines Wissen nach jeder der mitarbeiten möchte gerne angenommen und unterstützt, oft auch mit Hardware für Tests.

Deine Reaktion finde ich echt schade, aber so ist es halt...

[mumpf]

mpl1337: Wir waren schon mal in Kontakt, ich hatte Dich so verstanden, dass Du das Repo veröffentlichen wolltest wenn Du fertig bist und ich mir das anschauen sollte, wie weit in den Release-Zweig reinpasst und wir dann drüber reden? Uns hat jetzt nur Dein "Release" überrascht, weil es nicht abgestimmt ist. Ich finde Deine Arbeit wertvoll und auch sehr interessant. Und auch die Erweiterungen bis hin zum HomeAssistant sind doch prima.

Ich bin als nächstes sowieso am AccessControl dran und könnte mich dem Thema widmen.

und bleibt dann bis auf Weiteres bei mir alles.

Ich hab die Original Hardware nicht, daher hab ich das erstmal nicht vor.

Hier muss ich jetzt konkret nachfragen: Darf ich mich jetzt bei Dir bedienen und schauen, wie ich das zusammenführe oder willst Du das jetzt explizit nicht? Ich will auf keinen Fall gegen Deinen Willen was machen, aber eine Farbwahl der Farbringe wollte ich auch machen und die HA-Integration ist ja ein tolles Feature. Ich fände es schön, wenn wir uns zumindest so weit einigen könnten, dass Deine Arbeit nicht umsonst war.

Dass wir den Download erstmal zurückhalten ist nur wegen der Applikation und potentiellen Nebeneffekten (Updatebarkeit, ETS-Verträglichkeit). Normalerweise machen wir hier im Team Reviews und passen gegenseitig auf, dass alles "richtig" ist, das ist bei Dir nicht passiert, deswegen die Reaktion. Mitarbeit ist ausdrücklich gewünscht!
Ich denke, u20p17 wird das bestätigen können.

Gruß, Waldemar

[mpl1337]

Ich werde die Tage einen PR erstellen damit der Code offiziell bei euch ist. Ihr dürft euch bedienen und prüfen, ob und was davon für euch von Nutzen ist. Ich habe noch weitere Entwicklungen in der Pipeline. U.a eine Wiegand Schnittstelle, one time actions, zeitlich begrenzte Aktionen und die Android App(Binäre Datei) bleiben dann wohl bei mir, um nicht noch mehr Chaos zu verbreiten

[coko]

Ich hab die Original Hardware nicht

Die Erweiterung des Hardware-Supports kannst Du natürlich auch vorschlagen. Erst mal losgelöst von den anderen Erweiterungen.

Der Umgang mit den knxprods birgt einige Fallstricke, die dafür sorgen können, dass schlimme Dinge in der ETS passieren. In Deiner Konstellation ist es besonders tückisch, weil die Probleme bei anderen Usern absehbar erst in mit meheren Jahren Verzögerung auftreten würden, bzw. wir jetzt auch überlegen müssen Gegenmaßen zu treffen um das zu verhindern. Irgendwie hatte das somit einen gewissen "Zeitbombencharakter".

Ich werde die Tage einen PR erstellen [...] Ihr dürft euch bedienen und prüfen, ob und was davon für euch von Nutzen ist.

Ggf. auch mehrere (im Idealfall hast Du da schonwieso schon getrennte Commits):

• Support für weitere Hardware (potenziell am einfachsten zu übernehmen)
• LED-Ring-Farbe
• HA-Integration (eher aufwändigeres Thema)

Da aber am besten auch noch mal mit mumpf abstimmen in welcher Granularität das am besten passt

[jolt19]

Ich fände es fantastisch, wenn der RFID Scanner damit bald offiziell Einzug halten würde und mit Dominiks UP1 Hardware genutzt werden könnte.

[Ing-Dom]

Neu dazugekommen ist außerdem ein UART-RFID-Scanner per Softserial, also eine China-Platine mit externer Antenne.

PN532 oder welchen chip supportest du hier konkret?

[mpl1337]

Zeitbombencharakter

Was meinst du, wie lange das Ganze hier noch so weitergehen wird?

Inzwischen werden in der ETS Funktionen eingebaut, um unregistrierte Produkte nicht mehr einfach aus Projekten herauskopieren zu können. Es wird aktiv daran gearbeitet, das Umgehen der MA-Lizenzen zu verhindern, und vermutlich werden weitere Einschränkungen folgen – bis hin zur Verschlüsselung der Daten.

Spätestens dann muss man sich keine Gedanken mehr darüber machen, wer welchen Code im Forum verbreitet. Dann wird es nur noch möglich sein, KNX-Mitglied bzw. Hersteller zu werden und die entsprechenden Lizenzen zu erwerben. Daraus folgt natürlich auch, dass dieses Projekt in der bisherigen Form nicht mehr Open Source sein kann, weil das wiederum gegen die Lizenzbedingungen verstoßen würde – so wie mir hier vorgeworfen wird:

Ich hab aber ein Problem damit wenn die GPL Lizenzbedingungen verletzt werden, und das ist hier der Fall.
Du verteilst Binaries ohne die zugrunde liegenden Quellen.

Aus meiner Sicht habe ich jedoch nicht gegen die GPL verstoßen, da ich den vollständigen und nachbaubaren Code mit angefügt habe.

In Deiner Konstellation ist es besonders tückisch

Okay – warum auch immer.

Ggf. auch mehrere (im Idealfall hast Du da schonwieso schon getrennte Commits):

Einen PR werde ich machen, allerdings mit allen Änderungen zusammen.

Ich möchte mich hier nicht streiten oder bashen, aber man kann den Ball aus meiner Sicht auch etwas flacher halten – zumal sich das gesamte Projekt rechtlich ohnehin in einer gewissen Grauzone bewegen dürfte.

Ich wollte lediglich einen Beitrag leisten. Ich habe sehr viel Zeit in die Erweiterung gesteckt und nehme hier im Moment vor allem den erhobenen Zeigefinger wahr.

Ich war mit mumpf bereits in Kontakt und habe ihm die Erweiterung vorgestellt. Mein Vorschlag war, das Ganze einfach ins Forum zu stellen – genau so, wie ich es gemacht habe. Dass das nicht gewünscht ist, wurde mir vorher nicht mitgeteilt.

PN532 oder welchen chip supportest du hier konkret?

Ursprünglich hatte ich diesen Leser verwendet:

https://de.aliexpress.com/item/10050...r_list.order_l ist_main.181.45ed5c5foK4sme&gatewayAdapt=glo2deu

Bei diesem Modell lässt sich die Antenne ablösen und extern montieren. Die erfasste UID wird per UART als ASCII übertragen. Das machen die meisten Ali RFID/NFC Leser.

Ich erweitere jetzt noch folgenden:

https://de.aliexpress.com/item/10050...r_list.order_l ist_main.35.59f55c5fPrEYNI&gatewayAdapt=glo2deu

Hier bekomme ich RFID und NFC binär per UART bzw. Wiegand. Damit kann ich auch mein Android-Smartphone als NFC-Tag nutzen.

Mit PN532-Boards habe ich mich nicht beschäftigt, da die mir zu groß waren. Mir war vor allem eine kleine, einklebbare Antenne wichtig, die sich extern montieren lässt.