Test Adapter Nuki-extended v2.0.x

[Sandmanyz]

@Zefau sagte in [Neuer Adapter] Nuki:

/opt/iobroker/node_modules/iobroker.nuki2/node_modules/nuki-bridge-api/

Der Pfad /opt/iobroker/node_modules/iobroker.nuki2/node_modules/nuki-bridge-api bzw. der Ordner nuki-bridge-api existiert nicht. Der Pfad /opt/iobroker/node_modules/nuki-bridge-api/ hingegen ist vorhanden und es liegt auch die Datei package.json drin.

Ich habe mal einen Screenshot gemacht....

[Zefau]

@Sandmanyz Ok. Mist, ist die richtige Version Langsam weiß ich leider nicht weiter.

Der Log-Eintrag aus Zeile #L316 ist bei dir vorhanden (https://github.com/Zefau/ioBroker.nuki2/blob/master/nuki2.js#L316).
Aber weder der Log-Eintrag in #L322 noch in #L329 bzw. #L333 wird bei dir angezeigt, obwohl mindestens einer von diesen im Log stehen müsste.

[Zefau]

@Sandmanyz Wir können es allerdings "manuell" beheben, allerdings weiß ich nicht, ob das von Dauer ist.

1. Wenn du http://<bridge_ip>:<bridge_port>/callback/list?token=<bridgeToken> aufrufst
2. alle Einträge dort löschen mittels http://<bridge_ip>:<bridge_port>/callback/remove?id=<callback_id>&token=<bridgeToken>
3. den korrekten Eintrag manuell anlegen mittels http://<bridge_ip>:<bridge_port>/callback/add?url=http%3A%2F%2F<ioBrokerIp>%3A51988%2Fnuki-api-bridge&token=<bridgeToken>

EDIT: Kannst mir dann gerne nochmal die Ausgabe aus #1 vorher und nachher schicken, dann prüfe ich das nochmal quer.

[Sandmanyz]

@Zefau sagte in [Neuer Adapter] Nuki:

EDIT: Kannst mir dann gerne nochmal die Ausgabe aus #1 vorher und nachher schicken, dann prüfe ich das nochmal quer.

Verflucht, nicht gelesen. Habe also keinen vorher Screenshot. Ich weiß nur, dass der Broker mit zwei Ports (8080 und 51988) eingetragen war und die IDs 0, 1 und 2 belegt waren. D.h., ich weiß nicht mehr was bei der dritten ID hinterlegt war.

Jetzt gibt es genau einen Eintrag: {"callbacks": [{"id": 0, "url": "http://192.168.xxx.x:51988/nuki-api-bridge"}]} (192.168.xxx.x = mein Broker).

Wenn ich den Link http://192.168.xxx.x:51988/nuki-api-bridge aufrufe erscheint im Browser Cannot GET /nuki-api-bridge. Soll das so?

Es scheint erst einmal zu funktionieren. Die Werte werden nun aktualisiert. Wie zuverlässig das ist, wird sich zeigen.

Vielen Dank für deine Unterstützung

[Zefau]

@Sandmanyz sagte in [Neuer Adapter] Nuki:

Wenn ich den Link http://192.168.xxx.x:51988/nuki-api-bridge aufrufe erscheint im Browser Cannot GET /nuki-api-bridge. Soll das so?

Das ist richtig, da kein direkter Aufruf (/GET) unterstützt wird.
Freut mich, dass es (endlich) funktioniert.

[Sandmanyz]

@Zefau
Es war nicht von langer Dauer. Die Werte werden wieder nicht aktualisiert.

Habe nun den Adapter von @smaragdschlange installiert, welcher für den Smart Lock 2.0 funktioniert und erst einmal meine Zwecke erfüllt.

[Zefau]

@Sandmanyz alles klar, sehr schade

[Mercator]

@Zefau
Bei mir wurde noch nie bisher ein Wert in nuki2.0.bridge__nuki.callbacks eingetragen.
Sollten hier eventuell die Ergebnisse von :8080/callback/list stehen?

Darüber hinaus würde es mich interessieren, wieviele Sekunden es normalerweise bei dir/euch dauert zwischen dem Öffnen der Tür (sprich Aufleuchten der LED am Schloss) und Update im ioBroker durch den Callback (z.B. nuki2.0.door__meinNukiSchloss.status.refreshed)?
Hintergrund ist, dass ich per Script einen den Summer der Haustür betätige, sowie das Nuki per BLE die Wohnungstür geöffnet hat. Leider kommt der Callback aber erst nach ca. 10 - 20 Sekunden an, was dann eine gefühlte Ewigkeit ist, bis die Haustür aufgeht.
Gerne würde ich das so haben, dass nach 1-2 Sekunden, nachdem das Schloß bei Ankunft aufschließt, den Callback sendet und somit die Haustür öffnet.
(Ich nutze die HW Bridge + Nuki 2.0)

[Brati]

@Zefau

Ich bekomme den Adapter auch nicht zum Laufen. Also grün ist er, aber der State stimmt nicht.

In der Nuki App ist der Status richtig, im Adapter wird nix aktualisiert. Web API habe ich auch schon aktiviert, direkt die Bridge auslesen würde mir aber reichen.

Der Versuch über

http://<NukiBridgeURL>:8080/lockState?nukiId=<NukiID>&token=<NukiToken>

führt zu

HTTP 401 Unauthorized

ID habe ich aus dem Adapter genommen und den Token vorher aus der Bridge.

Nächster Versuch über

http://<bridgeIp>:8080/callback/list?token=deinToken

gibt

{"callbacks": [{"id": 0, "url": "http://1*******:51988/nuki-api-bridge"}]}

Müsste dort bei 0 nicht auch die ID stehen?

Das Schloss ist erst 2 Wochen alt und hat die aktuelle FW.

Update

Der andere Adapter funktioniert.

Grüße

Brati

[bergjet]

@Mercator said in [Neuer Adapter] Nuki:

Callback aber erst nach ca. 10 - 20 Sekunden an

Leider liefert Nuki das nicht schneller. Mindestens dauert es 20sek. Habe schon einmal an Nuki geschrieben, aber da kam nichts zurück.

[Brati]

Ich muss mich noch mal melden, weil doch keiner der Adapter zuverlässig läuft. Hatte nur keine Zeit mich drum zu kümmern. Es wird nur beim Adapter Start der Status eingelesen und dann nie wieder aktualisiert.

In der App und Web stimmt er.

Ich hatte die Bridge noch mal zurück gesetzt und über:

http://<NukiBridgeURL>:8080/lockState?nukiId=<NukiID>&token=<NukiToken>

stimmt der Status.

{"mode": 2, "state": 1, "stateName": "locked", "batteryCritical": false, "success": true}

Mit Aufruf von

http://<NukiBridgeURL>/list?token=<NukiToken>

Stimmt der Status nicht (es ist gerade abgeschlossen):

[{"deviceType": 0, "nukiId": #####, "name": "####", "lastKnownState": {"mode": 2, "state": 3, "stateName": "unlocked", "batteryCritical": false, "timestamp": "2019-09-09T08:34:16+00:00"}}]

Ich kann das Schloss auch über die Adapter bedienen. Callback ist dektiviert.

Woran könnte es liegen?

Grüße

Brati

[Zefau]

@Brati sagte in [Neuer Adapter] Nuki:

dann nie wieder aktualisiert.

Unabhängig vom Adapter muss der callback aktiviert sein, um die Status Änderung vom Nuki zu empfangen.

[Brati]

@Zefau es war vorher eingeschaltet und der Adapter steht auf alle 5min periodisch aktualisieren.

[Zefau]

Hallo zusammen,

Hab mir gerade den Nuki Opener gekauft. Im Zuge dessen habe ich einen 30 EUR Gutschein erhalten, den ich weitergeben darf. Sofern dieser genutzt wird, erhalte ich einen Nuki Fob.

Gerne PN an mich, wenn jemand den 30 EUR Gutschein haben möchte.

Viele Grüße
Zefau

[locke987]

Hallo,

Ich hab jetzt auch beide Adapter (nuki --> 1.0.7 und nuki 2.0 --> 1.0.4) ausprobiert. Zuerst mal vielen Dank an smaragdschlange und zefau - super was ihr da auf die Beine gestellt habe! Ich hoffe ihr könnt mir bei meinen Problemen ein bisschen weiter helfen.
Ich hab ein Nuki Lock 2.0 + Bridge im Einsatz. Letzte Firmware beim Lock und der Bridge ist eingespielt.
Ich steuere über eine Homematic Schlüsselanhänger Fernbedienung das nuki lock. Dazu frage ich über ein Blockly Skript die Tasten der Fernbedienung ab und steuere dann entsprechend über die die jeweiligen Adapter Objekte das Nuki lock. Im Prinzip funktioniert das auch, aber bei beiden Adaptern nicht ganz so wie ich es gerne hätte:
Auffällig ist, dass über Callback erst nach ca. 20 Sekunden ein Update der Objekte passiert. Während diesem Zeitpunkt kann man über die rest api nicht auf die Bridge verbinden:

>curl -s http://x.x.x.x:8080/info?token=12324567
HTTP 503 Unavailable

Wenn die Bridge gerade nichts zu tun hat bekomme ich mit dem gleichen command den erwarteten output:

>curl -s http://x.x.x.x:8080/info?token=1234567
{"bridgeType": 1, "ids": {"hardwareId": 427126026, "serverId": 28737326}, "versions": {"firmwareVersion": "2.2.13", "wifiFirmwareVersion": "2.0.0"}, "uptime": 452, "currentTime": "2019-09-14T15:05:01+00:00", "wlanConnected": true, "serverConnected": true, "scanResults": [{"deviceType": 0, "nukiId": 447733957, "name": "Nuki_1AAFE0C5", "rssi": -61, "paired": true}]}

Scheinbar ein Problem mit der rest api die Schwierigkeiten hat mit mehr als einem command umzugehen.

Wenn ich also erfolgreich mein Schloss locke oder unlocke und dann die oben erwähnten ca. 20sek. nicht abwarte dann funktioniert der command nicht und es gibt es einen error im debug Log vom iobroker --> beim Adapter von smaragdschlange schaut das so aus:

2019-09-14 19:56:47.054  - error: nuki.0 null

Beim Adapter von zefau steht das drinnen:

2019-09-14 10:10:47.862  - debug: nuki2.0 503 - "HTTP 503 Unavailable"

Wenn ich dann noch ein bisschen zuwarte geht es beim erneuten Drücken des Buttons dann meistens wieder.
Was ich aber auch gesehen habe ist, dass durch zu schnelles wiederholtes drücken die Bridge scheinbar komplett überfordert ist und dann erst nach einer gefühlten Ewigkeit (Minuten) meist den letzten Befehl ausführt und dann manchmal wieder normal funktioniert. Es kommt teilweise scheinbar auch zu automatischen reboots der bridge wie man an der niedrigen uptime erkennen kann. Teilweise habe ich den jeweiligen Adapter auch restarten müssen damit es wieder funktioniert.

In Summe ist mir die Steuerung über die rest api zu langsam und instabil, mit Handy App und Bluetooth (ich nehme an auch über FOB den ich aber nicht habe) geht das alles deutlich schneller und auch stabiler.

Frage an die Runde: Kennt Ihr das auch so? Oder gibt's eine Lösung für mein Problem?
Ist das ein Verhalten dass eventuell nur mit dem 2.0 nuki lock auftritt?
Habt ihr Ideen was ich ausprobieren könnte oder generell anders machen kann?

Danke Euch für Euren Input!

[Zefau]

@locke987 zum Verständnis: die Aktion die du ausführst und die die Bridge scheinbar blockieren werden von den Adaptern geschickt? Oder auch wenn du die Smartphone App nutzt?

Du hast das Problem demnach nicht, wenn du eine Aktion über curl schickst und danach auch direkt mit curl den Status abrufst?

[Zefau]

@locke987 es gibt in Entwickler Forum eine ernüchternde Diskussion: https://developer.nuki.io/t/random-http-503-unavailable/909?u=zefau

[Zefau]

@locke987 Vote für MQTT Support in der Nuki Bridge, das würde das Problem beheben: https://developer.nuki.io/t/nuki-bridge-mqtt-support/2498

[locke987]

Danke für Deine Mühe...

@Zefau said in [Neuer Adapter] Nuki:

@locke987 zum Verständnis: die Aktion die du ausführst und die die Bridge scheinbar blockieren werden von den Adaptern geschickt? Oder auch wenn du die Smartphone App nutzt?

Du hast das Problem demnach nicht, wenn du eine Aktion über curl schickst und danach auch direkt mit curl den Status abrufst?

Die Aktionen kommen nur vom iobroker über Skripte die die Objekte in den Adaptern steuern, mit der Smartphone App geht es schnell und stabil. Ob es einen Unterschied gibt wenn ich über curl schicke und danach den Status abfrage muss ich erst checken.

@Zefau said in [Neuer Adapter] Nuki:

@locke987 es gibt in Entwickler Forum eine ernüchternde Diskussion: https://developer.nuki.io/t/random-http-503-unavailable/909?u=zefau

Ja, habe ich schon gesehen....

@Zefau said in [Neuer Adapter] Nuki:

@locke987 Vote für MQTT Support in der Nuki Bridge, das würde das Problem beheben: https://developer.nuki.io/t/nuki-bridge-mqtt-support/2498

ich hab schon gevoted

[locke987]

@Zefau said in [Neuer Adapter] Nuki:

@locke987 zum Verständnis: die Aktion die du ausführst und die die Bridge scheinbar blockieren werden von den Adaptern geschickt? Oder auch wenn du die Smartphone App nutzt?

Du hast das Problem demnach nicht, wenn du eine Aktion über curl schickst und danach auch direkt mit curl den Status abrufst?

Ich habe folgendes getestet:

>curl http://x.x.x.x:8080/lockAction?nukiId=447733957?deviceType=0?action=2?token=1234567
{"success": true, "batteryCritical": false}
>curl http://x.x.x.x:8080/lockState?nukiId=447733957?deviceType=0?token=1234567
HTTP 503 Unavailable
>curl http://x.x.x.x:8080/lockState?nukiId=447733957?deviceType=0?token=1234567
HTTP 503 Unavailable
>curl http://x.x.x.x:8080/lockState?nukiId=447733957?deviceType=0?token=1234567
HTTP 503 Unavailable
>curl http://x.x.x.x:8080/lockState?nukiId=447733957?deviceType=0?token=1234567
HTTP 503 Unavailable
>curl http://x.x.x.x:8080/lockState?nukiId=447733957?deviceType=0?token=1234567
HTTP 503 Unavailable
>curl http://x.x.x.x:8080/lockState?nukiId=447733957?deviceType=0?token=1234567
HTTP 503 Unavailable
>curl http://x.x.x.x:8080/lockState?nukiId=447733957?deviceType=0?token=1234567
HTTP 503 Unavailable
>curl http://x.x.x.x:8080/lockState?nukiId=447733957?deviceType=0?token=1234567
HTTP 503 Unavailable
>curl http://x.x.x.x:8080/lockState?nukiId=447733957?deviceType=0?token=1234567
{"mode": 2, "state": 1, "stateName": "locked", "batteryCritical": false, "success": true}

Zeitraum für obige commands entspricht auch ca. 20 Sekunden....
Ist also das selbe verhalten wie wenn man es über Skripte/Adapter triggert.
Hast Du die alte nuki Hardware version 1.0 im Einsatz? Verhält sich das genau so?