Ah, darum hat meine Alexa immer aufgesperrt, wenn ich ihr „zusperren“ zugerufen hab … 
Man hält sich ja brav an die Anleitung. Daher hab ich den Fehler zuerst auf meiner Seite vermutet.
Habs dann am Abend noch gelassen und wollte heute mit der Fehlersuche weitermachen 
Wollte ja nur mal sehen, ob euch das auffällt 
Uli
RTFM
hab ich getan 
Mir ist es auch erst aufgefallen, nachdem ich komplett (auch die Skripte) auf das neue Modul umgestellt hatte und das Auf- und Abschließen plötzlich nicht mehr funktionierte und das Lock immer nur geleuchtet hat, ohne etwas zu tun.
Hatte schon angefangen den Code des Moduls auseinanderzupflücken. Dachte erst, dass vor der Ausführung des Befehls vielleicht der aktuelle Status des Locks geprüft wird. Und das Mapping der API-States auf die Modul-States war auch erst etwas verwirrend. Aber ich vermute, dass @ubittner das aus Kompatibilitätsgründen zum alten Modul gemacht hat.
Funktioniert es denn jetzt?
Uli
Ja klar, lag einfach daran, dass ich bei der Umstellung die Werte aus der Doku genommen habe.
Daher wollten meine Skripte ein offenes Lock immer erneut öffnen und ein geschlossenes Lock erneut schließen, was sich im Leuchten des Locks bemerkbar gemacht hat, da sich der Status nicht geändert hat.
Hab eben das Update eingespielt und er hat offenbar die Bridge verloren. Zumindest findet der Konfigurator sie nicht. Die war aber heute sicher da, da mir am Nachmittag - mit der vorigen Version - eine Bridge angezeigt wurde die gar nicht bei mir im Netz ist.
Ansonsten funktioniert aber alles.
Interessant. Jetzt wird wieder eine Bridge gefunden, die gar nicht da sein kann.
Meine Range ist 192.168.32.0/24
Servus,
mal eine Frage, vom Opener kann man nicht das „klingeln“ an der Sprechanlage vorm Haus bekommen? Das es klingelt muss der Opener ja wissen wenn er dann bei „RingToOpen“ die untere Haustür aufmacht.
Cheers Seppm
Nabend,
ich nutze zur Bridge-Erkennung die Vorgabe aus der API:
- 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:
Scheinbar steh ich grad mächtig auf der Leitung 
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).
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_12345678ist die ID der Nuki Bridge -
nukiId: 987654321ist die ID des Nuki Smart Locks -
http://127.0.0.1:3777/hook/nuki/bridge/12345ist die IP-Adresse und Port des IP-Symcon Servers inkl. Webhook -
12345ist 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“