Der Nuki Smart Lock 2.0 Adapter basiert, soweit ich weiß, auf den Implementierungen von Mik13 für die Nuki Bridge API (Mik13/nuki-bridge-api) und intelligencecompany für die Nuki Web API (intelligencecompany/nuki-api). Mein Nuki Smart Lock Adapter kommunniziert direkt mit der Nuki Bridge, ohne diese Abhängigkeiten. Konkret bedeutet das Folgendes:

• Zefaus Nuki Smart Lock 2.0 Adapter unterstützt die Nuki Web API und damit auch den neuen Türsensor, der mit dem Nuki 2.0 geliefert wird. Aktuell wird der Status des Türsensors noch nicht über die Bridge API übertragen (wenn Nuki die API aber anpasst, wird auch der alte Adapter dies unterstützen). Außerdem lassen sich über Nuki Web wohl auch u.a. die Benutzer verwalten. Allerdings funktioniert dies natürlich nur, wenn eine Internetverbindung besteht, da es sich bei Nuki Web um eine (optionale) Cloud-Anbindung handelt.

• Auch werden Software-Bridges vom neuen Adapter offenbar besser unterstützt. Da Zefau selbst eine solche nutzt, ist diese Anbindung bei seinem Adapter weit aus besser getestet, als bei mir. Ich glaube aber, das Problem, das in meinem Adapter mit Software-Bridges bestand, mit Version 1.0.5 behoben zu haben...

• Unterstützung für mehrere Nuki Bridges ist eine Funktion, die für den "alten" Adapter zwar geplant, im Nuki Smart Lock 2.0 Adapter aber schon heute umgesetzt ist.

Alles in Allem, ich denke, der neue Adapter ist dem meinem in vieler Hinsicht überlegen. Für die Nutzung des alten Adapters könnte höchstens sprechen, dass es weniger Abhängigkeiten zu anderen npm-Modulen gibt, und, wenn man ein wenig paranoid ist, wie ich , es sich um eine rein "lokale" Lösung handelt (wobei die Cloud-Anbindung in Zefaus Adapter ja auch optional ist).

@wideblick Derzeit habe ich nicht geplant, die WebAPI mit einzubinden, weil ich dadurch mehr Abhängigkeiten schaffe, die potentiell zu mehr Fehlerquellen sorgen können. Ein weiterer Grund ist,, dass ich persönlich eine Cloud-freie Lösung bevorzuge. Ich weiß, dass das eine wenig befriedigende Antwort ist, wenn man die Möglichkeiten der WebAPI gern nutzen möchte, aber das ist die Philosophie hinter dem Adapter. Vielleicht ändert sich das ja noch...

Mit dem Nuki-Adapter können Nuki-Produkte (Smart Lock & Opener) über die API der Nuki Bridge aus ioBroker gesteuert und überwacht werden.
Mit Version 1.5.0 wird die Kompatibilität zu Admin 5.x.x und jscontroller 3.3.x erhöht.

Changelog

1.5.0

• (smaragdschlange) bug fix: compatibility with jscontroller 3.3.13

1.4.4

• (smaragdschlange) update: changes to comply with admin 5.x.x requirements

1.4.3

• (smaragdschlange) update: dependency axios to >=0.21.1

1.4.2

• (smaragdschlange) bug fix: common.dataSource type had an invalid type

1.4.1

• (smaragdschlange) bug fix: references fixed

1.4.0

• (smaragdschlange) improvement: support of keypad battery state
• (smaragdschlange) improvement: support of ring action states for opener

Hat alles wunderbar geklappt
Danke, Ingo.

@wideblick Ich möchte den Nuki Adapter möglichst einfach halten. Das heißt für mich, Abhängigkeiten vermeiden und lokal bleiben. Sicher bietet die WebAPI viele weitere Möglichkeiten, aber derzeit zögere ich, dieses Fass aufzumachen, zumal ich persönlich eine rein lokale Lösung, ohne Cloud, bevorzuge.
Das mag sich zukünftig noch ändern , zumal sich die Unterstützung der WebAPI wohl viele wünschen...

@dr-bakterius Ich habe versucht, im Nuki-extended Adapter den Support für Nuki 3.0 einzubauen. Wäre schön, wenn das mal jemand ausprobieren und Feedback geben könnte.

Hi @dominic-reber ,

der Unterschied liegt darin, dass Du ohne Hardware Bridge immer eine funktionierende Internetverbindung benötigst, um das Nuki Lock mit ioBroker steuern zu können, da die Web API ja eine Cloud-Lösung ist. Über die Harware Bridge wird eine lokale API zur Verfügung gestellt, über die das Smart Lock auch gesteuert werden kann, wenn die Nuki-Server mal down ist oder Deine Internetverbindung mal nicht funktioniert. Ich persönlich strebe immer, wenn möglich, eine Lösung an, die ohne Cloud auskommt, aber das ist wohl Geschmachssache.

Gruß
Sven

@dr-bakterius Ich habe versucht, im Nuki-extended Adapter den Support für Nuki 3.0 einzubauen. Wäre schön, wenn das mal jemand ausprobieren und Feedback geben könnte.

@wideblick Hm, wenn der devicetype nicht mehr mitgegeben wird, ist es für mich um Einiges schwerer, den Benutzer die korrekten Aktionen und Status anzubieten. Momentan werden in meinem Adapter unterschiedliche Datenpunkte erzeugt, je nachdem, um welche Art Device es sich handelt. Da werde ich dann wohl umdenken müssen, bzw. bin gespannt, wie das in der neuen API dann gelöst ist...
Aber Sinn macht es zumindest bei Nuki Smartlock, Nuki Smartlock 3.0 und Smart Door schon, nicht mehr zwischen den devicetypes zu unterscheiden, da die Möglichkeiten der Steuerung und Überwachung absolut identisch sind. Nur der Opener (und ggf. der neue Door Sensor) fallen da ein wenig aus dem Rahmen.

@dr-bakterius Ich habe mir mal die Issues des Nuki-extended Adapters angesehen und kann jetzt verstehen, dass der Autor den Adapter nicht selbst weiterentwickeln will...
Wenn ich mal ein wenig Zeit habe, werde ich mir die WebAPI mal ansehen, aber ich habe, ehrlich gesagt, weder Zeit, noch Lust, mir eine Vollzeitbaustelle ins Boot zu holen.

@jackdaniel Ich hab leider keine Erfahrung mit der Kommunikation via Bluetoth und der Einbindung der Bluetooth-Schnittstelle in ioBroker. Wenn mir da jemand eine gute Anleitung empfehlen kann, seh ich mir das mal an...

@exitus Hm, für das Keypad ist mir keine API bekannt. Kann man das Keypad denn irgendwie per WLAN erreichen?

@wideblick Ich möchte den Nuki Adapter möglichst einfach halten. Das heißt für mich, Abhängigkeiten vermeiden und lokal bleiben. Sicher bietet die WebAPI viele weitere Möglichkeiten, aber derzeit zögere ich, dieses Fass aufzumachen, zumal ich persönlich eine rein lokale Lösung, ohne Cloud, bevorzuge.
Das mag sich zukünftig noch ändern , zumal sich die Unterstützung der WebAPI wohl viele wünschen...

@johgre Ja, das ist richtig. Das integrierte Wifi-Modul des Nuki 3.0 pro ist nicht kompatibel mit der Bridge API. Offenbar hat Nuki vorgesehen, dass ohne Bridge das Smartlock lediglich per App oder WebAPI gesteuert werden soll.
Schade eigentlich.

@wideblick Derzeit habe ich nicht geplant, die WebAPI mit einzubinden, weil ich dadurch mehr Abhängigkeiten schaffe, die potentiell zu mehr Fehlerquellen sorgen können. Ein weiterer Grund ist,, dass ich persönlich eine Cloud-freie Lösung bevorzuge. Ich weiß, dass das eine wenig befriedigende Antwort ist, wenn man die Möglichkeiten der WebAPI gern nutzen möchte, aber das ist die Philosophie hinter dem Adapter. Vielleicht ändert sich das ja noch...

@exitus Den Nuki adapter habe ich jetzt angepasst, hab aber keinen Nuki 3.0 pro. Über Tester und Feedback würde ich mich sehr freuen.