[ NUKI Smartlock ] 73_NUKIBridge.pm und 74_NUKDevice.pm

[Sascha_F]

Hallo zusammen,

konnte die Posts in der letzten Zeit leider nicht mehr so stark verfolgen, daher hoffe ich, ich werfe hier nichts "altes" hoch.

Folgendes ist mir zum Batterie-Status des Nuki (2.0) aufgefallen:

Gestern Abend hat das "Tür öffnen" nicht mehr funktioniert. Dachte, die Batterien seien bald am Ende und habe dann auch das Batterie-Icon (mit wenig roter Füllung) in der Nuki App gesehen (ist mir bisher nie aufgefallen, ggf. auch noch neuer).

Die Readings haben folgende Werte:

battery	ok	2019-12-14 05:59:42
batteryCritical	0	2019-12-14 05:59:42
batteryState	ok	2019-12-14 05:59:42

Die Nuki-App hat also schon gezeigt, dass die Batterien nicht mehr lange halten. Vor ein Paar Minuten hat FHEM die Haustür aufgeschlossen. Das war wohl mit letzter Kraft, denn über die App bekomme ich jetzt keine Verbindung mehr "nicht erreichbar". Das dürfte dafür sprechen, dass die Batterien schon "critical" waren.

Die Batterie-Readings wurden ja zumindest in der Nacht noch aktualisiert. Da gibt's jetzt drei Möglichkeiten, denke ich:

- Über die API kommen falsche Daten
- API-Daten werden falsch ausgewertet
- Batterie-Readings wurden irgendwann mal aus dem Device ausgebaut und führen aktuell nur noch Dummy-Werte

So, habe die Batterien gerade getauscht - waren in der Tat komplett leer - hat nicht mal mehr für das Blinken der LED gereicht.

Viele Grüße
Sascha

[Firetic]

Ich versuche seit einigen Tagen die Firmware meiner Bridge upzudaten - allerdings bleibe ich irgendwie dauerhaft auf der 2.3.0 hängen. Gibt es irgendeinen Trick wie ich das mit dem Update schaffen könnte?

Vielen Dank

[Thyraz]

Bei mir hing sie da auch ne Zeitlang.

Habe dann die FHEM Module auf disabled gesetzt, dass die nicht irgendwie mit Befehlen dazwischenfunken, die Bridge rebootet (neu eingesteckt) und danach über den Browser direkt das fwupdate angestoßen:

https://developer.nuki.io/page/nuki-bridge-http-api-190/4#heading--fwupdate
Achtung der Token muss noch hinten mit dran an den Aufruf:
https://developer.nuki.io/page/nuki-bridge-http-api-190/4#heading--token

Dann hat die Bridge zu blinken angefangen, was Downloaden und Updaten bedeuted.
Das dauert dann ewig, da die nächste Firmware laut Changelog tiefgreifende Änderungen ggü. der 1.30 hat.
Also etwas Geduld mitbringen.

[CoolTux]

Verstehe ich das richtig das ein

Code Auswählen Erweitern

set NUKIBRIDGE fwUpdate
nicht geklappt hat?

[Firetic]

Ja genau - irgendwie scheint sich die Bridge mit dem fwUpdate Befehl vom FHEM Modul irgendwann aufzuhängen. Hab es auch schonmal mit dem Deaktivieren probiert, allerdings kein Reset der Bridge gemacht... Das werde ich dann nochmal probieren.

[antonwinden]

Das Firmwareupdate der Bridge ist bei mir auch nicht gegangen.
Erst wie ich das Device in fhem deaktiviert habe (aus testgründen ob die bridge dann stabiler läuft) hat sich die bridge von selbst über nacht upgedatet und läuft seither besser...
die 2.3 hat bei mir nur troubles gemacht....
gruß anton

[RappaSan]

Das mit dem trouble der 2.3.0 unterschreibe ich auch...

[Andy89]

Verstehe ich das richtig das ein

Code Auswählen Erweitern

set NUKIBRIDGE fwUpdate
nicht geklappt hat?

auch bei mir hat das nicht geklappt.
Ich habe dann auch das Fhem Bridge Device disabled und den manuellen http fwupdate Befehl gestartet. In der Nacht wurde dann das Update ausgeführt..

Davor habt wohl fhem das Update verhindet, indem es Befehle/Anfragen an die Bridge gesendet hat. Irgendwo im Nuki Forum hab ich gelesen, dass man auch keine info Anfrage an die Bridge senden soll, wenn man den fwupdate Befehl absetzt. Nur deswegen bin ich darauf gekommen, dass ich es in Fhem deaktiviere.

Beste Grüße
Andy

[CoolTux]

auch bei mir hat das nicht geklappt.
Ich habe dann auch das Fhem Bridge Device disabled und den manuellen http fwupdate Befehl gestartet. In der Nacht wurde dann das Update ausgeführt..

Davor habt wohl fhem das Update verhindet, indem es Befehle/Anfragen an die Bridge gesendet hat. Irgendwo im Nuki Forum hab ich gelesen, dass man auch keine info Anfrage an die Bridge senden soll, wenn man den fwupdate Befehl absetzt. Nur deswegen bin ich darauf gekommen, dass ich es in Fhem deaktiviere.

Beste Grüße
Andy

Gut zu wissen dann sollte ich es mal so versuchen ein zu bauen bei Gelegenheit.

[Firetic]

Sehr gut - hat geklappt 
Vielleicht ist die Bridge ja jetzt mal zu gebrauchen...

[Thyraz]

Igendwie komm ich mit den Events noch nicht so klar, die über das Callback der Bridge reinkommen.

Wenn meine Tür in der NUKI App auf "aufgesperrt" ist und ich dann die Tür per App öffnen lasse (also Falle ziehen),
sehe ich im Protokoll in der Nuki Smartphone App, dass die "Tür geöffnet" wurde.

Ich hätte daher in FHEM lockState Events nach dem Schema erwartet:
- Unlatching
- Unlatched
- und nach dem Loslassen der Falle dann wieder "Unlocked" da ich nicht zusperren lasse solange ich Zuhause bin.

Der einzige Event der da reinkommt ist aber "Unlocked".
Ist das normal, bedeuted Unlocked Tür geöffnet statt Falle gezogen?

Die API sagt eigentlich was anderes:
https://developer.nuki.io/page/nuki-bridge-http-api-190/4/#heading--lock-states


Oder bewahrheitet sich meine Vor-Kauf-Befürchtung, dass dies das nächste Produkt mit liebloser Umsetzung der lokalen API ist? 

[Thyraz]

Ok, ist wohl eine Art Failure-By-Desing:

https://developer.nuki.io/t/http-api-callback-and-the-unlatched-state/2091/4

edit: Feature request:
https://developer.nuki.io/t/enhance-the-current-bridge-callbacks-with-additional-keys-so-we-can-detect-lock-actions-in-smart-home-systems-more-reliable/4140

[Thyraz]

So weiter im Monolog.

Bin mittlerweile dabei den Opener mit ins Modul einzubinden.
Aber nachdem ich gelesen habe, dass man zur Zeit die Türklingel gar nicht über die HTTP API über Callback/Webhook geliefert bekommt,
ist die Anbindung leider nur halblebig.

Tür öffnen kann man dann wohl, Klingeln bekommt man aber eben nicht mit (und kann somit auch keine schönen Automatisierungen wie Klingelsignal durch blinkende Lampen oder Internal Call zum Klingeln auf dem DECT Gerät realisieren).

Damit gibt ist die API gefühlt 50% nutzlos, da eines der beiden Hauptfeatures nicht drin ist.

Ich kann nur jeden ermutigen hier:
https://developer.nuki.io/t/nuki-bridge-api-bell-ring-of-nuki-opener-as-trigger-for-callbacks/2557/8
- einen Vote für den Featurerequest abzugeben
- ein Post in dem Thread zu hinterlassen, dass eine SmartHome Implementierung des Openers damit ziemlich nutzlos ist und dies schnellstens nachgerüstet werden sollte.

[Andy89]

Ich kann nur jeden ermutigen hier:
https://developer.nuki.io/t/nuki-bridge-api-bell-ring-of-nuki-opener-as-trigger-for-callbacks/2557/8
- einen Vote für den Featurerequest abzugeben
- ein Post in dem Thread zu hinterlassen, dass eine SmartHome Implementierung des Openers damit ziemlich nutzlos ist und dies schnellstens nachgerüstet werden sollte.

done

[Thyraz]

So, wer will kann hier mal eine erste Version mit Support für den Opener runterladen und testen:
https://github.com/Thyraz/NUKI/tree/Opener

Die Attribute für den Webhook müssen nach Einspielen und FHEM Restart dann nochmal im Bridge Device angelegt werden,
da der Webhook dann nicht mehr pro Device läuft, sondern das Bridge Modul die einkommenden Events an die einzelnen Nuki Devices verteilt.

Da der Opener bei dem meisten ja sicher schon per Bridge Autocreate als nicht funktionelles Device angelegt wurde,
dieses nochmal löschen und dann nochmal den autocreate set Befehl in der Bridge ausführen.

Danach sollte der Opener neu angelegt werden und mit entsprechenden Readings und den passenden Set-Befehlen ausgestattet werden.

Sofern es bei euch zu keinen Problemen kommt, erstell ich für Cooltux einen Pull-Request auf Github.

P.S. da meine Erfahrung mit FHEM Entwicklungs-Internas noch nicht sooo ausgeprägt sind, empfiehlt sich evtl. ein Backup vor dem Test.