[OpenKNX-Ready] Zutrittskontrolle mit Fingerprint / Fingerabdruck

[tobiasr]

Ein Zennio Display hab ich vor ~2 Jahren auch mal Programmiert. Das hat ebenfalls die Firmware übertragen. Blöderweise hab ich das sogar über VPN gemacht, weil mir das mit der Firmware überhaupt nicht bewusst war. Dauerte dann halt ~40 Minuten.

Die BCU1 Geräte hatten die Firmware doch auch schon IN der Applikation, weil die BCU ja etliche vollkommen unterschiedliche Funktionen je nach Applikation abbilden konnte.

[mumpf]

Nein die ETS sieht sowas auch für Kommerzielle Anbieter (Massenmarkt) nicht vor.

Da muss ist Dir leider widersprechen. Die ETS kann das schon sehr lange, das gab es schon zu ETS4-Zeiten, ich habe damals eine Produktdatenbank (knxprod) von Zennio gehabt, die auch ein Firmware-Update enthielt. Ich hab aber überhaupt keine Ahnung, wie das funktoiniert hat und ich finde es auch nicht erstrebenswert, es so zu machen, wie es damals lief. Das was nämlich komplett "seemless", man hat einfach programmiert und die ETS hat "entschieden", dass die Gerätefirmware auch aktualisiert werden musste. Und das dauerte dann eben mal 30 Minuten oder so. Vor allem manchmal auch, wenn die Firmware bereits drauf war.
Und so würde es nötig sein, bei jedem reinen Firmware-Upgrade auch die Applikaitonsversion zu erhöhen. Alles Sachen, die wir nicht wollen. Aber es könnte sein, dass es technisch immer noch funktioniert... Ich habe nur lange keine Applikation mehr gesehen, die auch eine Firmware "im Bauch" hat.

Gruß, Waldemar

[thewhobox]

Das lustige daran ist:
DCAs müssen kostenlos sein.
Allerdings muss der Hersteller für jedes Update erneut zahlen (glaub 80€) und das jedes Mal, wenn es eine neue Version der Applikationen gibt (es wir nämlich jede Applikation UND jede Version davon manuell in der DCA abgelegt).

[traxanos]

Button sicher schnieke, aber Ihr könnt und wollt ja gar nicht in den Massenmarkt damit

Nein die ETS sieht sowas auch für Kommerzielle Anbieter (Massenmarkt) nicht vor. Das Tool ist zum verwalten von Geräten gedacht nicht mehr und nicht weniger. Wenn man so ein Update Button ähnlich wie MDT & Co haben möchte, dann muss das separat Entwickeln und als externe Anwendung in die ETS integrieren. Das muss aber imho die KNXA signieren und das würden Sie sicher nicht für eine OpenSource Projekt machen. Und eigentlich möchte man solche Apps nicht, da Sie orgen ggf nicht mehr funktionieren.

Ich denke das ist der Grund warum z.B. Enertex das Firmwareupdate extern macht ohne ETS Integration.

[Theees]

Bin jetzt auch schwach geworden und habe mir das Gerät bestellt
Bin gespannt!

[TabSel]

Ja, ist wirklich sehr innovativ, progressiv und so ein bisschen hat es Dir das UI der OpenKNX Geräte in der ETS schon auch angetan, mit Icons, Context Help etc…
für den Endanwender wäre ein „prüfe auf FW-Update“ und „install FW-Update“ - Button sicher schnieke, aber Ihr könnt und wollt ja gar nicht in den Massenmarkt damit, und dafür danke ich Euch am meisten!

Edit: ich brauch sicher keine solchen Buttons! Is ja eh nur Kosmetik! Nicht falsch verstehen!

[mumpf]

kann das nicht asynchron laufen?

Tut es ja, in einem eigenen Tool . Nee ernsthaft, wir bringen Sachen, die sinnvoll sind, in die ETS, weil es das KNX-Verwaltungswerkzeug ist. Aber die ETS ist weder ein UI-Framework, dass es erlaubt, beliebig "schöne" UI zu bauen noch ein Laufzeitsystem mit API's zur Verwaltung von KNX-Geräten. Javascript hört sich schön an, aber es gibt nicht wirklich viel, was man da machen kann. Wir sind schon jenseits der Grenzen, wenn man bedenkt, dass unsere bisherige Kommunikation über Buttons recht instabil ist und komplett vom Kommunikationspfad zum Gerät abhängt (aber da sind wir dran - wie an so vielen Dingen).

Es wäre ein Krampf, ein Update über die ETS zu machen, falls es überhaupt ginge, deswegen werden wir uns das nicht antun.

Das is eh Wahnsinn was die OpenKNXler hier zaubern

Danke für das Lob.

ist das alles Reverse Engineered oder gibt es irgendwo Dokumentationen zu ETS-APIs

So halb-halb. Die ETS-APIs erlauben Dir den Zugriff auf interne Objekte, aber es gibt kein Discovery, Du kannst also nicht erfragen, welche Objekte es gibt. Deswegen betreiben wir recht großen Aufwand beim Bauen der Applikation und geben alle benötigten Informationen vorweg mit. Also eigentlich ist es was komplett neues, das wir so noch nirgends gesehen haben - eben echte Innovation.

Gruß, Waldemar

[TabSel]

kann das nicht asynchron laufen? Is aber ja auch nur Kosmetik. Das is eh Wahnsinn was die OpenKNXler hier zaubern, z.B. mit dem ConfigTransfer, im Fingerprint… ist das alles Reverse Engineered oder gibt es irgendwo Dokumentationen zu ETS-APIs?

[willisurf]

per ETS Button/javascript

wäre für mich eher ein Nachteil, da die ETS dann durchgehend blockiert wäre.

[TabSel]

Danke für die Rückmeldung, freut mich!


Finde ich auch. Muss nur noch robuster werden, vor allem durch Koppler hindurch. Aber wir arbeiten dran, stückchen für Stückchen.

Gruß, Waldemar

und sicher per ETS Button/javascript…?

[mumpf]

Danke für die Rückmeldung, freut mich!

Firmwareupdate über KNX ist ein big Features...!!!!

Finde ich auch. Muss nur noch robuster werden, vor allem durch Koppler hindurch. Aber wir arbeiten dran, stückchen für Stückchen.

Gruß, Waldemar

[benji]

Hi,

ich hatte heute auch endlich mal Zeit die Firmwareupdates meiner FP zu machen. Wirklich mal wieder Klasse Arbeit...ich bin immer noch richtig begeistert.


Ps: Firmwareupdate über KNX ist ein big Features...!!!!

[mumpf]

Freut mich und danke für die Rückmeldung.

Gruß, Waldemar

[klayman]

Das steht in unserem Wiki: https://github.com/OpenKNX/OpenKNX/w...tuelle-Version

Und das gilt für alle Applikationen, nicht nur für OpenKNX. Wir achten nur besonders drauf, dass das möglichst immer geht.

Gruß, Waldemar

P.S.: Genau lesen, was da steht, die Schritte sind wichtig!

Grandios, es hat funktioniert. Danke für die Hilfe.

[mumpf]

Natürlich würde es an der Aktion einfacher sein und den Wunsch gab es auch schon. Wir werden das diskutieren.

Erstmal musst Du aber mit den verfügbaren Möglichkeiten leben, es ist Urlaubszeit und eine größere Version (mit Änderungen in der Applikation) wird noch etwas dauern...

Und es ist wirklich nicht schwer über eine Logik:

OpenKNX,cv1,*/LOG:0x33/*§f~Name=Aktion%20sperren§f~Logic=4§f~Trigger=1§f~TriggerE1=1§f~NameInput1=Aktion%20(intern%20verkn%C3%BCpft)§f~E1=1§f~E1UseOtherKO=1§f~E1OtherKO:2=100§f~NameInput2=Sperre§f~E2=2§f~E2Default=2§f~NameOutput=Aktion%20nach%20Sperre§>Eingang1->Bestehendes KO: dort Ausgangs-KO§>           der zu sperrenden Aktion auswählen§;OpenKNX

Gruß, Waldemar