[Modul] Nuki Bridge - Elektronisches Türschloss und Opener mittels Bridge HTTP API

Nabend,

ich nutze zur Bridge-Erkennung die Vorgabe aus der API:

  1. Bridge discovery & API activation

Calling the URL https://api.nuki.io/discover/bridges returns a JSON array with all bridges which have been connected to the Nuki Servers through the same IP address than the one calling the URL within the last 30 days. The array contains the local IP address, port, the ID of each bridge and the date of the last change of the entry in the JSON array.

3.1 Example

{
"bridges": [

{ "bridgeId":2117604523,"ip":"192.168.1.50","port":8080,"dateUpdated":"2017-06-14

T06:53:44Z" }

],

"errorCode":0 }

Once a bridge has been discovered on the LAN the API can be activated and the API token retrieved by calling the /auth command. The user has to confirm this request by pressing the button on the bridge. For more details see the description of the /auth command. Alternatively you can activate the API and set the token by managing the Bridge in the Nuki App.

If discovery is disabled via /configAuth or through the Nuki App, the IP is 0.0.0.0 and the port 0. In this case the /auth command fails with HTTP error 403.

Da habe ich keinen Einfluß drauf. Mit mDNS kann ich die Bridge im Netz nicht finden.
Mal sehen, welche Alternativen es gibt.

Uli

Alles klar. Dann hängt das mit der externen IP zusammen. Und bei mir kann es sein, dass IPS gerade über den mobilen Router rausgeht. Dieser hat keine öffentliche IP Adresse, sondern eine private vom Mobilfunkanbieter. Da haben viele Anwender, die selbe externe IP. Somit könnte es sein, dass ein anderer User, der über den selben Anbieter einsteigt und auch ein Nuki mit aktivierter API hat, mir seine Bridge präsentiert. Sehr viele „wenns“ aber theoretisch möglich.

Wo hab ich da den Wurm drin? Bei mir sieht das so aus:
Bildschirmfoto 2022-03-12 um 11.43.39

Scheinbar steh ich grad mächtig auf der Leitung :frowning:

Danke und Gruss Seppm

Hi Seppo,

ich vermute du nutzt das Nuki Opener Modul aus der „alten“ NUKI Bibliothek.

Du musst das Nuki Opener Modul aus der Bibliothek Nuki Bridge nutzen.

Alle Module aus dieser Bibliothek haben immer einen Namenszusatz (Bridge API).

Bildschirmfoto 2022-03-12 um 12.27.29

Es gibt dann noch eine weitere Bibliothek „Nuki Web“ die nutzt aber die Web API, in dieser ist das Klingeln nicht vorgesehen.

Prüfe bitte nochmals, welche Bibliotheken (Module Store) du installiert hast. Du kannst auch beide parallel betreiben, musst aber dann die Nuki Opener (Bridge API) Instanz installieren.

Uli

1 „Gefällt mir“

ja so wars. Dachte zwar explizit ich hätte das neue genommen, aber denkste.
Jetzt passt alles!

Danke und Gruss Seppm

  • IP Adresse OK?
  • Bridge mit WLAN verbunden?
  • Symcon im gleichen Subnetz wie die Bridge?
  • HTTP API in der NUKI App (iPhone/Android) aktiviert?

Alternativ kannst du auch den API token im Entwicklerbereich der Bridge Instanzkonfiguration manuell angeben.

Token angeben und auf Übernehmen klicken.

Uli

Moin,
ich habe gerade das Modul installiert und die Funktionen migriert.

Aber bei mir ist die aktuallsierung Sau langsam. Es dauert ca. 5 minuten bis das neue Modul merkt das sich was geändert hat.
Das alte Modul meldet Syncon zur App das die Tür offen ist. Beim neuen Modul sind es knapp 5 minuten.
Ich habe „Nuki Smart Lock (Bridge API)“ und „Nuki Splitter Bridge API“ Status autoamtisch aktualsieren an.

Hilft aber nix.
Gibt es da einen Trick? Oder muss ich das alte Modul komplett runterwerfen - mögen die sicht nicht?

danke

Kannst du mal bitte die Callbacks auf der Bridge prüfen, ob die Daten stimmen und eine Bridge Callback Simulation durchführen:

Mit einem curl Befehl kann der Callback einer Nuki Bridge im Rahmen einer Entwicklungsumgebung simuliert werden.
Für den normalen Gebrauch oder Einsatz der Nuki Bridge ist der curl Befehl nicht notwendig.
Für die Verwendung von curl über die Konsole des entsprechenden Betriebssystems informieren Sie sich bitte im Internet.

curl -v -A "NukiBridge_12345678" -H "Connection: Close" -H "Content-Type: application/json;charset=utf-8" -X POST -d '{"nukiId": 987654321, "state": 1, "stateName": "locked", "batteryCritical": false}' http://127.0.0.1:3777/hook/nuki/bridge/12345
  • NukiBridge_12345678 ist die ID der Nuki Bridge
  • nukiId: 987654321 ist die ID des Nuki Smart Locks
  • http://127.0.0.1:3777/hook/nuki/bridge/12345 ist die IP-Adresse und Port des IP-Symcon Servers inkl. Webhook
  • 12345 ist die Objekt ID der Nuki Bridge in IP-Symcon

Ebenfalls mal die Webhooks unter IP-Symcon.
Zusätzlich kannst du das Debug Fenster der Bridge Instanz öffnen, um zu sehen, wann die Daten eingehen.

Eigentlich können die zwei Module unabhängig voneinander betrieben werden.

Ich kann frühestens am nächsten Wochenende es bei mir prüfen. Ansonsten lösche das „neue“ Modul erstmal, wenn es bei deinem Zustand bleiben sollte.

Ich schaue parallel mal im Nuki Forum, ob es dort ähnliche Nachfragen gibt.

Gut zu wissen wäre noch deine Geräte und Installationsumgebung: Windows, Linux, Docker, SymBox und welcher Versionsstand.

Uli

Hi, das war der entscheidene Tipp.
Mein IP-Symcon Server hat zwei IP Adressen. eine im Smart Home und eine im normalen LAN.
Die Webookrückmeldung sollte raus aus dem SmartHome netz ins „normale“ Netz. Das fand die Firewall jetzt nicht so gut.
Ich habe in deinem Modul die webook Adresse auf die IP im Smarthome Netzwerk geändert, nun ist das neue Modul noch 2 Sekunden langsamer als das alte. Damit komme ich gut klar!

vielen Dank!

Hi Uli,

NUKI stellt im Juli die Bridge-API um und führt ein neues Verfahren zur Absicherung der Requests ein. Die bisherigen Hashed Token bleiben vorerst erhalten, sollen aber früher oder später aus der API entfernt werden, wovon dann auch dieses Modul betroffen sein wird. Nur damit du die Info schon mal hast, falls du es noch nicht mitbekommen hast.

Details zum neuen verschlüsselten Token findest du hier: Bridge Beta FW 1.22.1 / 2.14.0 with new Encrypted Bridge HTTP API token - Nuki Bridge Beta - Nuki Developers

Gruß
Slummi

1 „Gefällt mir“

Hi Slummi,

habe ich gestern Abend bereits überflogen. Wird irgendwann kommen, aber nicht innerhalb der nächsten drei Wochen.

Danke für deinen Hinweis.

Uli

2 „Gefällt mir“

@Slummi
@Dustin723

Im Beta Kanal im Module-Store gibt es eine neue beta Version des NUKI Bridge Moduls:
2.0-4
Unterstützung für verschlüsselten API Token, ersetzt den hashed Token.

ACHTUNG!:
Für den verschlüsselten API Token (encrypted API token) wird nachfolgende Firmware der Bridge benötigt:

Bridge 1.0, min. Beta 1.22.1
Bridge 2.0, min. Beta 2.14.0

Diese ist im Moment im beta Stadium bei NUKI.
Wer die beta Firmware ausprobieren möchte, hier geht es weiter bei NUKI Bridge Beta Firmware

Solange die NUKI Firmware beta ist bleibt auch das Modul im beta Kanal. Sobald die Firmware für alle verfügbar ist, werde ich die Änderungen zur Revision einreichen.

Die alte „hashed Token“ Methode wird nicht mehr unterstützt.

Freue mich über Rückmeldungen.

Uli

2 „Gefällt mir“

Ich wollte eigentlich gestern die Beta des Moduls testen, bin vorher aber auf ein Problem mit der Stable gestoßen, welches ich erst lösen musste.

Das Modul wollte mit einer meiner Bridges plötzlich einfach nicht mehr zusammen arbeiten. Egal welchen Request ich an die Bridge geschickt habe, es kam nach 5 Sekunden immer ein HTTP 503. Das einzige was problemlos funktionierte, war das Callback-Interface. Eine andere Bridge lief derweil problemlos weiter mit dem Modul.

Ich dachte erst die Bridge hätte sich vielleicht aufgehangen (obwohl das Callback wie gesagt funktionierte und über die Nuki-App arbeitete die Bridge auch einwandfrei). Also habe ich mal einen Power-Off-Reset gemacht. Nach dem Booten aber das gleiche Thema. Das Modul wollte weiterhin nicht richtig mit der Bridge reden.

Ich habe mir dann mal das Debug angesehen und auf jedes SendDataToParent (was ständig wiederholt wurde) kam nach 5 Sekunden ein „Aborted. Semaphore Reached.“ Und dann folgte der Response mit HTTP 503. Ich dachte, dass die Bridge vielleicht aus irgendeinem Grund zu spät antwortet. Daher habe ich mal den Timeout in der Instanz hoch gesetzt. Trotzdem kam weiterhin immer nach 5 Sekunden besagte Fehlermeldung.

Ich habe dann versucht den Dienst zu beenden, was jedoch ebenfalls scheiterte, weil er endlos auf die Beendigung irgendeines Threads gewartet hat. Ich vermute, dass das was vom Modul war, aber sicher bin ich mir nicht. Ich konnte das im Nachgang leider nicht mehr herausfinden. Nachdem ich den Prozess gekillt und IPS neu gestartet habe, liefen wieder beide Bridges problemlos.

@ubittner Wann genau bringt das Modul denn die Meldung „Aborted. Semaphore Reached.“? Kommt das immer, wenn nach dem eingestellten Timeout keine Antwort von der Bridge kommt oder resultiert das woanders her? Und das HTTP 503 kommt das wirklich als Antwort von der Bridge oder erzeugt das Modul den Fehlercode intern, nach dem erreichen des Timeouts? Mir kam es eher wie letzteres vor, da es wirklich immer exakt 5 Sekunden waren. Eigenartig fand ich, dass die geänderte Einstellung des Timeouts nichts an dem 5 Sekunden Intervall für die Debug-Meldung geändert hat.

Nur für den Fall, dass es wieder mal auftreten sollte, wäre es für die weitere Analyse hilfreich zu wissen, wie sich das Modul hier verhält.

Da jetzt erst mal wieder alles funktioniert, werde ich die Beta mal testen. Die neue Bridge-Firmware ist inzwischen übrigens offiziell released. Aber der alte Hashed Token wird ja erst mal weiter von der Bridge unterstützt, sodass wir keinen Stress mit dem Testen haben.

Die Implementierung des encrypted Token scheint auf den ersten Blick reibungslos zu funktionieren.
Wirklich klasse, wie schnell du das implementiert hast! :+1:t3:

Falls mir doch noch was auffällt, melde ich mich.

1 „Gefällt mir“

Guten Morgen,

In der Vergangenheit war es ja so, dass die Bridge mehrere Schaltbefehle innerhalb kürzester Zeit nicht abarbeiten konnte. NUKI empfiehlt:

Why do i repeatdly get an Error 503 when calling the Bridge API
The Bridge can only handle one incoming request at a time and you therefore have to serialize repeated requests to the Bridge API.

Dies betrifft dann die Fehlermeldung:

503 Service Unavailable
Another request already running on the device
Increase intervals between API calls sent to the Bridge as it can only handle one request at a time.

Ich habe im Modul versucht dies mit Semaphore abzufangen. Jeder Schaltbefehl betritt den Semaphore und verlässt diesen auch wieder.

Hier scheint es so zu sein, dass aus einem mir noch nicht bekannten Grund der Semaphore nicht ordentlich verlassen wird, bzw. die Bridge nicht antwortet. Dann gebe ich auch 503 zurück.
Ich hatte dieses Phänomen auch einmal, als ich Bridge über das Modul mit dem Firmwareupdate angestoßen habe. Musste auch Symcon einmal neu starten, damit alles wieder aktiv war. Unschön.

serialize repeated requests

Hier muss ich noch eimal schauen ob Semaphore die richtige Wahl ist, den Semaphore Interval erhöhen muss oder ich eine „Queue“ bauen muss.

Prima, dass es klappt. Nochmals der Hinweis: in der jetzigen Beta Version gibt es den hashed Token nicht mehr. Er wurde durch den neuen crypted Token ersetzt.

Uli

Guten Morgen,

Ja, das ist mir bekannt. Falls das noch mal auftreten sollte, werde ich mal manuell versuchen, die HTTP-API via curl anzusteuern. Ich glaube nämlich nicht, dass das hier das Problem war und die Bridge mit der Abarbeitung nicht hinterher kam. Dann hätte ich auch andere Probleme mit der Bridge erwartet und es hätte nach dem Power-Off-Reset der Bridge wieder funktionieren müssen.

Das vermute ich auch. Das erklärt auch, warum nach genau 5 Sekunden immer der Status kam. Ich habe mir schon gedacht, dass das kein realer Status der Bridge ist, der dort ausgegeben wird.
Habe gerade mal einen schnellen Blick in den Code geworfen. Eigentlich kann das Script dann ja nur im curl-Teil hängen geblieben sein. Oder das IPS_SemaphoreLeave() wurde aus irgendeinem Grund nicht erfolgreich durchgeführt. Ich überlege gerade ob es Sinn macht:

a) Den Rückgabewert von IPS_SemaphoreLeave() mit auszuwerten und bei einem FALSE (wodurch auch immer das zustande kommen könnte) entsprechend zu reagieren.

b) Eine Umgehung für den Notfall zu bauen, die dafür sorgt, dass der Semaphor nach Ablauf einer gewissen Zeit in jedem Fall wieder aufgehoben wird, da das Modul sonst im Fehlerfall für die jeweilige Instanz bis zum nächsten Neustart des Dienstes tot ist. Denn mit der aktuellen Implementierung gibt es keinerlei Möglichkeit, ein einmal fehlgeschlagenes IPS_SemaphoreLeave() jemals wieder zu erreichen.

c) Den Timeout für den Semaphore in Abhängigkeit der Timeout-Property zu setzen. Das dürfte zwar nicht die Ursache für das Problem sein, würde aber bei einem hohen eingestellten Timeout (z.B. 10 Sekunden) dazu führen, dass ein zwischenzeitlich abgesetzter neuer Befehl in jedem Fall scheitert - vorausgesetzt die Bridge benötigt für ihre Antwort wirklich länger als die fixen 5 Sekunden.

Warum sich der IPS-Dienst während des Promles nicht beenden ließ, ist mir aktuell noch ein Rätsel. Dass ein Thread des Moduls komplett hängen geblieben ist, würde ich eigentlich ausschließen. Denn ich sehe im Monitoring keinen Thread, der länger als normal gelaufen wäre und ich habe relativ lange auf den Shutdown gewartet bis ich den Dienst am Ende gekillt habe. Das wird also irgendwas anderes gewesen sein. Wäre ganz hilfreich, wenn man im Nachgang noch über die Logs feststellen könnte, auf welche Scripts IPS beim Beenden (vergeblich) gewartet hat.

@paresy Kann man diese Info nicht irgendwie mit ins Log schreiben?
Also diese Loge-Einträge mit zusätzlichen Informationen anreichern, welche Skripte / Module aktuell noch laufen, auf die gewartet wird?

Warte auf Beendigung aller Skript-Threads...

Skripte können nicht gestartet, sobald Abschaltung eingeleitet wurde

Aktion konnte für Ereignis #123450 nicht ausgeführt werden: Skripte können nicht gestartet, sobald Abschaltung eingeleitet wurde

Weiß jemand, ob es Auswirkungen auf den Shutdown hat, wenn zwar kein Skript mehr läuft, aber noch irgendwo ein Semaphor gesetzt ist? Würde das ebenfalls das Herunterfahren des Dienstes verhindern?

Ich werde das mal weiter beobachten. Falls es noch mal auftritt, versuche ich noch weitere Daten zu sammeln, die bei der Ursachenfindung helfen könnten. Aber bisher war das wirklich die Ausnahme. War glaube ich erst das zweite Mal seit ich das Modul nutze, dass da was komplett hängen geblieben ist.

Gruß
Slummi

Das ist nicht möglich. Gesetze Semaphoren werden am Ende des Skripts immer freigegeben und mit einer gelben Meldung im Log quittiert, wenn du nicht korrekt gearbeitet hast.

paresy

Hallo,

kleine Verständnis Frage: Mit einem Nuki Smart Lock 3.0 Pro brauche ich keine separate Bridge da diese integriert ist?

Oder ist sie für das Modul zwingt Notwendig?

Dank im Voraus.

Mit freundlichen Grüßen,
DATA78Lux

ein ganz klares JEIN :slight_smile:

Für die Integration des SL gibt es für IPS zwei Module:

Nuki Bridge:
Hier brauchst du auch für das Pro eine Bridge, da zur Zeit die Bridge API auf dem Pro nicht zur Verfügung steht.

Hinweis : Die Bridge-API wird vom integrierten WLAN Modul des Smart Locks 3.0 Pro NICHT unterstützt. Um die Bridge API verwenden zu können, verbinde dein Smart Lock 3.0 Pro mit der Nuki Bridge. Auf diese Weise erhältst du alle Nutzungsmöglichkeiten.

Nuki Web:
Dies ist die „Cloud Anbindung“ des SL. Ich selber habe leider zur Zeit kein Pro, so dass ich definitiv nicht sagen kann, ob dies funktioniert.

Fazit:
Wenn du es in IPS local einbinden willst brauchst du zur Zeit auch für das Pro eine Bridge.

Uli

1 „Gefällt mir“

Guten Morgen Zusammen,
ich hatte heute morgen vor vom „alten“ Nuki-Modul auf das neue „Nuki-Bridge“-Modul umzusteigen. Die Discovery hat auch beide Bridges erkannt, ich konnte die Token abrufen durch drücken des Knopfes an der Bridge. Beim Anlegen der SL weiß ich jetzt aber net so genau, was ich machen muss - da ist alles doppelt und dreifach drin beim Anlegen der Instanz:
image
image

Über den Modul-Store sieht man, das was ich instelliert habe:

Hat jemand einen Tipp für mich?
LG Dennis.