Test Adapter Nuki-extended v2.0.x

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?

Zefau

@locke987 habe ebenfalls den Nuki 2. Habe das Problem aber bisher nicht festgestellt.

Nutzt du die Callbacks? Du musst ja eigtl nicht direkt nach lockState die Information abrufen, da du die ja über den Callback bekommst?

locke987

@Zefau said in [Neuer Adapter] Nuki:

@locke987 habe ebenfalls den Nuki 2. Habe das Problem aber bisher nicht festgestellt.

Nutzt du die Callbacks? Du musst ja eigtl nicht direkt nach lockState die Information abrufen, da du die ja über den Callback bekommst?

Ja ich nutze die callbacks, und die funktionieren in der Regel auch, die callbacks dauern mit Deinem Adapter auch gar nicht so lange (ca. 10 Sek).
Mich würde interessieren was bei Dir passiert wenn Du zu schnell hintereinander lock/unlock Befehle über den Adapter schickst.
Also z.B.: Zustand des locks ist unlocked, du schickst den Befel lock, du hörst den Sperrvorgang, kurz nachdem der Sperrvorgang akustisch abgeschlossen ist schickst Du einen unlock Befehl.

Bei mir schaut das im debug Log dann so aus (http 503 error):

nuki2.0	2019-09-15 08:35:09.857	debug	Updating lock door__eingangstür with payload: {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":4
nuki2.0	2019-09-15 08:35:09.857	debug	updateLocks(): {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":48.28686,"longitude":16.107248,"
nuki2.0	2019-09-15 08:35:09.258	info	Successfully triggered action -UNLOCK- on Nuki Eingangstür.
nuki2.0	2019-09-15 08:35:01.758	debug	Action applied on Bridge API.
nuki2.0	2019-09-15 08:35:01.758	info	Triggered action -UNLOCK- on Nuki Eingangstür.
nuki2.0	2019-09-15 08:35:01.758	debug	State of nuki2.0.door__eingangstür.action has changed {"val":0,"ack":true,"ts":1568529301753,"q":0,"from":"system.adapter.nuki2.0","user":"system.user.admin","lc":1568529301753}.
nuki2.0	2019-09-15 08:35:01.753	debug	State of nuki2.0.door__eingangstür.action has changed {"val":1,"ack":false,"ts":1568529301750,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1568529301750}.
nuki2.0	2019-09-15 08:34:59.854	debug	Updating lock door__eingangstür with payload: {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":4
nuki2.0	2019-09-15 08:34:59.853	debug	updateLocks(): {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":48.28686,"longitude":16.107248,"
nuki2.0	2019-09-15 08:34:51.268	debug	503 - "HTTP 503 Unavailable"
nuki2.0	2019-09-15 08:34:51.267	warn	Error triggering action -UNLOCK- on Nuki Eingangstür. See debug log for details.
nuki2.0	2019-09-15 08:34:51.171	debug	Action applied on Bridge API.
nuki2.0	2019-09-15 08:34:51.170	info	Triggered action -UNLOCK- on Nuki Eingangstür.
nuki2.0	2019-09-15 08:34:51.164	debug	State of nuki2.0.door__eingangstür.action has changed {"val":0,"ack":true,"ts":1568529291159,"q":0,"from":"system.adapter.nuki2.0","user":"system.user.admin","lc":1568529291159}.
nuki2.0	2019-09-15 08:34:51.163	debug	State of nuki2.0.door__eingangstür.action has changed {"val":1,"ack":false,"ts":1568529291155,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1568529291155}.
nuki2.0	2019-09-15 08:34:49.837	debug	Updating lock door__eingangstür with payload: {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":4
nuki2.0	2019-09-15 08:34:49.837	debug	updateLocks(): {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":48.28686,"longitude":16.107248,"
nuki2.0	2019-09-15 08:34:48.281	debug	503 - "HTTP 503 Unavailable"
nuki2.0	2019-09-15 08:34:48.281	warn	Error triggering action -UNLOCK- on Nuki Eingangstür. See debug log for details.
nuki2.0	2019-09-15 08:34:48.165	debug	Action applied on Bridge API.
nuki2.0	2019-09-15 08:34:48.164	info	Triggered action -UNLOCK- on Nuki Eingangstür.
nuki2.0	2019-09-15 08:34:48.159	debug	State of nuki2.0.door__eingangstür.action has changed {"val":0,"ack":true,"ts":1568529288155,"q":0,"from":"system.adapter.nuki2.0","user":"system.user.admin","lc":1568529288155}.
nuki2.0	2019-09-15 08:34:48.155	debug	State of nuki2.0.door__eingangstür.action has changed {"val":1,"ack":false,"ts":1568529288150,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1568529288150}.
nuki2.0	2019-09-15 08:34:40.755	debug	503 - "HTTP 503 Unavailable"
nuki2.0	2019-09-15 08:34:40.755	warn	Error triggering action -UNLOCK- on Nuki Eingangstür. See debug log for details.
nuki2.0	2019-09-15 08:34:40.651	debug	Action applied on Bridge API.
nuki2.0	2019-09-15 08:34:40.651	info	Triggered action -UNLOCK- on Nuki Eingangstür.
nuki2.0	2019-09-15 08:34:40.647	debug	State of nuki2.0.door__eingangstür.action has changed {"val":0,"ack":true,"ts":1568529280644,"q":0,"from":"system.adapter.nuki2.0","user":"system.user.admin","lc":1568529280644}.
nuki2.0	2019-09-15 08:34:40.644	debug	State of nuki2.0.door__eingangstür.action has changed {"val":1,"ack":false,"ts":1568529280641,"q":0,"from":"system.adapter.javascript.0","user":"system.user.admin","lc":1568529280641}.
nuki2.0	2019-09-15 08:34:40.158	debug	Updated state door__eingangstür.logs to value [{"id":"5d7ddb778519f29a434e7190","smartlockId":447733957,"deviceType":0,"name":"Nuki Bridge ","action":2,"trigger":0,"state":0,"autoUnlock":false,"date":
nuki2.0	2019-09-15 08:34:39.857	debug	Updated state door__eingangstür.status.lastAction to value 2 (from 1).
nuki2.0	2019-09-15 08:34:39.857	debug	Updating lock door__eingangstür with payload: {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":4
nuki2.0	2019-09-15 08:34:39.851	debug	updateLocks(): {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":48.28686,"longitude":16.107248,"
nuki2.0	2019-09-15 08:34:35.019	debug	Updated state door__eingangstür.status.locked to value true (from false).
nuki2.0	2019-09-15 08:34:35.019	debug	Updated state door__eingangstür.status.lockState to value 1 (from 3).
nuki2.0	2019-09-15 08:34:35.018	debug	Updated state door__eingangstür.status.refreshed to value Sun Sep 15 2019 08:34:35 GMT+0200 (GMT+02:00) (from Sun Sep 15 2019 08:33:37 GMT+0200 (GMT+02:00)).
nuki2.0	2019-09-15 08:34:35.012	debug	Updating lock door__eingangstür with payload: {"nukiId":447733957,"state":{"state":1,"batteryCritical":false,"timestamp":"2019-09-15T06:34:35.008Z"}}
nuki2.0	2019-09-15 08:34:35.011	debug	Received payload via callback: {"deviceType":0,"nukiId":447733957,"mode":2,"state":1,"stateName":"locked","batteryCritical":false}
nuki2.0	2019-09-15 08:34:31.625	info	Successfully triggered action -LOCK- on Nuki Eingangstür.
nuki2.0	2019-09-15 08:34:29.844	debug	Updating lock door__eingangstür with payload: {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":4
nuki2.0	2019-09-15 08:34:29.843	debug	updateLocks(): {"smartlockId":447733957,"accountId":241889230,"type":0,"authId":3431665,"name":"Eingangstür","favorite":false,"config":{"name":"Eingangstür","latitude":48.28686,"longitude":16.107248,"
nuki2.0	2019-09-15 08:34:24.156	debug	Action applied on Bridge API.
nuki2.0	2019-09-15 08:34:24.156	info	Triggered action -LOCK- on Nuki Eingangstür.

Aufgefallen ist mir bei Deinem Adapter, dass über den callback die Werte relativ schnell zurückkommen (ca. 10 Sek), wenn ich zum Beispiel nach dem Zustand "lockstate" in meinem Skript prüfe so bekomme ich dann z.B.: den Zustand locked zurück, darf aber trotzdem über "action" noch nicht den Zustand unlock herbei führen da ich sonst wieder einen http 503 bekomme....man muss nochmal ca. 10 Sek. warten.
Beim Adapter von smaragdschlange dauert der callback länger (ca. 20 Sek.), wenn die Werte sich ändern kann man dann auch unmittelbar danach auch ein command absetzen.

Bei deinem Adapter bewirkt das zu schnelle drücken hintereinander dann auch manchmal, dass der Zustand des locks über den callback nicht geändert wird. Der steht dann der "lockstate" auf lock anstatt unlock und das kann man scheinbar nur durch ein stoppen und neustarten des Adapters wieder bereinigt werden.

Warum ist das alles ein Problem? Man schließt ja nicht dauern ab und gleich wieder auf etc.
Ich möchte mit iobroker in Verbindung mit nuki auch andere Dinge steuern wie die Alarmanlage, Türklingel etc. und da ist das timing schon wichtig. Und wenn man mal unabsichtlich (und ich hab auch kleine Kinder
) und eventuell kurz hintereinander eine Taste auf der Fernsteuerung drückt sollte sich die sch*** Bridge nicht aufhängen.

Sandmanyz

@locke987 sagte in [Neuer Adapter] Nuki:

Bei deinem Adapter bewirkt das zu schnelle drücken hintereinander dann auch manchmal, dass der Zustand des locks über den callback nicht geändert wird. Der steht dann der "lockstate" auf lock anstatt unlock und das kann man scheinbar nur durch ein stoppen und neustarten des Adapters wieder bereinigt werden.

Das ist beim Adapter von @smaragdschlange auch der Fall. Wenn ich die Garagentür öffne, durchgehe und direkt hinter mir wieder schließe, wird der Öffnungsvorgang erfasst. Das anschließende Verschließen jedoch nicht. Solange zwischen dem Öffnen und Schließen genug Zeit vergeht, ändert sich der Status im Adapter.

Zefau

@Sandmanyz sagte in [Neuer Adapter] Nuki:

Wenn ich die Garagentür öffne, durchgehe und direkt hinter mir wieder schließe, wird der Öffnungsvorgang erfasst. Das anschließende Verschließen jedoch nicht. Solange zwischen dem Öffnen und Schließen genug Zeit vergeht, ändert sich der Status im Adapter.

Das Öffnen und Schließen beides mit dem Adapter? Und beim Schließen liefert der Callback falsche Informationen oder gibt der einen 503 Fehler?

Im zweiten Fall könnte man einen Loop einbauen, der nach 10s wieder neu abfragt.

locke987

Ich hab mich heute wieder mal ein bisschen herumgespielt.

Die Callback Funkton in Verbindung mit der nuki bridge verstärkt die Probleme mit der rest api.
Wenn Callback aktiv ist reagiert die rest api über /lockaction Befehle ziemlich empfindlich.
Wenn man die lock/unlock Befehle zu schnell hintereinander absetzt kommen die schon erwähnten http 503 Fehler oder die rest api reagiert überhaupt nicht oder commands werden stark verzögert ausgeführt. Das hat überhaupt nichts mit den Adaptern zu tun - ich hab es mit deaktivierten Adaptern und curl ausgetestet.

Wenn man alle bestehenden callbacks deaktiviert und die Liste leer ist:

curl -s http://1.1.1.1:8080/callback/list?token=1234567

dann brauch man zwischen den lock/unlock Befehlen eigentlich nur 1-2 Sek. warten und das lock sperrt wie es soll, keine 503 Fehler etc.

Ohne callback und damit ohne aktualisierten Stati von nuki im iobroker macht das alles aber leider wenig Sinn....manuelle Abfragen über die Adapter nach einer gewissen Zeitspanne sind mir zu wenig aktuell um sie für meine Zwecke zu verwenden.

locke987

@Zefau
Bei mir wird bei deinem Adapter bei deaktiviertem callback und der Konfig laut Screenshot zwar alle 15 Sekunden aktualisiert, es verändern sich aber nur wenige Werte, insbesonderes der Wert lockstate bleibt immer unverändert im Gegensatz zu lastAction. Siehe Screenshot 2 --> eigentlich ein Widerspruch. Sollte sich der lockstate updaten bei meinen Einstellungen?

Danke!

Zefau

@locke987 Danke für die Analyse. Probier mal die Version von Github bei aktiviertem Debug: https://github.com/Zefau/ioBroker.nuki2/tree/nuki2

locke987

@Zefau

Ich bekomme da Fehler beim installieren:

iobroker 2019-09-17 10:33:19.457 info exit 0
iobroker 2019-09-17 10:33:19.417 info npm ERR! A complete log of this run can be found in:npm ERR! /home/iobroker/.npm/_logs/2019-09-17T08_33_19_401Z-debug.log
iobroker 2019-09-17 10:33:19.416 info
iobroker 2019-09-17 10:33:19.409 info npm ERR! 404 tarball, folder, http url, or git url.
iobroker 2019-09-17 10:33:19.409 info npm ERR! 404 Note that you can also install from a
iobroker 2019-09-17 10:33:19.409 info npm ERR! 404
iobroker 2019-09-17 10:33:19.409 info npm ERR! 404 1. name can only contain URL-friendly charactersnpm ERR! 404 2. name can no longer contain capital letters
iobroker 2019-09-17 10:33:19.407 info 404 Your package name is not valid, because
iobroker 2019-09-17 10:33:19.392 info npm ERR!
iobroker 2019-09-17 10:33:19.392 info 404 npm ERR! 404 'https://github.com/Zefau/ioBroker.nuki2/tree/nuki2/tarball/master' is not in the npm registry.
iobroker 2019-09-17 10:33:19.390 info ERR!
iobroker 2019-09-17 10:33:19.388 info 404 Not Found - GET https://github.com/Zefau/ioBroker.nuki2/tree/nuki2/tarball/masternpm
iobroker 2019-09-17 10:33:19.386 info ERR!
iobroker 2019-09-17 10:33:19.384 info
iobroker 2019-09-17 10:33:19.383 info npm
iobroker 2019-09-17 10:33:19.375 info E404
iobroker 2019-09-17 10:33:19.373 info code
iobroker 2019-09-17 10:33:19.372 info ERR!
iobroker 2019-09-17 10:33:19.371 info
iobroker 2019-09-17 10:33:19.369 info npm
iobroker 2019-09-17 10:33:11.733 info npm install https://github.com/Zefau/ioBroker.nuki2/tree/nuki2/tarball/master --production --save --prefix "/opt/iobroker" (System call)
iobroker 2019-09-17 10:33:10.989 info install https://github.com/Zefau/ioBroker.nuki2/tree/nuki2/tarball/master
iobroker 2019-09-17 10:33:10.447 info url "https://github.com/Zefau/ioBroker.nuki2/tree/nuki2" --debug

Zefau

@locke987 liegt wohl am Branch. Ich hab's nochmal in den Master geladen. Probier mal bitte direkt https://github.com/Zefau/ioBroker.nuki2

locke987

@Zefau installieren konnte ich es, ich habe danach einen neue Instanz hinzugefügt und die alte Instanz deaktiviert, die Version ist laut iobroker noch die selbe, also 1.0.4
Sollte der lockstate jetzt aktualisiert werden bei deaktivierten callback oder was ist jetzt anders?

Zefau

@locke987 sagte in [Neuer Adapter] Nuki:

Sollte der lockstate jetzt aktualisiert werden bei deaktivierten callback oder was ist jetzt anders?

Trag mal im Reiter der Web Api eine Refresh Zeit ein. In der Version auf Github gilt diese auch für die Bridge. Design muss ich noch ändern.

Dann pollt er den Status regelmäßig ab.

locke987

@Zefau ja das funktionier jetzt ...lockstate wird so jetzt auch upgedated.
Danke Dir!

Frage zum Webadapter:
Was genau ist der Zweck des Webadapters? Es gibt ein paar mehr Objekte wie zum Beispiel doorstate richtig? Und wie werden diese Objekte dann upgedated? Ganz normal über die http appi und dem callback? Oder könnte man die WebApi auch alleine verwenden?

Zefau

@locke987 Die Web API liefert zusätzliche Informationen, beispielsweise Logs (damit wird auch das Interface aufgebaut, siehe https://forum.iobroker.net/assets/uploads/files/1553251416356-screenshot_2019-03-22-iobroker-nuki2.png), die gesamte Konfiguration und die berechtigten Benutzer - auch doorstate ist mit drin.
Die Web API hat keinen Callback. Dieser ist nur bei der Bridge API verfügbar. Die States werden über Polling geupdated.

Theoretisch kann man die Web API auch alleine verwenden, aber gerade das schicken von Aktionen macht über die Bridge API mehr Sinn.

locke987

@Zefau Danke für die Aufklärung!

NEWS

Test Adapter Nuki-extended v2.0.x

Support us

367

32.4k

81.4k

1.3m