NUKI Smartlock Plugin

[hagor]

Christian Fenzl da hast du Recht, die Beschreibung des API Endpoints /info sagt eh was von "in Range" - Lesen bleibt mir halt doch nicht erspart
Das erklärt auch warum die unpaired Nukis so miese RSSI-Werte haben - sind bei mir wohl grad noch so am Rand der Reichweite und haben bei mir für falsche Schlüsse gesorgt

Die Korrektur sieht gut aus, die paired Nukis werden stabil gelistet und es ändert sich jetzt lediglich der RSSI
Danke dir! :-)

Find ich nicht schlimm, dass unpaired Devices nicht gelistet werden - sonst bräuchte es ja auch eine pairing/unpairing Funktion im Plugin zum Abrunden ;-) So sieht man nur was mit der App konfiguriert wurde.

[Christian Fenzl]

Das Pairing des Devices zur Bridge will ich garnicht im Plugin - so bleibt sichergestellt, dass der Benutzer schon erfolgreich seine Bridge in der App eingerichtet hat.

[hagor]

Jep macht auch Sinn so :-)

[bubuij]

Hallo Zusammen

Nun komme ich auch mal wieder dazu.

Kann bestätigen, dass der Change greift - siehe Printscreen.


Ist das nur bei mir so, dass die RSSI Werte nun Schwarz hinterlegt sind?

Christian Fenzl , danke für die rasche Korrektur/Anpassung!

[Christian Fenzl]

Komisch, das war bei mir auch, dachte aber nur, mein Browser spinnt. Es war 01:30, hab mich deswegen nicht weiter darum gekümmert.

[frshwoody]

Hallo Christian.

Ich finde leider keine Lösung für mein Problem. Ich habe das Plugin neu installiert und soweit ist auch alles in Ordnung.
Aber im Log wird mit ein kritischer AJAX-Fehler angezeigt: P2445 Ajax call: checktoken



Kannst du mir kurz auf die Sprünge helfen? Ich sehe die Bridge und das Device im Plugin alles scheint sonst in Ordnung zu sein.

SG, Andreas

[Christian Fenzl]

Du musst ins Log REIN schauen. Der Info-Button zeigt ALLES, was so dort und da passiert ist. Wenn du vor einer Stunde den Token noch nicht eingegeben hattest, steht das auch dort.

[frshwoody]

IM Log kann man keinen einzigen Fehler lesen. Dann ist praktisch alles in Ordnung?
Die Anzeige am Info-Button hat mich dann leider verunsichert.
Danke für die schnelle Info.
Einen schönen Tag noch.

[Imperator]

Seit der Nuki Bridge 2.7 Firmware wird das ringactionState für den Opener im Callback angeboten. Damit könnte man womöglich die Klingel vollständig in Loxone integrieren (inkl. intelligente Stummschaltung). Oder hat der Callback nochimmer eine starke Verzögerung von bis zu 30 Sekunden? Hat dies jemand schon zum Laufen gebracht und daher ein Konfigurationsbeispiel oder sonst eine Idee wie man dies am Besten umsetzen könnte?

[Imperator]

Meine Nuki Bridge scheint nur ein Callback für das Smartlock registriert zu haben. Da nun noch ein Opener dazu gekommen ist, müsste es dann nicht noch einen Callback für den Opener geben? Oder wird dieser erst nach einer bestimmten Aktivität angelegt?

[Christian Fenzl]

Der Callback ist pro Bridge, nicht pro Gerät.
Also alles in Ordnung, wenn die Geräte aufgelistet sind.

[Imperator]

Vielen Dank Christian Fenzl!

[JCR7]

Grüß euch in die Runde,

nachdem ich nun mein ekey uno mit Nuki verbunden habe hätte ich da gleich mal eine Frage:

ist es möglich (ich konnte es nicht herauslesen) auf das Protokoll von Nuki zuzugreifen?
Ich hätte daran gedacht, dass wenn Nuki durch den ekey geöffnet wurde zusätzliche Ketten auszulösen (z.b Alarmanlage, etc.)

dazu müsste ich vom Plugin übergeben bekommen, durch wen der Sperrvorgang durchgeführt wurde.

Danke und beste Grüße
Chris

[Christian Fenzl]

JCR7

Die Nuki Bridge sendet nicht mit, wie geöffnet wurde.
Mir ist bekannt, dass die Bluetooth API von Nuki den Öffnungstyp kennt (zb via API, per App, per Knopf am Nuki, oder mit dem Handrad), diese Info wird aber im Callback (den das Plugin empfängt) nicht mitgegeben.

Du könntest dem Nuki-Support mitteilen, ob man diese Info nicht in den Bridge Callback aufnehmen möge.

Ob es auch Benutzernamen oder eindeutige Identifikations-Schlüssel gibt (insbesondere wegen Ekey), weiß ich nicht. Kannst auch gleich mitfragen, interessiert uns alle 🙂

lg, Christian

[JCR7]

Hi,
Danke für deine rasche Antwort. Hatte ich schon fast befürchtet.

Anfrage an Nuki habe ich nun gestellt. Warten wir mal was kommt.

lg, Christian

[Christian Fenzl]

Info zur Nuki Software Bridge für Android - deren Weiterentwicklung und Support wird eingestellt: http://l.facebook.com/l.php?u=http%3...8FiFzxOIgs7Pfg

Das betrifft natürlich nicht die Nuki Bridge.

Die Software-Bridge funktioniert weiter, kann aber später nicht neu heruntergeladen werden.

lg, Christian

[Gargamel]

Hallo Christian Fenzl

habe vor zwei Wochen bei einem bekannten das Nuki Plugin installiert und auch ein Nuki Schloss erfolgreich eingebunden was wunderbar funktioniert.
Heute wollte ich eine zweite Bridge und ein zweites Schloss installieren. Es hat soweit alles funktioniert, Bridge über die Nuki App eingelernt und dann im Plugin die Bridge gesucht und gefunden.

Komischerweise war das erste Problem das die Vorlagen VI/VO nicht im xml Dokument herunter geladen wurden. Die Vorlagen die ich vor zwei Wochen in den Template Ordner hinterlegt habe wurden in der Config unter "Vorlagen" gefunden - diese wurden als XML Datei hinterlegt.
Die Vorlagen die ich jetzt vom Plugin herunter geladen habe waren erstmal leer und die musste ich dann mit einem editor öffnen. Habe dann eine bestehende Vorlage kopiert und den Inhalt des editors eingefügt. Somit war dann die Vorlage in der Config vorhanden. Hoffe das ist verständlich :-))

Nun zu meinem eigentlichen Problem.
Wenn ich das Nuki über die Nuki App öffne/schließe ändern sich auch die Werte im mqtt Plugin, denke das passt soweit. Was nicht funktioniert ist einen Ausgang schalten, sprich über die Loxone App öffnen oder schließen. ( Bei dem ersten Nuki funktioniert es ) Im Logfile zeigt es mir auch einen AJAX Fehler an und einen Error..

Kann ich dir das Log über eine PN schicken und könntest du da mal drüber schauen? Oder kann ich es hier bedenkenlos Posten??

[Christian Fenzl]

Ja, schick alles durch was du hast (PM).
Die Befehle zum Steuern gehen direkt zur Bridge - zeig, welchen Ajax-Fehler du meinst, weil das Plugin erhält dabei nur die Rückmeldung, nicht den eigentlichen Steuerbefehl.

[Imperator]

Hat der Callback noch immer eine starke Verzögerung von bis zu 30 Sekunden?

[Prof.Mobilux]

Bei mir kommt er sofort. Bridge Firmware 2.8.0

[Imperator]

Danke Prof.Mobilux. Super, dann könnte die Idee mit der Klingel gänzlich über Lox zu führen tatsächlich funktionieren - zumindest in Theorie.

[julianbmw]

Hat das mit der Klingel schon wer umgesetzt?

[samke]

Hi, ich nutze das Keypad - wenn man hier den PIN falsch eingibt, wird das im Nuki Protokoll als Fehleingabe gespeichert. Ist es möglich, das man diese Fehleingabe Info in den MS bekommt? So das ich dann dadruch eine Aktion auslösen könnte? Oder ist das wie bei Post 187, das sowas von Nuki nicht über die Bridge gesendet wird? Eine Lösung/Idee dazu gibt es dann nicht, oder?

[Christian Fenzl]

In welchem Protokoll steht das? Zeig mal einen Screenshot.

[samke]

Hier der Screenshot zur Pin Fehleingabe im NUKI Log.

[Christian Fenzl]

@samke
Denkanstoß an die Kollegen von NUKI:

https://developer.nuki.io/t/extend-nuki-brigde-api/9250

Wir bekommen keine Nachricht "Jetzt ist ein neuer Eintrag im Log", sondern könnten das Log nur regelmäßig abrufen.
In älteren Bridge Firmwares hat es die Bridge schon zerlegt, wenn wir zwei Aufrufe unmittelbar hintereinander gemacht hatten (der Code, um diese Bridge-Problem zu workarounden, ist immer noch in unserem Log sichtbar).
Selbst mit der neuen Firmware wäre ein Log-Abruf jede Sekunde ein Overkill, und wenn du die Informationen 5 Minuten später bekommst, bringt dir das noch was?

Das könnten wir schon implementieren, dass das Log nach einem selbst festlegbarem Intervall an MQTT gesendet wird. Die falsche PIN-Eingabe kann diesen Abruf aber nicht triggern, weil du und wir nicht wissen, wann jemand den PIN falsch eingegeben hat.

lg, Christian

[samke]

Super das mit dem "Denkanstoß an NUKI"! :-)

Ne 5min später die Info würde in dem Fall nichts bringen. Ich dachte daran, das wenn der Pin falsch eingegeben wird, ein Bild mit der Überwachungskamera gemacht wird und dieses ich als Push Info bekomme.

Alternative könnte vielleicht sonst erstmal sein, das man einmal pro Tag eine Info bekommt, wenn eine Falscheingabe stattgefunden hat (mit Uhrzeit wann genau). Dann könnte man in den Aufzeichnungen der Cam von dem Tag nachschauen.

[Christian Fenzl]

Ein regelmäßiges Auslesen des Protokolls ist denkbar.
Das Datenformat gilt es noch zu überlegen, weil Loxone kennt kein Array oder dergleichen, und irgendwie soll auch erkennbar sein, ob was Neues da ist oder nicht.

[samke]

Ok, also im Prinzip würde auch reichen, wenn es eine Info gibt, wenn es im Nuki Log ein Eintrag mit Pin Fehleingabe gibt (Check zB einmal an Tag). Beim nächsten Lauf sollte dann dieser Check nur auf neue Log Einträge beruhen. Wenn man dann eine Info bekommt, muss man halt über die Nuki App in derem Log die Uhrzeit nachschauen und dann bei der Cam. Das ist ja keine Sache, die täglich vorkommt. Daher wäre das schon besser als nichts :-)