Dokumentation Nuki Bridge API (Bluetooth Türschloss)
Einklappen
X
-
Kommentar
-
Habe mittlerweile mein Nuki. Allerdings wird die Bridge noch nicht mit ausgeliefert. Ist erst in Produktion. Somit könnte man es noch nicht in Loxone einbinden.
ABER ich kann es auf meinem Türblatt noch nicht mal anbringen. Habe zwei lange Schrauben von innen nach aussen, die den äußeren Beschlag halten. Die Bohrungen in der Montageplatte passen allerdings nicht.
Der Support macht mir auch keine Hoffnung. Werde
Die Klebe Montageplatte ist ebenfalls keine Option, da ich für die langen Schrauben Unterlegscheiben bräuchte, damit die Schrauben nicht im Bohrloch verschwinden. Mit den Unterlegscheiben, würde die Montageplatte allerdings nicht mehr am Türblatt anliegen.
Werde mir nun selbst behelfen und aus den Bohrlöchern ein Langlöcher machen.Kommentar
-
Neu kostet es 229. natürlich ohne Bridge.
Ich gebe es für VB 200 inkl Versand ab. Natürlich nie gebraucht.Kommentar
-
-
Ich habe die API über die Android Bridge jetzt in Betrieb genommen und es funktioniert fürs Erste sehr gut!
Gesehen und getestet hab ich den NUKI nur per Facetime, also Remote!
Hier auch gleich meine Templates:
Gast Wenn ich mir was wünschen dürfte...?
Loxone ist mit dem Fehlerhandling recht schwach (bzw. ist es praktisch nicht vorhanden, oder selbst fehlerhaft). Beispielsweise gibt es noch nicht mal eine Behandlung, wenn ein Request nicht durchgeht oder einen HTTP-Fehler bekommt.
Könntet ihr zur Fehlererkennung in den /lockState als Rückgabe einen Timestamp als Zahl (nicht im Datums-/Zeitformat) einbauen, z.B. epoch. Oder wenn es keine Zeit gibt, irgendeinen bei euch vorhandenen Ticks-Zähler. Damit lässt sich eine eigene Validierung wie die hier realisieren: http://www.loxwiki.eu:80/x/0YBq
Gleichermaßen wäre es schön, wenn beim /lockState statt bzw. zusätzlich zu den HTTP-Errors 401 und 404 auch tatsächlich noch ein {success: "false"} zurück käme.
Dann hätte ich noch eine Frage zum Status 4 - unlatched.
Das ist ja praktisch die Falle zurückziehen (öffnen). Die Falle wird ja mechanisch vermutlich wieder in Normalposition gefahren - bleibt dann der Status 4 - unlatched als letzter Status, oder erkennt der Keyturner, dass die Tür aufgesprungen ist?
Wenn das nicht erkannt wird, ist das sowieso ein Manko, dass ich bei offener Tür den schönsten LOCK-Status haben kann, und trotzdem steht die Haustür sperrangelweit offen. Ein Reed-Kontakt oder irgendeine Art von Bestätigung, dass die Tür wirklich ZU ist, wäre zusätzlich zum Keyturner eigentlich Pflicht.
Beste Grüße,
Christian
Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraineKommentar
-
Kommentar
-
Loxone ist mit dem Fehlerhandling recht schwach (bzw. ist es praktisch nicht vorhanden, oder selbst fehlerhaft). Beispielsweise gibt es noch nicht mal eine Behandlung, wenn ein Request nicht durchgeht oder einen HTTP-Fehler bekommt.
Könntet ihr zur Fehlererkennung in den /lockState als Rückgabe einen Timestamp als Zahl (nicht im Datums-/Zeitformat) einbauen, z.B. epoch. Oder wenn es keine Zeit gibt, irgendeinen bei euch vorhandenen Ticks-Zähler. Damit lässt sich eine eigene Validierung wie die hier realisieren: http://www.loxwiki.eu:80/x/0YBq
Gleichermaßen wäre es schön, wenn beim /lockState statt bzw. zusätzlich zu den HTTP-Errors 401 und 404 auch tatsächlich noch ein {success: "false"} zurück käme.
Dann hätte ich noch eine Frage zum Status 4 - unlatched.
Das ist ja praktisch die Falle zurückziehen (öffnen). Die Falle wird ja mechanisch vermutlich wieder in Normalposition gefahren - bleibt dann der Status 4 - unlatched als letzter Status, oder erkennt der Keyturner, dass die Tür aufgesprungen ist?
Wenn das nicht erkannt wird, ist das sowieso ein Manko, dass ich bei offener Tür den schönsten LOCK-Status haben kann, und trotzdem steht die Haustür sperrangelweit offen. Ein Reed-Kontakt oder irgendeine Art von Bestätigung, dass die Tür wirklich ZU ist, wäre zusätzlich zum Keyturner eigentlich Pflicht.
Wenn man ein unlatch (Falle ziehen) Kommando ausführt, dann wird der Status zunächst zu "unlatching", danach "unlatched" und dann wieder "unlocked".
Den Status "Tür offen" oder "Tür geschlossen" gibt es mangels Türkontakt nicht.
Kommentar
-
Danke für die Info!
Ein Türkontakt zum Nuki wäre dann wohl ein nettes Zusatzprodukt.
lg, ChristianHilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraineKommentar
-
@ Christian Fenzl: Vielen Dank für die Loxone Integration und das Wiki :-)
Eine Anmerkung habe ich jedoch: Das Rücksetzten des Radio-Buttons klappt so nicht.
Habe das mit einem Vergleicher gelöst. dann klappt es. ;-)
....ach ja, und zusätzlich hab ich einen Eltako Enocean Türkontakt eingebunden.
Da ich keine guten Erfahrungen mit den Nuki FOBs gemacht habe,
(Die schaffen es kaum, das Funksignal durch eine 3-fach Glasscheibe an den Nuki zu senden :-( )
verwende ich ausschließlich nur noch Handy mit Loxone APP (die ist schneller als die Nuki APP).
Zudem gibts ja auch noch die Quick Functions bei iOS.
Gruß
Christian
Kommentar
-
Hallo Christian!
musst nur beim Baustein "verzögerten Impuls" die Invertierung bei TR weggeben.
Hab von Haus aus einen Reed in der Tür, muss sagen das funktioniert super.
Bei mir klappt das mit den Rückmeldungen irgendwie nicht, da muss ich noch mal schauen.
lg richardKommentar
Kommentar