NUKI Smartlock Plugin

[Christian Fenzl]

NUKI Smartlock Plugin

Version 0.1.0 PRE-RELEASE

Prof.Mobilux und ich stellen euch heute das NUKI Smartlock Plugin vor. Unterstützt werden als Schnittstelle die NUKI Hardware-Bridge und Software-Bridge. Als Endgeräte sind das NUKI Smart Lock sowie der NUKI Opener unterstützt.

Das Plugin ist eine Schnittstelle NUKI Bridge -> MQTT. Für die Verbindung zu Loxone ist das MQTT Gateway Plugin auf einem LoxBerry erforderlich. Wir haben alles gemacht, dass die Konfiguration möglichst selbstständig funktioniert.

Das Plugin kümmert sich vollautomatisch um die Einrichtung des Callbacks, um Batterie zu sparen, und führt stündliche Keep-Alives durch, um zu prüfen, ob die Geräte noch verfügbar sind.

Außerdem erzeugt das Plugin für euch in der Weboberfläche die Loxone Vorlagen für die Ausgänge und Eingänge.

Download und Konfiguration ist im Wiki beschrieben:

https://www.loxwiki.eu/x/t4RdAw

Das Plugin führt automatische Updates durch, wenn ihr diese in der Plugin-Verwaltung aktiviert.

Fragen und Feedback immer gerne hier in diesem Thread.

Viel Erfolg!
Christian und Michael

[Christian Fenzl]

V0.1.1
Fixed VirtOut Template: Falsches Feld mit der URL befüllt (Commands funktionierten nicht)
Templates: Encodingfehler Umlaute behoben

[Christian Fenzl]

Version 0.2

• Sicherheit: Token wird nicht mehr ins Logfile geschrieben
• Sicherheit: Durchgehend alle Aktionen sind mit dem SecurePIN geschützt
• Geräte: Anzeige der Geräte-Signalstärke (RSSI) in Farbe
• Analog-Aktion zum VO-Template hinzugefügt
• Anpassungen für die Unterstützung von Multilingual
• Deutsche Übersetzung

[Prof.Mobilux]

Ich habe da mal gleich ein Release draus gemacht :-)

[thomas76ch]

Wow, jetzt schon herzlichen Dank für das Plugin. Nuki wurde bestellt und ist bald einsatzfähig. Freue mich schon.
Super Arbeit, Danke

[Wohle]

Das ist super - vielen dank!

[thomas76ch]

Hi,
wollte euch kurz informieren, dass ich über das Plugin mein neues Nuki integrieren konnte und soweit alles perfekt läuft. Selten kämpfe ich jedoch mit leichten Verzögerungen von ca. 20s, was schon echt lange ist.

Zudem wollte ich euch über die Schliess- und Öffnungsvorgänge fragen, ob ihr diese kontrolliert? Konkret ws macht ihr, wenn das Schloss zugesperrt ist und ihr zum Beispiel den "Gute-Nacht-Knopf" drück, welches ein Befehl ans Nuki sende, dass es zusperren soll. Lass ihr diesen Befehl einfach durch oder habt ein eine kleine Schlaufe um abzufragen, wie der Zustand des Schlosses ist?

Hoff meine Formulierung ist verständlich

Gruss Thomas

[Christian Fenzl]

Bezüglich Verzögerung, das können wir bestätigen, und liegt an der Bridge.
Bei Nuki (im Developer-Forum) gab es bezüglich der Bridge Firmware auch einige (mehr als kritische) Meldungen zu deren Leistung - wir haben im Plugin da auch ein paar Sachen drin, um diese Probleme zu umgehen, und Nuki hat auch selbst gesagt, dass es strukturelle Änderungen der Bridge Firmware geben muss (schöne Umschreibung von "Neuentwicklung"), nur wird das nicht so schnell gehen.

Du solltest jedenfalls Befehle immer absenden und nicht vorher auf den Status prüfen (dem Smartlock ist das egal). Eine Statusüberprüfung des lockState, ob mein Befehl tatsächlich ausgeführt wurde, habe ich derzeit nicht (damit gab's bei mir aber noch nie Probleme).
Du solltest aber jeddnfalls die im Wiki-Artikel empfohlenen Keep-Alives übernehmen, damit du weißt, ob das Smartlock/Bridge auch tatsächlich noch verbunden ist.

Lg, Christian

[thomas76ch]

Ok, bin somit zumindest froh, dass nicht nur ich mit Verzögerungen zu kämpfen hab... und eine kleine Hoffnung hab ich, dass dies wohl über Firmware Updates massiv verbessert werden kann seiten Nuki.

Ok, danke für die Info... hatte es soeben getestet was passiert, wenn Nuki zugesperrt ist und ich den zusperr- Befehl gebe... er rattert aber es geschieht nichts. Somit passt das so wie ich mir das vorstelle. Die KeepAlives habe ich wie im Wiki und Vorlage umgesetzt.

Gruss Thomas

[Christian Fenzl]

NUKI Smartlock Plugin

Version 0.2.2 Release

• Korrigiert den Statusabruf per Cron für NUKI Opener (nicht betroffen ist das normale Smartlock)
• Korrigiert kleine Fehler im Template Builder
• Visuelle Optimierung der Popups

Wer keinen NUKI Opener hat, braucht das Update nicht durchzuführen (das NUKI Smartlock ist nicht betroffen). Auch die Templates vor dieser Version sind in Ordnung, man braucht nichts auszutauschen.

Wiki https://www.loxwiki.eu/x/t4RdAw bzw. über Plugin AutoUpdate.

lg, Christian

[Prof.Mobilux]

Die Verzögerungen hab ich bei mir auch - die Bridge ist für den Preis eine wirkliche Katastrophe...

Zusätzlich habe ich das Thema, dass die Falle bein ersten Öffnen oft nicht aufgehalten wird, sondern nach 1 Sekunden wieder zurückschnappt. Ich muss dann nochmal öffnen und erst dann wird die Falle auch aufgehalten.

[mgerste]

Hallo, bei mir funktioniert es leider überhaupt nicht. Wenn ich den Befehl aufsperren schicke, öffnet die Türe und sperrt sofort wieder ab. Vor der Installation vom Plugin hatte ich dieses Problem nicht. Selbst wenn ich es über den Knopf am Nuki versuche funktionierte es nicht mehr. Ist mein Nuki defekt, oder soll ich ihn einfach einmal neu installieren?
Weiteres schlägt die Abfrage Ajax checkonline stätig fehl. Alle anderen Abfragen sind lt. Log ok...

[Christian Fenzl]

Bezüglich checkonline: Kannst du mir das Logfile per PM schicken. Es sollten keine Passwörter/Tokens drin stehen, aber trotzdem kontrollieren. Wenn es ein JavaScript-Fehler ist, dann diesen + Browser und Browserversion.

Bezüglich Auf/Zusperren: Kannst du deine Beschaltung und den verwendeten VO (URL) schicken. Den Token mit xxx überschreiben.

[Christian Fenzl]

mgerste Oder siehst du das nur im Log, aber „Online“ ist grün?

[Christian Fenzl]

mgerste Danke für das Log. Das was du da im Log siehst, ist „by design“ (zumindest derzeit).
Wir haben zwei Ajax-Calls: Einen ohne Token, nur um zu prüfen, ob die Bridge erreichbar ist, und einen zweiten mit Token, um diesen zu prüfen. Der erste Call gibt im Log immer diesen Fehler aus, das ist ok.

Jetzt wo wir drüber reden, ist das eigentlich unglücklich, weil mit dem Token-Check eigentlich beide Sachen geprüft werden können. Ich nehm das in die Issues auf.

Dass das SmartLock selbst wieder zusperrt, kann eigentlich fast nur was an der Loxone-Beschaltung sein. Das Plugin ist beim Sperrbefehl ja garnicht beteiligt, das geht direkt zur Bridge.

[Christian Fenzl]

https://github.com/mschlenstedt/LoxBerry-Plugin-Nuki/issues/36

[thomas76ch]

Bezüglich Verzögerung, das können wir bestätigen, und liegt an der Bridge.
Bei Nuki (im Developer-Forum) gab es bezüglich der Bridge Firmware auch einige (mehr als kritische) Meldungen zu deren Leistung - wir haben im Plugin da auch ein paar Sachen drin, um diese Probleme zu umgehen, und Nuki hat auch selbst gesagt, dass es strukturelle Änderungen der Bridge Firmware geben muss (schöne Umschreibung von "Neuentwicklung"), nur wird das nicht so schnell gehen.

Du solltest jedenfalls Befehle immer absenden und nicht vorher auf den Status prüfen (dem Smartlock ist das egal). Eine Statusüberprüfung des lockState, ob mein Befehl tatsächlich ausgeführt wurde, habe ich derzeit nicht (damit gab's bei mir aber noch nie Probleme).
Du solltest aber jeddnfalls die im Wiki-Artikel empfohlenen Keep-Alives übernehmen, damit du weißt, ob das Smartlock/Bridge auch tatsächlich noch verbunden ist.

Lg, Christian

Zeil war es eigentlich, etwas Batterie zu sparen. DAs SmartLock rattert ganz schön, obwohl es ja nicht müsste. Also wenn das Nuki zugesperrt ist und ich gebe nochmals den Befehl zusperren, macht es irgendwelche Bewegungen. Es könnte ja einfach über die Statusnummern überprüft werden, ob der befehl nochmals abgesetzt werden sollte. Konkret

Status mit 1 (locked) oder 4 (locking) vorab überprüfen, bevor ein erneuter Zusperrbefehl geben wird.

Oder würdest du das nicht empfehlen?

Danke und Gruss

[Christian Fenzl]

Hi Thomas,

durch die Callbacks statt minütlicher Abrufe fällt schon mal einiges an Batterieverbrauch weg.

Ich habe mit einer Logik zum Filtern auf Loxone-Seite ein ungutes Gefühl. Das Callback dauert (wie wir nun ja wissen) bis zu 20 Sekunden. Für ein erfolgreiches Callback muss der LoxBerry unbedingt laufen. Wenn in diesen 20 Sekunden etwas passiert, oder der LoxBerry, warum auch immer, nicht verfügbar ist, hast du einen falschen Status und filterst vielleicht deswegen ein legitimes Lock-Event weg.
In Anbetracht dessen, und dass es hier um eine wichtige Sicherheitseinrichtung geht, nimm den zusätzlichen Batterieverbrauch für die nutzlose Bewegung einfach in Kauf.

Ich habe zudem bei NUKI deponiert, dass dieses Filtern auf Seite des Smartlocks passieren sollte:
https://developer.nuki.io/t/battery-...?u=christiantf

Wenn eine Filterung passiert, dann muss das direkt am Smartlock passieren.

lg, Christian

[thomas76ch]

Hallo Christian,

gebe dir zu 100% recht, dass dies eigentlich im Smartlock selbst geschehen sollte. Werde dies somit nicht einbauen, da es einfach zu insicher ist. DAs bei einem Sicherheitsrelevanten Element einzubauen, wäre definitiv falsch.

Hoffe nun auf Nuki, dass dies bei der API berücksichtigt wird.

Bezüglich der geschwindigkeiten, welche ja auf die Bridge zurück zu führen ist, hat es mich schon verwundert, da ja gerade die Version 2 vorgestellt wurde. Auch da, lassen wir uns überraschen was von Seiten Nuki geschehen wird.

Nochmals herzlichen Dank für die Hintergrundinfos.

Thomas

[Christian Fenzl]

mgerste

Bezüglich "öffnet die Tür und sperrt wieder ab" - sogar wenn du den Knopf am Smartlock drückst:
Das Plugin ist dabei überhaupt nicht involviert, das ist eine reine Aktion, die das Smartlock für sich ausführt. (außer, du hättest eine Art Rückkopplung Callback->Sperrbefehl in der Config zusammengebaut)


Im Nuki Developer Forum habe ich eine ähnliche Anfrage gefunden, wo das plötzlich aufgetreten ist, und das könnte eine Neukalibrierung des Türsensors erfordern (Nuki 2.0): https://developer.nuki.io/t/door-status-incorrect/2668

Wenn das beim Drücken auf den NUKI-Knopf trotz Neukalibrierung des Türsensors bleibt, musst du dich an den NUKI Support wenden.

lg, Christian