Ich hatte folgenden Thread im NUKI Forum gefunden:
Die Empfehlung dort lautet das komplette smartlock Objekt per get abzurufen, die benötigten Werte zu verändern und dann das komplette Objekt per post zurückzuschicken.
Lautstärke und Klingelunterdrückungen finden sich in der Smartlock.OpenerAdvancedConfig als doorbellSuppression und soundLevel: https://api.nuki.io/#!/Smartlock/get
Ich würde es auch vorziehen, wenn es direkt über die Bridge ginge - ehrlich gesagt verstehe ich auch nicht, warum das nicht möglich ist - allerdings ist die Bridge API im Vergleich zur Web API ja recht stark eingeschränkt …
Von daher würde ich den Umweg durchaus in Kauf nehmen…
Mittels Instanzkonfiguration, dort kannst du die Administration des Openers vornehmen oder als Variablen im WebFront. Dies sind dann aber jede Menge an Variablen. Das kann ich den Bridge Nutznern nicht zumuten.
Ich könnte mir vorstellen das in der Instanzkonfiguration mit aufführen. Dann müsstest du dir etwas bauen, was die Konfiguration verändert und ich sende die Änderungen über die Web API.
IPS_SetConfiguration
und
IPS_ApplyChanges
Alles nur ein paar Gedanken….mal zum ausloten und austauschen.
Der Weg über die Konfiguration wäre auf Grund der Variablenanzahl definitiv angenehmer für alle Nutzer einer Basic oder Professional Lizenz.
Der Nachteil wäre vermutlich, dass einem natürlich auch die Vorzüge der Variablen verloren gingen:
Man könnte Veränderungen auf einer Einstellung nicht loggen (wovon ich persönlich immer großer Fan bin)
Man könnte nicht einfach Veränderungen (die z.B. durch die App oder die Web UI getätigt wurden) ein Event auslösen lassen, auf das man in IPS reagiert. Über Umwege sicher auch wieder möglich, aber eben nicht ganz so komfortabel.
Nur mal so laut gedacht:
Was wäre denn, wenn man einen Konfigurator hat, für was man Variablen anlegen möchte? Man könnte z.B. eine Liste mit Checkboxen für alle möglichen Optionen generieren und einen Button „alle (de-) aktivieren“, der alle Checkboxen toggeled. Wer alles haben will, bekommt alles. Wer nur ein paar Optionen braucht und Variablen sparen will, wählt nur die benötigten aus. Das würde für mich gerade das beste aus beiden Welten zusammenbringen.
Ich glaube ich möchte eher den Weg gehen eine separate Library für die Nuki Web API zu erstellen. Dann könnte man auch beides mixen, ist aber trotzdem getrennt.
Ich probiere die Tage mal etwas aus, wenn überhaupt würde ich nur den Opener zunächst mit aufnehmen und dann dort alle Variablen erstellen…
Ich schaue mir die Tage die neue API mal näher an und werde das Modul ergänzen, habe aber selber keine Version 3, daher kann ich es dann leider nicht testen.
Laut Hersteller kann das Pro bis auf Weiteres nicht mit der HTTP-API genutzt werden, außer man nutzt eine externe Bridge. Wann eine Unterstützung für die interne Bridge des Pro kommt, haben sie bisher nicht gesagt.
Ich gehe davon aus, dass die interne Bridge immer irgendwelche Einschränkungen gegenüber der externen haben wird. Anders wird es kaum gehen, eine WLAN-Verbindung für ein batteriebetriebenes Gerät zu realisieren, außer man will das Schloss jeden Tag laden oder die Batterien wechseln.
Hier noch eine Info vom Hersteller zum Smart Lock 3.0:
Brauche ich die Nuki Bridge für den Online-Zugriff auf mein Smart Lock?
Aktiviere das integrierte WLAN-Modul deines Smart Lock 3.0 Pro und genieße vollen Online-Zugang.
Das Nuki Smart Lock 3.0 Pro ist bereits mit einem integrierten WLAN-Modul ausgestattet. Du benötigst somit keine Bridge mehr, um es aus der Ferne zu steuern und es in dein Smart Home einzubinden.
Durch das eingebaute WLAN-Modul hast du vollen Online-Zugriff auf dein Smart Lock und kannst es jederzeit mit deiner Nuki Smartphone App bedienen und verwalten. Mit der App kannst du deine Tür von unterwegs zu sperren oder öffnen, das Protokoll einsehen und Zugangsberechtigungen vergeben.
Der Fernzugriff ist nicht auf die Nuki App beschränkt. Bei Bedarf kannst du auch Nuki Web aktivieren, um das Smart Lock über einen Browser zu verwalten.
Der Fernzugriff für alle anderen Versionen des Nuki Smart Locks ist nur über die Nuki Bridge.
Ein Modul für die Nuki Web API ist bei mir gerade in Vorbereitung. Dies wird aber bis zum Release noch dauern. Gehe mal von Ende Januar 2022 aus.
Moin,
danke schon mal für die Infos.
Wie wäre eure Kaufempfehlung? Dann würde ich eher die Version 2 mit Bridge kaufen. eine Bridge stört mich eigentlich nicht, in der nähe ist eine Steckdose.
Bis auf der es den Pro in schwarz gibt sehe ich da gerade keine Vorteile.
WLAN auf Batterie sehe ich eher als Nachteil was den Stromverbrauch an geht.
die von dir zitierte Aussage von NUKI ist aber etwas verwirrend, weil das nur in Verbindung mit der App und der Web-API zutrifft. Das sollte NUKI vielleicht noch mal klarstellen. Jürgen Pansy (NUKI) hat im Entwicklerforum mehrfach bestätigt, dass das Pro keine HTTP-API unterstützt. Siehe z.B. hier: Nuki 3.0 Pro - #3 by Juergen - Questions - Nuki Developers
Es gibt auch bereits mehrere Feature Requests, die HTTP-API ins Pro zu integrieren.
Wenn das Modul also in Zukunft die Web-API unterstützt, wird es mit dem Pro auch ohne externe Bridge gehen. Über die HTTP-API wohl bis auf Weiteres nicht.
Im Moment sehe ich im 3.0 Pro persönlich auch keine Vorteile. Der einzige Unterschied, der mich gereizt hat, wo ich aber nicht beurteilen kann, wie groß er wirklich ist, ist dass beide 3.0 Locks leiser als das 2.0 sein sollen. Ansonsten sehe ich eigentlich keine weiteren Vorteile. Ein Akku-Pack kannst du sowohl im 3.0 als auch im 2.0 nachrüsten. Beim 3.0 (inkl. Pro) fehlt zudem der integrierte Türsensor, weil er wohl nicht so zuverlässig funktioniert hat. Den gibt es jetzt beim 3.0 (inkl. Pro) als externe Version, wem das wichtig ist.
Ich persönlich fahre derzeit mit meinen 2.0 Locks mit Türsensor und externen Bridges sehr gut, auch was die Akku-Laufzeiten angeht. Nur die Lautstärke der Schlösser stört mich als einziges etwas.