Dokumentation Nuki Bridge API (Bluetooth Türschloss)

[Wolfgang67]

Habs mir jetzt nochmal angesehen:
Über die URL liefern alle 3 Schlösser "BatteryCritical"=false, über Loxone eines "OK", zwei "kritisch".
Konnte aber keinen Unterschied bei der Konfiguration der 3 Schlösser erkennen, außer dass das Schloss welches OK liefert über die Software-Bridge dran hängt und die beiden anderen Schlösser über eine gemeinsame Hardware-Bidge.

@Labmaster: Wo finde ich die "MS Input Konfig" und wie sollte die aussehen ?

[Wolfgang67]

Ich habe aktuell ein Problem mit einem meiner NUKI-Schlösser. Da die Software-Bridge über welche dieses Schloss bisher angesteuert wurde alle paar Tage neu gestartet werden musste, habe ich heute diese gegen eine Hardware-Bridge getauscht. Leider läuft es mit der neuen Bridge aber nicht und ich dreh mich bei der Fehlersuche im Kreis. :-(

Folgender Status:
1) Die App der Software-Bridge wurde beendet.
2) Die Hardware-Bridge wurde erfoldgreich eingerichtet (Fixe IP: 10.0.0.53, die SW-Bridge hatte 10.0.0.31)
Die API wurde aktiviert und als Token wurde mit "tuer67" die gleiche Zahlen-Ziffern-Kombination wie bei der Software-Bridge angegeben
3) Das NUKI-Schloss wurde mit der Hardware-Bridge erfolgreich verbunden.
4) Die NUKI-App zeigt im Verbindungsstatus eine Verbindung über die Bridge an und das Schloss lässt sich auch über die Bridge steuern (also ohne direkte Bluetooth-Verbindung)
5) In Loxone habe ich die IP-Adresse an folgenden beiden Stellen angepasst:
a) Beim virtuellen Eingang "NUKI-Haustüre" - URL
b) Beim virtuellen Ausgang "Nuki-Haustüre" - Adresse
Die ID des Schlosses und der Token hat sich ja nicht geändert.
Leider zeigt das Schloss aber "Undefinierter Fehler" :-(
6) Interessanterweise kommt auch bei direktem Auslesen der URL (http://10.0.0.53:8080/lockState?nuki...9&token=tuer67) nichts retour, aber auch keine Fehlermeldung

Was habe ich vergessen ?

-------- es läuft ! ---------------------------
---> Ich kanns kaum glauben, nachdem ich den ganzen Nachmittag Fehler gesucht habe und vor wenigen Minuten obige Nachricht hier rein geschrieben habe noch ein letzter Versuch die URL aufzurufen - Überraschung: Es kommen Werte zurück
Also gleich in die Loxone-App - und siehe da: Plötlich funktioniert das Schloss ganz normal
das ganze ohne, dass ich noch etwas geändert hätte !
--> Wundersame Heilung ??? - oder funktioniert die API erst nach einer längerem Startphase ?

Das oben beschriebene Problem mit dem falschen Batteriestatus ist aber noch aktuell

[Gast]

Die Reichweite von der Bridge zum Schloss ist ausreichend? (Spontane Bluetooth Abbrüche etc.)

[Labmaster]

Das mit der plötzlichen Funktion hatte ich ja auch schon beschrieben, siehe hier: https://www.loxforum.com/forum/germa...2434#post92434

Bezüglich Batteriestatus, kannst du mal Bilder der Loxone Config der 3 Virtuellen Batteriestatus Eingänge (von den drei Nukis) posten ?

Im übrigen, wenn das ganze mit neuerer API läuft (ab V1.5), und man zum abfragen die /list Funktion verwendet, dann stimmt gegebenfalls die Statusbaustein Tabelle der ursprünglichen Vorlage nicht mehr, da sich die Statuswerte geändert haben.
Ich hatte im Post vom oberen Link auch schon mal ein Bild mit angepasster Statusbaustein Tabelle angehängt. (nur die letze Spalte mit "Statuswert" anpassen)

[Wolfgang67]

@Labmaster: Danke für Deinen Hinweis bez. API-Version. Damit wäre das Problem nachvollziehbar,

Wo finde ich die Version der von mir verwendeten API ? Bei den Einstellungen der Bridge bzw. beim Lock konnte ich nichts finden. Die Locks sind auf der aktuellen V 1.4.5.
Müssen für die neuen API die Tabellen aller 3 Bausteine "Schließzustand", "Batteriestatus" und "kombinierter Status" angepasst werden ?

[Labmaster]

Die Api ist ja in der Bridge Firmware eingebaut, über den Update Befehl sollten sich auch ältere Firmwares der Hardwarebrige updaten lassen.
Über http://IP:8080/info?token=xxxxx sollte man die Versionen bekommen (Firmware, API ...)

Mit http://IP:8080/fwupdate?token=xxxxx sollte man (zumindest ab API Version 1.5) ein Firmwareupdate anstossen können, hierzu muss die Bridge so im Netzwerk konfiguriert sein, daß Internetzugang für die Bridge gewährleistet ist.

Siehe:
V1.5: https://nuki.io/wp-content/uploads/2...e-API-v1.5.pdf
V1.6: https://nuki.io/wp-content/uploads/2...e-API-v1.6.pdf

[Labmaster]

...
Müssen für die neuen API die Tabellen aller 3 Bausteine "Schließzustand", "Batteriestatus" und "kombinierter Status" angepasst werden ?...

Ohh, das hatte ich gar nicht mehr auf dem Plan, da ich nur den kombinierten Status verwenden, aus diesem geht doch eigentlich eh schon alles hervor was man benötigt.
Ich hatte die beiden etxra Status Tabellen von Anfang an NICHT implemeniert, denn über den AQ Ausgang des kombinierten Status war eine nachgeschaltete Auswertung für mich sowieso einfacher.

Hier nochmal die letzte Version der Kombistatus Tabelle

[Wolfgang67]

Meine beiden Bridges hatten die API V1.5 und ich habe gleich das Update auf 1.6 gemacht.
Die Tabelle bei "Kombinierten Zustand" habe ich auf die neuen Werte korrigiert womit nun die Schließzustände korrekt angezeigt werden.

Der Batteriezustand wird aber sowohl beim "Kombinierten Zustand" als auch beim "Batteriezustand" weiter als schwach bzw. kritisch angezeigt obwohl bei der direkten Abfrage über die URL der Schlüsser jeweils "batteryCritical=false" zurückgemeldet wird.

Der Virtuelle Eingang "batteryCritical" liefert bei allen Schlössern lt. Liveview am roten Ausgang den Wert 1 was bei den beiden Bausteinen an den EIngängen AI2 bzw, AI1 laut Tabelle natürlich zu den entsprechenden Meldungen führt. Dadurch vermute ich inzwischen, dass der Fehler eher am virtuellen Eingang "batteryCritival" liegt.

Beiliegend die neue Tabelle für den kombinierten Status und die Tabelle für den Batteriezustand
sowie die Einstellungen für den virtuellen Eingang "batteryCritival" und die Beschaltung der beiden relevanten Bausteine mit den LiveView-Werten.

[Labmaster]

scheint logisch.

In den zurück gelieferten Json Daten sind ja die Statis aller Schlösser enthalten, also muss man auch für jedes Schloss einzeln anhand seiner ID an der richtigen Stelle den Wert (f oder nicht f) finden.
Bei mir sieht dann die Befehlserkennung für den Batterystatus z.B. so aus:
nukiId": yyyyyyyyy\i"batteryCritical\i": \1
wobei y eben die jeweilige Schloss ID des jeweiligen Schlosses ist von welchem man den Batterystatus haben möchte

Ausserdem ist zwischen dem Text
batteryCritical\i":
und der
\1
ein Leerzeichen in den Daten, das fehlt bei dir ausserdem, weshalb die Validierung nun statt dem f von false ein Leerzeichen erkennt und deshalb immer einen Fehler liefert

Erklärung zu der Befehlsauswertung:
Mit dem oben gezeigten Befehlt geht die Auswertung also erst mal durch die empfangenen Daten und sucht nach
nukiId": yyyyyyyyy
danach muss reihenfolglich nun noch
"batteryCritical\i": (leezeichen am Ende sieht man hier nicht)
gefunden werden
das nächste Zeichen wandert dann in die Validierung für den Fehlerausgang (ist der Ascii Wert 102 oder nicht)


Das hatte ich aber auch schon im Beitrag hier:

https://www.loxforum.com/forum/german/software-konfiguration-programm-und-visualisierung/92041-vitueller-eingang-von-nuki-schloss?p=92434#post92434

beschrieben.

Am besten nochmal den Beitrag genau durchlesen und copy/paste der Befehle für state, batterycritical ... machen, dabei halt nur die ID enstprechend einsetzen.

[Wolfgang67]

Natürlich hatte ich eh schon für alle 3 Schlösser jeweils eigene virtuelle Eingänge mit den entsprechenden IP-Adressen der Schlösser. "Battery Critical" gibt es also 3 mal.
Das Problem war wirklich das fehlende Leerzeichen bei der Befehlserkennung zwischen "batteryCritical": und "\1" ! Jetzt funktioniers es :-)

Hab jetzt nochmal die originale Demo-Config der NUKI-Schlösser geöffnet von der ich alles übernommen und dannn angepasst hatte. Da wars auch ohne Leerzeichen drinnen. Hat sich wohl mal was in der Anforderung geändert.

Herzlichen Dank für Deine rasche Hilfe und Deine Geduld !!!

[Labmaster]

Hast du drei Bridges, für jedes Schloss eine einzelne, oder woher kommen drei IP's für drei Schlösser ?
Die Schlösser selbst haben doch gar keine IP sondern nur die Bridges ?

Bei uns ist es so, daß eine Bridge zwei Schlösser bedient und auch über diese EINE Bridge die Daten aller Schlösser in einem Json über einen Virtuellen Eingang zurück kommen.

Wenn du nur eine Bridge hast, dann gibt es auch nur eine IP und auch nur einen Virtuellen Eingang, jedoch für diesen dann für jedes Schloss entsprechend viele Befehle in denen eben die IDs der Schlösser zum Suchen in den Daten entsprechend angepasst sein müssen.

Mit den zwei Schlössern hier haben wir also 6 Befehle für den einen Virtuellen Eingang.
Pro Schloss einen Befehl für Suchen der State Nummer, einen für suchen von batterycritical false und ich hab noch einen für schloss verfügbar (taucht im json überhaupt die ID des gesuchten Schlosses auf.

[Wolfgang67]

Sorry, da war ich ungenau, ich habe aufgrund der Entfernung 2 Bridges für 3 Schlösser.
Die 3 Virtuellen Eingänge unterscheiden sich jeweils durch die IP-Adresse der Bridge und der Nuki-ID des Schlosses.

[Labmaster]

Wenn du nur zwei Bridges hast, dann hast du doch auch nur zwei unterschiedliche IP Adressen. (aber nicht 3 IP Adressen)
Die beiden Schlösser welche dann auf einer gemeinsamen Bridge und somit IP Adresse liegen kannst du nicht mit unterschiedlichen. IP's abfragen, sondern mußt diese über Befehle die IDs suchen lassen.
Ansonsten bekommst du für beide Schlösser immer die Werte und Ergebnisse der ersten Sektion (des ersten Schlosses) zurück.

[Wolfgang67]

Ich habe bei den 3 virtuellen Eingängen im EIntrag URL folgende Einträge:
Virtueller EIngang 1: IP-Adresse Bridge 1 + Nuki-ID Schloss 1
Virtueller EIngang 2: IP-Adresse Bridge 2 + Nuki-ID Schloss 2
Virtueller EIngang 3: IP-Adresse Bridge 2 + Nuki-ID Schloss 3

Damit sollte doch eine Verwechslung ausgeschlossen sein und ich jeweils die Wete vom richtigen Schloss bekommen.

[Labmaster]

Ok,
das mit der ID ging eben aus deiner Konfig (oben im Bild von Post 82) nicht hervor, dort wurde als Befehl eben nur nach "batteryCritical" gesucht, jedoch nicht zuvor nach der passenden NukiId.

[Mattgyver]

@Labmaster

ich bräuchte deine Hilfe bzgl. meines Nuki schon wieder. Seit ein paar Tagen verändert sich der Status des Nuki nicht.
Die "state" bleib immer 1, batteryCritical immer 102, success immer 44.

Wäre toll wenn du dir die Screenshots anschauen könntest. Fällt dir ein Fehler auf?

lg Matthias

[Labmaster]

Schwierig, kommen den die richtigen Daten (also die Datenstruktur) wenn die Abfrage z.B. über einen Browser gemacht wird ?
Gab es ein Update ?
Ich hab leider im Moment keinen Zugriff auf ein Nuki Schloss, kann deshalb im Moment nichts selbst testen :-(

[Mattgyver]

wie kann ich den die Abfrage über den Browser machen?

[Labmaster]

Das was du in der Config beim Virtuellen Eingang bei der Url eingetragen hast, einfach in die Browser zeile kopieren und Enter drücken.
Dann am besten im Browser den Queltext der zurück gekommenen Antwort anschauen was da so kommt, oder ob ein Fehler kommt ....

[Bender]

Hallo,

ich denke, eine Bridge ist nicht unbedingt möglich.

Siehe https://github.com/jandebeule/nukiPyBridge bzw. https://github.com/as19git67/nukible Bin noch nicht sicher, welches Projekt am Schluss besser für eine Loxone Integration geeignet ist.

Beste Grüße,
Bernhard

[philox]

Ich meine häufiger schon gelesen zu haben das die "Hardware" Bridge etwas stabiler ist.

Ich habe eine Bridge mit Loxone Integration seit ca. 6 Monaten in Betrieb und bin sehr zufrieden.

Gesendet von meinem Aquaris X Pro mit Tapatalk