[NUKI Smartlock] Neuer Thread

[CoolTux]

Du brauchst die Bridge.

[zivi]

Du brauchst die Bridge.

Alles klar, danke dir!

Gruß
Zivi

[marboj]

Du brauchst die Bridge.

Also das 3.0 Pro und die Bridge? Ist das nicht doppelt gemoppelt?

Gruß
Marco

[CoolTux]

Kommt drauf an was Du machen/haben willst.

Wenn es Dir nur damrum geht über das Internet mittels der Cloud Dein Schloß zu bedienen dann ja. Willst Du die HTTP API verwenden um mittels FHEM das Schloß zu bedienen und andere Nuki Produkte wie den Opener, dann nein.

[swsmily]

Hallo,

seit meinem letzten Update hab ich bei jedem Tür öffnen und schließen folgende Einträge im Logfile:

Code Auswählen Erweitern

2022.01.15 17:32:49.053 3: NUKIBridge WEBHOOK (NukiBridge) - Received webhook for matching NukiId at IODev NukiBridge

Diese hatte ich vorher nicht. Laut Wiki sollte bei verbose 3 auch nur gesendete Meldungen protokolliert werden.

Zusätzlich hatte ich heute einmalig folgenden Eintrag im Log:

Code Auswählen Erweitern

2022.01.15 17:38:19.165 3: NUKIBridge (NukiBridge) - JSON error while request: malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "HTTP 503 Unavailable") at lib/FHEM/Devices/Nuki/Bridge.pm line 870.

Was hat das zu bedeuten?

[CoolTux]

Die erste Meldung dient zur Hilfe für den Webhook. Somit kann man sofort sehen ob der Callback funktioniert.

Beim der zweiten Meldung brachte die Bridge eine Meldung in Form eines HTTP Fehlers anstatt eines erwarteten JSON String.

[swsmily]

Die erste Meldung dient zur Hilfe für den Webhook. Somit kann man sofort sehen ob der Callback funktioniert.

Beim der zweiten Meldung brachte die Bridge eine Meldung in Form eines HTTP Fehlers anstatt eines erwarteten JSON String.

Braucht man diese Meldung zum Webhook denn wirklich bei Verbose 3?
Für mich ist das eher nur ein Hinweis. Während die zweite Meldung ein Error ist, aber auch Verbose 3.
Ich denke es ist evtl kontraproduktiv Hinweise und Fehler im gleichen Log-Level zu haben.

[CoolTux]

Gerade zum Thema Callback würde so viel im Forum nachgefragt das ich die Meldung extra so angesetzt habe. Für mich als Maintainer sehe ich da eher ein Ansatz weniger schnell Angefragt zu werden.

[swsmily]

Gerade zum Thema Callback würde so viel im Forum nachgefragt das ich die Meldung extra so angesetzt habe. Für mich als Maintainer sehe ich da eher ein Ansatz weniger schnell Angefragt zu werden.

Mich hat es erstmal verwirrt, als plötzlich diese Zeilen im Logfile aufgetaucht sind. Ich bin der Meinung, dass weniger mehr ist. Fehlermeldungen ja klar, die gehören ins Logfile, ob aber der Webhook funktioniert, wenn ich die Tür öffne und schließe, sehe ich ja an den entsprechenden Readings. Sollte da was nicht funktionieren, kann man im Bedarfsfall erstmal Verbose höher einstellen.
Ich persönliche finde daher die Meldung bei Verbose 3 nicht so schön, da Error und Hinweis beide in Verbose 3 kommen. Würde ich auf Verbose 2 einstellen, hätte ich auch die Error-Meldung nicht bekommen. Aber, wenn es so viele Nachfragen dazu gab und es für dich als Maintainer so besser ist, kann ich gut damit leben. 

Für so ein tolles, dazu noch kostenloses Spitzenprodukt wie FHEM mit all seinen Modulen, der tollen Community, usw. nehm ich gern diesen Eintrag im Logfile in Kauf 

Danke für die Aufklärung!

[Frank D. aus V.]

Ich habe die Nuki-Bridge und das Nuki-Smartlock 3 in FHEM eingebunden. Jetzt habe ich die Vermutung das sich, durch die zyklichen Abfragen alle 30 Sekunden, die Batterien schneller entleeren. Leider finde ich keine Möglichkeit den Intervall zu ändern. Im wesentlichen interessiert mich nur der "state" des Schlosses zur Weiterverarbeitung. Hätte da jemand einen Tipp?

[CoolTux]

Die Abfragen werden nicht auf das Schloss gemacht sondern einzig und allein auf die Bridge. Darauf wurde geachtet. Wie oft dann die Bridge sich aktuelle Daten vom Schloß holt kann ich aber nicht sagen. Auf jeden Fall hat die Abfrage keinen sonderlichen Einfluss auf den Batterieverbrauch.

[enno]

Moin Marko,

ich bin mit deinem Modul sehr zufrieden. Leider fehlt mir aber immer wieder die Information wer die Tür geöffnet hat. Leider ist diese Information ja aus der API nicht zu bekommen. Hast du mal daran gedacht eine Möglichkeit einzubauen, die fehlende Information über WebAPI zu holen? Vorschlag wird auch hier gemacht.

https://developer.nuki.io/t/add-user-to-bridge-http-api-notifications/151/34

Gruss
  Enno

[enno]

Habe mir jetzt aus einem anderen FHEM "Baukasten" eine Abfrage gestrickt:

Code Auswählen Erweitern

defmod NUKI_WEB JsonMod https://api.nuki.io/smartlock/log
attr NUKI_WEB DbLogExclude .*
attr NUKI_WEB httpHeader Authorization: Bearer [KEY]
attr NUKI_WEB readingList complete();;

Die Daten rufe ich ab, wenn Nuki aufgeschlossen wurde und werte dann das Reading "0.name" aus.

Gruss
  Enno

[Jaykoert]

Hallo,

ich habe vor einigen Tagen ein Update gemacht und bekomme nun folgende Fehlermeldung beim Start:

Code Auswählen Erweitern


Compilation failed in require at ./FHEM/73_NUKIBridge.pm line 44, <$fh> line 617.
Attempt to reload FHEM/Devices/Nuki/Bridge.pm aborted.


Hat jemand eine Idee?

Gruß
Jaykoert

[CoolTux]

Hallo,

ich habe vor einigen Tagen ein Update gemacht und bekomme nun folgende Fehlermeldung beim Start:

Code Auswählen Erweitern


Compilation failed in require at ./FHEM/73_NUKIBridge.pm line 44, <$fh> line 617.
Attempt to reload FHEM/Devices/Nuki/Bridge.pm aborted.


Hat jemand eine Idee?

Gruß
Jaykoert

Schau mal ob Du unter /opt/fhem/lib/FHEM/Devices/Nuki etwas zu stehen hast