Nuki Smartlock Plugin

[fuppy]

Hallo zusammen,

ich habe ein Plugin für die Anbindung eines Nuki Smartlocks an sh.py geschrieben. Voraussetzung hierfür ist neben dem Smartlock an sich noch die Nuki Bridge, welche via REST API mit sh.py kommuniziert.

Mithilfe des Plugins lässt sich

• der Lock Status des Smartlocks auslesen,
• der Batteriezustand des Smartlocks überwachen,
• Sperrvorgänge triggern und
• via Callback-Funktion der Bridge der Status des Smartlocks automatisch an sh.py übermitteln (--> kein Scheduler notwendig; der Status ist immer up-to-date)

Das Plugin ist so konzipiert, dass es auch mehrere Smartlocks gleichzeitig unterstützt. Testen konnte ich dies aber leider mangels fehlender Hardware nicht.

Leider läuft bei mir noch sh.py mit dem letzten Dev Stand. Sollte aber normalerweise alles auch mit smarthomeNG laufen.

Das Plugin ist hier zu finden:
GitHub: https://github.com/chrpuf/smarthome-nuki


Danke schon mal für eure Hilfe!

Gruß

Christian

[psilo]

Pull Request gegen den DEV der Plugins. Dazu müsstest Du dann aber doch umstellen. Und bitte dann noch auf das hier anheben: https://github.com/smarthomeNG/smart...ki/SmartPlugin

Alternative evtl eigenes github Projekt

[pfischi]

Da ich auch gerade ein Plugin dafür erstelle (aber noch einiges machen muss), kannst du mir gerne den Code geben und ich schaue drüber und stelle auch gleich um.

Gruss,

Stefan

[fuppy]

Ich versuch morgen die Dateien auf GitHub zur Verfügung zu stellen. Danke schon mal!

Gruß

Christian

[fuppy]

Hab das Plugin auf GitHub bereitgestellt (siehe Post #1)

Danke schon mal an pfischi fürs Prüfen!

PS: Ist mein erstes Plugin. Ich bitte um Nachsicht ;-)

[pfischi]

Danke fürs Plugin. Sieht gut aus. Würde gerne noch zwei, drei Dinge ändern und dir dann nochmal abstimmen. Der get_lan_ip-Aurfruf kommt mir bekannt vor , den habe ich mittlerweile abgeändert und wird dadurch stabiler.

Gruss,

Stefan

[fuppy]

Danke fürs positive Feedback :-)

Ja das hab ich dreister Weise von deinem Plugin übernommen Hatten ja vor einiger Zeit schon mal Kontakt wg. dem TCP Dispatcher für das Handling der Nuki Bridge Callbacks.

Dann warte ich mal auf deine Antwort!

Gruß

Christian

[pfischi]

fuppy

So, ich habe das Plugin etwas angepasst.

• SmarthomeNG-konform gemacht
• Strukturen etwas geändert
  • SmarthomeNG muss nicht neu gestartet werden, wenn ein Schloss hinzugefügt wurde (spätenstens nach 5min wird erneut gescannt)
  • callbacks werden beim Start des Plugins von der Bridge gelöscht, da nur max 3. gleichzeitig möglich sind
  • hier und da Code-Cleaning
• die url-Methoden habe ich auf Requests-Klassen umgestellt, da einfacheres Encoding-Handling
• Item-Struktur angepasst:
  • alle Items haben jetzt den type 'num', das macht es deutlich einfacher, die Stati in der Smartvisu abzubilden
  • ein Item sieht jetzt so aus, das ist variabler und übersichtlicher (ich habe die entsprechende Dokumentation angepasst):

[Test]
    [[LockState]]
        type = num
        nuki_id = 101022222
        nuki_trigger = state

    [[LockBattery]]
        type = num
        nuki_id = 101022222
        nuki_trigger = battery

    [[Action]]
        type = num
        nuki_id = 101022222
        nuki_trigger = action

Großen Dank an deine Arbeit. Das Schloss läuft wunderbar mit dem Plugin. Bin auf das Feedback gespannt.

-->GITHUB<--

Gruss,

Stefan

[fuppy]

Hallo pfischi ,

vielen Dank fürs Code-Review und die Anpassungen. Da ich aktuell ja noch sh.py einsetze, kann ich leider noch nicht von deinen Verbesserungen profitieren.

Deine Anpassungen finde ich fast alle sehr gut! Man merkt einfach, dass du in Sachen Programmierung und auch Python mehr drauf hast als ich :-)

Einen Punkt möchte ich allerdings etwas in Frage stellen: Du hast dich ja dafür entschieden, alle Items auf type 'num' umzustellen und auch die Items für "LockState" und "LockAction" zu trennen. Ich hab mich hier aktiv dagegen entschieden. Mein Gründe hierfür waren vor allem der Blick Richtung smartVISU und der (einfachen) Anzeige bzw. "Übersetzung" von num-Werten in lesbare Strings. Das Thema wurde hier schon einmal behandelt. Da es keine "schöne" und einfache Möglichkeit gab, hab ich mich dazu entschieden, vom sh.py gleich die richtigen Werte liefern zu lassen. Des Weiteren hab ich mich dann entschieden, auch für das Triggern der LockActions dieses Item zu benutzen. Aus meiner Sicht macht es das Ganze dann einfacher. Aber darüber kann man sicherlich streiten...

Kannst du mir (außer der Anzeige in smartVISU) noch Vorteile nennen, weshalb du dich für die Trennung von LockState und LockAction entschieden hast? Ich lerne gerne dazu :-)

Dann werde ich mich wohl mal bei Zeiten dransetzen, auf smarthomeNG upzudaten...

[pfischi]

Die Trennung macht hier deshalb Sinn, weil es sich eigentlich um zwei getrennt zu betrachtende Aktionen handelt. Das eine ist "lesend", das andere "schreibend". So wird es ja auch bei typischen KNX-Aktoren wie z.B. beim Status vom Licht gemacht; ein KO schaltet das Licht, das andere KO sendet unabhängig davon den Licht-Status. In deiner Version würde jede Aktion den Wert für den Status überschreiben und umgekehrt, eventuell würde es da zu unvorhergesehenen Konflikten kommen. Die Trennung macht also durchaus Sinn.

Der Typ 'num' ist aus meiner Sicht einfach der unkomplizierteste. Erstens bildet er genau die API des Nuki ab, zweites kann ich später einfacher mit eval-Anweisungen arbeiten. Die Umsetzung auf den String gehört für mich in die Visu, Smartvisu bietet ja da auch von Haus aus Möglichkeiten an (siehe Item basic.multistate in SmartVisu). Ein anderes Problem sind natürlich auch die zu setzenden Werte für die LockActions: ein

lock 'n' go with unlatch

ist halt einfach fehleranfälliger (auch in der späteren Verarbeitung mit eval-Ausdrücken) als ein Wert

6

Ich hoffe ich konnte dich überzeugen

Wenn du willst kann ich dir gerne eine Version für smarthome.py fertig machen. Die Änderung sind eigentlich marginal.


Edit: Achja, num-Werte lassen sich völlig unkompliziert als Gruppenadresse über den KNX-Bus senden, Texte nur bedingt. Performanter ist es allemal. Ein Beispiel fällt mir noch ein: Nimm den Fehlerwert vom Nuki. Beim num-Typ kann ich einfach auf >=254 vergleichen, beim Text wirds schon komplizierter. Ein weiterer Vorteil wäre auch die Speicherung der Stati in einer DB. Jede Datenbank wird es dir danken, wenn du ihr Integer-Werte gibst. Speicherung von Strings versucht man unter allen Umständen zu vermeiden. (Stichwort Indexing etc)



Gruss,

Stefan

[pfischi]

So, das Plugin wurde in den dev-Zweig aufgenommen. Damit kommt das Plugin noch rechtzeitig ins 1.3er Release. Der offizielle Support-Thread ist -->HIER<--.
Bis dahin können wir noch weitere Änderungen einfließen lassen.

Gruss,

Stefan

[fuppy]

Hallo Stefan,

sorry für die späte Rückmeldung.

Klasse, dass es das Plugin dann später noch auch ins Release schaffen wird :-)

Zu deinen vorherigen Posts hätte ich trotzdem noch zwei Fragen/Anmerkungen:

Die Umsetzung auf den String gehört für mich in die Visu, Smartvisu bietet ja da auch von Haus aus Möglichkeiten an (siehe Item basic.multistate in SmartVisu).

Kannst du mir genau verraten, wie man mit basic.mulitstate auf Basis von num-Werten aus shNG Stings ausgeben kann? Soweit ich das deute kann man auf Basis von num-Werten verschiedene Icons anzeigen lassen.

• callbacks werden beim Start des Plugins von der Bridge gelöscht, da nur max 3. gleichzeitig möglich sind

Hier verstehe ich den Sinn nicht ganz. In meiner ersten Version des Plugins habe ich ja eine Prüfung eingebaut, ob die Callback-Funktion des Plugins bereits in der Bridge hinterlegt ist. Wenn ja, soll diese nicht hinzugefügt werden, wenn nein, dann soll sie es.
Es könnte ja theoretisch sein, dass die Bridge mit mehreren Systemen (z. B. smarthomeNG und HS) gleichzeitig kommunizieren muss. Dann werden auch zwei unterschiedliche Callback-Funktionen benötigt. Das Plugin löscht dann alle, erstellt aber nur noch die für sich selbst.
Aus meiner Sicht würde ich das wieder umstellen...

Ansonsten bin ich mit den Verbesserungen meines ursprünglichen Plugins sehr zufrieden Tolle Arbeit!

Zwei Plugins hab ich noch in der Hinterhand... sind aber leider wieder sehr spezifisch mit vermutlich eher weniger Nutzen für die Community.

Wünsch dir noch nen schönen Sonntag. Ich mach mich jetzt mal dran, auf smarthomeNG upzudaten... Gar nicht so einfach zwei smarthome-Versionen parallel auf ner Kiste zu installieren...

[pfischi]

Hier verstehe ich den Sinn nicht ganz. In meiner ersten Version des Plugins habe ich ja eine Prüfung eingebaut, ob die Callback-Funktion des Plugins bereits in der Bridge hinterlegt ist. Wenn ja, soll diese nicht hinzugefügt werden, wenn nein, dann soll sie es.
Es könnte ja theoretisch sein, dass die Bridge mit mehreren Systemen (z. B. smarthomeNG und HS) gleichzeitig kommunizieren muss. Dann werden auch zwei unterschiedliche Callback-Funktionen benötigt. Das Plugin löscht dann alle, erstellt aber nur noch die für sich selbst.
Aus meiner Sicht würde ich das wieder umstellen...

Ich hatte beim Testen bemerkt, das die Bridge die Callbacks ewig drinnen lässt. Ich hatte ein wenig mit den Ports und IPs rum probiert und musste feststellen, das ich keine Callbacks mehr registrieren konnte. Das war einfach die Quick-and-Dirty-Lösung. Nicht ganz perfekt. Das Problem ist halt, wer hat hier Vorrang :-) Eventuell könnte man nur einen Callback überschreiben, z.B. den als letztes hinzugefügten. Garnieren kann man das noch mit einer entsprechenden Warning im shNG-Log.

Kannst du mir genau verraten, wie man mit basic.mulitstate auf Basis von num-Werten aus shNG Stings ausgeben kann? Soweit ich das deute kann man auf Basis von num-Werten verschiedene Icons anzeigen lassen.

Ja, du hat vollkommen recht, ich hatte mir für andere Sachen ein entsprechendes eigenes Widget benutzt. Ich kann ja ein eigenes Widget für das Nuki Plugin bauen.

Gruss,

Stefan

[fuppy]

IEventuell könnte man nur einen Callback überschreiben, z.B. den als letztes hinzugefügten. Garnieren kann man das noch mit einer entsprechenden Warning im shNG-Log.

Den Ansatz finde ich interessant. Man müsste dann den zuletzt geschriebenen Callback innerhalb von shNG zwischenspeichern. Fällt dir hier spontan eine Lösung ein? Ohne Item kann man ja nichts in die DB bzw. in den Cache schreiben. Bliebe nur der Weg übers Filesystem, oder?
Einfach alles rauslöschen ist auch nicht die Lösung

Ja, du hat vollkommen recht, ich hatte mir für andere Sachen ein entsprechendes eigenes Widget benutzt. Ich kann ja ein eigenes Widget für das Nuki Plugin bauen.

Das mit dem dedizierte Widget klingt gut. Gibt es irgendwo ne brauchbare Anleitung, wie man eigene Widgets erstellt?
Im smartVISU Forum haben wir das Thema "Mapping von mehreren num- zu String-Werten" auch schon mal kurz behandelt. Vermutlich wird in eines der nächsten Releases ein neues Widget mit einfließen, welches die gewünschte Funktion unterstützen soll (siehe hier). Alternativ kann man ein bereits bestehendes Widget namens "multitext" einbinden, welche im Forum rumgeistert, aber nicht offiziell im Release enthalten ist.

Ich hoffe, bis Ende der Woche auf smarthomeNG umgestellt zu haben. Dann kann ich unser Plugin dann endlich mal testen

PS: Ich hab in der Readme.md im Dev-Branch einen Fehler gefunden: Bei nuki_trigger - battery steht im Beschreibungstext

nuki_trigger = state

anstatt

nuki_trigger = battery

[pfischi]

Ich würde es gerne simpel lassen. Das hier Leute die API vom Nuki mehrfach verwenden wird gegen null tendieren.Wir sollten einen entsprechenden Hinweis in der Doku einbauen und noch eine Warnung im Log. Den Code werde ich noch so umbauen, das er nur dann die callbacks löscht, wenn kein Slot mehr frei ist. Das ist aus meiner Sicht ein guter Kompromiss.

Ich baue gerade am Sonos-Widget. Danach schaue ich mir mal das Widget für das Plugin an. Eventuell können wir dies auch gleich als Plugin-Widget einbinden. Ich erinnere mich, das dies irgendwie möglich ist, muss ich mir aber noch anschauen. Gerne kannst du da auch schon loslegen

Die Fehler in der Doku mache ich noch raus, Danke für den Hinweis.

Was ich mir noch überlegt habe um die Zutrittssicherheit noch ein wenig zu erhöhen: man könnte ein zusätzliches Attribute einfügen was verhindert, das bestimmte Aktionen getriggert werden können, z.B Tür öffnen und/oder Tür entriegeln. Sozusagen eine Art Filter.

Noch ein kleines Feedback nach drei Tagen Nuki-Plugin: läuft tadellos, der Status des Schlosses wird korrekt aktualisiert.

Gruss,

Stefan