Tweet
Nuki: Keypad 2 für weitere Funktionen nutzen
vllt. ist das für den ein oder anderen interessant der ein Nuki Keypad (2) hat:
Man kann mit dem Keypad auch codes definieren, mit denen man im Smart Home andere Dinge steuert bzw. autorisiert als nur die Tür. (siehe auch hier) Z.B. mit unterschiedlichen Fingern verschiedene Tore aufsperren
1) Dazu geht man in die Nuki App (auf dem Handy) > Einstellungen > Keypad. Dort fügt man für jede zusätzliche gewünschte Funktion eine eigene "Berechtigung" hinzu. Diese versieht man mit einem Code und bei Bedarf auch einem Fingerabdruck. Dabei nimmt man folgende Einstellung vor: "Sperren erlauben" > Aus (Häkchen entfernen!). Die "normalen" Berechtigungen mit "Sperren erlauben" (default) aktiv unangetastet lassen (die ermöglichen weiterhin den Schlüssel zu drehen bzw. die primäre Funktion auszuführen).
2) in der Nuki App > Funktionen und Konfiguration > Smart Home > MQTT aktivieren und einrichten für den Loxberry.
3) Danach setzt man auf dem Loxberry beim MQTT incoming view für nuki_<<ID>>_lockActionEvent unter "show details and advanced settings": "Disable cache" > An; "Reset after send" > An. Vorher ggf. mal die lockActionEvents auslesen und schauen was die Auth-ID und Code-IDs sind (benötigt man in Schritt 5)!
4) In der Loxone Config dann wie folgt vorgehen: virtuellen Texteingang anlegen: "nuki_<<ID>>_lockActionEvent". Dieser kommt nun gepulst an und codiert (und zwar nur bei Eingabe, nicht nach Miniserver-Neustart o.Ä.) wie folgt (siehe API 1.4 specs):
5) Diesen MQTT Eingang dann über einen ersten Status-Baustein abfangen (Text-Vergleich scheint zu funktionieren?!) und in entsprechende eindeutige Zahlen bzw. von 0 verschiedenen IDs überführen (z.B.: "3,0,<<Auth-ID>>,<<Code-ID 1>>,1" > Val = 1; "3,0,<<Auth-ID>>,<<Code-ID 1>>,2" > Val = 2; usw.; die <<Auth-ID>> und <<Code-ID>> für die Vergleichs-Strings im Baustein jeweils vorher mal durch Betätigen & MQTT Explorer (freeware) oder von Schritt 3 nutzen). Die "0" als Val muss für den MQTT Eingangs-default (=0=keine aktuelle Eingabe=reset value des MQTT gateways am Loxberry) gesetzt sein. Diese Status-Baustein-Val-Ausgaben kann man dann über einen Analog-Speicher-Baustein (V=Val vom Status-Baustein, Set-Eingang von einem "Ungleich 0"-Baustein; Off-Eingang: verzögerter Impuls-Baustein vom Ungleich 0"-Baustein) für z.B. 10 sek. in einem entsprechenden (1<>1 vom ersten Status-Baustein übernehmen, aber Spalte I1= auf die Zahlen bzw. eindeutigen IDs setzen) zweiten Status-Baustein anzeigen lassen und auswerten (in entsprechende Werte bzw. Val überführen für Nachverarbeitung, siehe Schritt 6; z.B. I1=1 > Val=1; I1=2 > Val=1; Da beide der gewünschten Aktion per Code bzw. Fingerabdruck entsprechen!):
Wenn nun der entsprechende Zugangscode für die nicht-SmartLock-Actions, also jener neu angelegt ohne Sperr-Erlaubnis, eingegeben wird, so kommt im MQTT und in dem virtuellen Texteingang als LockActionEvent an: "3,0,<<Auth-ID>>,<<Code-ID 1>>,1" (oder ",2" > Fingerabdruck der neu angelegten Berechtigung), wobei nichts mit dem Türschloss geschieht! Wenn hingegen der korrekte Zutritts-Code eingegeben wird, so kommt "3,0,<<Auth-ID>>,<<Code-ID 2>>,1" an, also ein von der <<Code-ID 1>> unterschiedene andere <<Code-ID 2>> (eben die mit Sperr-Erlaubnis, schließt z.B. wie gehabt die Tür). Bei falscher Code-Eingabe (also keiner Berechtigung entsprechend) kommt folgendes im MQTT an: "3,0,<<Auth-ID>>,0,1".
Der zweite Statusbaustein überführt also die eindeutigen MQTT-Eingänge in entsprechende zusammengeführte Values die einer Aktion entsprechen sollen für Schritt 6, z.B. Fingerabdruck oder Code = Val = 1 für die neue Berechtigung mit der Code-ID 1 soll das Garagentor öffnen o.Ä., die Zutritts-Code ID 2 soll noch die Alarmanlage entschärfen, falscher Code soll ein rotes Licht innen ausgeben...
6) Der zweite Status-Baustein kann nun also mit einem nachgeschalteten "Vergleich"-Baustein (=den zusammengeführten Val für die Aktion abfragen)und einer Flankenerkennung (wandelt de 10sek Puls in einen kurzen Puls bei "On" um) genutzt werden um weitere Funktionen zu triggern (z.B. Garagentor öffnen/schließen).
Man kann mit dem Keypad auch codes definieren, mit denen man im Smart Home andere Dinge steuert bzw. autorisiert als nur die Tür. (siehe auch hier) Z.B. mit unterschiedlichen Fingern verschiedene Tore aufsperren
1) Dazu geht man in die Nuki App (auf dem Handy) > Einstellungen > Keypad. Dort fügt man für jede zusätzliche gewünschte Funktion eine eigene "Berechtigung" hinzu. Diese versieht man mit einem Code und bei Bedarf auch einem Fingerabdruck. Dabei nimmt man folgende Einstellung vor: "Sperren erlauben" > Aus (Häkchen entfernen!). Die "normalen" Berechtigungen mit "Sperren erlauben" (default) aktiv unangetastet lassen (die ermöglichen weiterhin den Schlüssel zu drehen bzw. die primäre Funktion auszuführen).
2) in der Nuki App > Funktionen und Konfiguration > Smart Home > MQTT aktivieren und einrichten für den Loxberry.
3) Danach setzt man auf dem Loxberry beim MQTT incoming view für nuki_<<ID>>_lockActionEvent unter "show details and advanced settings": "Disable cache" > An; "Reset after send" > An. Vorher ggf. mal die lockActionEvents auslesen und schauen was die Auth-ID und Code-IDs sind (benötigt man in Schritt 5)!
4) In der Loxone Config dann wie folgt vorgehen: virtuellen Texteingang anlegen: "nuki_<<ID>>_lockActionEvent". Dieser kommt nun gepulst an und codiert (und zwar nur bei Eingabe, nicht nach Miniserver-Neustart o.Ä.) wie folgt (siehe API 1.4 specs):
LockAction (1: unlock; 2: lock; 3: unlatch; 4: lock ‘n’ go; 5: lock ‘n’ go with unlatch; 6: full lock; 80: fob (without action); 90: button (without action)),
Trigger (0: system / bluetooth command; 1: (reserved); 2: button; 3: automatic (e.g. time control); 6: auto lock; 171: HomeKit; 172: MQTT),
Auth-ID (entspricht einem Gerät / Keypad?),
Code-ID (entspricht einer Berechtigung),
Auto-Unlock (0 or 1) / # button presses / Keypad source (0 = back key, 1 = code, 2 = fingerprint)
Trigger (0: system / bluetooth command; 1: (reserved); 2: button; 3: automatic (e.g. time control); 6: auto lock; 171: HomeKit; 172: MQTT),
Auth-ID (entspricht einem Gerät / Keypad?),
Code-ID (entspricht einer Berechtigung),
Auto-Unlock (0 or 1) / # button presses / Keypad source (0 = back key, 1 = code, 2 = fingerprint)
5) Diesen MQTT Eingang dann über einen ersten Status-Baustein abfangen (Text-Vergleich scheint zu funktionieren?!) und in entsprechende eindeutige Zahlen bzw. von 0 verschiedenen IDs überführen (z.B.: "3,0,<<Auth-ID>>,<<Code-ID 1>>,1" > Val = 1; "3,0,<<Auth-ID>>,<<Code-ID 1>>,2" > Val = 2; usw.; die <<Auth-ID>> und <<Code-ID>> für die Vergleichs-Strings im Baustein jeweils vorher mal durch Betätigen & MQTT Explorer (freeware) oder von Schritt 3 nutzen). Die "0" als Val muss für den MQTT Eingangs-default (=0=keine aktuelle Eingabe=reset value des MQTT gateways am Loxberry) gesetzt sein. Diese Status-Baustein-Val-Ausgaben kann man dann über einen Analog-Speicher-Baustein (V=Val vom Status-Baustein, Set-Eingang von einem "Ungleich 0"-Baustein; Off-Eingang: verzögerter Impuls-Baustein vom Ungleich 0"-Baustein) für z.B. 10 sek. in einem entsprechenden (1<>1 vom ersten Status-Baustein übernehmen, aber Spalte I1= auf die Zahlen bzw. eindeutigen IDs setzen) zweiten Status-Baustein anzeigen lassen und auswerten (in entsprechende Werte bzw. Val überführen für Nachverarbeitung, siehe Schritt 6; z.B. I1=1 > Val=1; I1=2 > Val=1; Da beide der gewünschten Aktion per Code bzw. Fingerabdruck entsprechen!):
Wenn nun der entsprechende Zugangscode für die nicht-SmartLock-Actions, also jener neu angelegt ohne Sperr-Erlaubnis, eingegeben wird, so kommt im MQTT und in dem virtuellen Texteingang als LockActionEvent an: "3,0,<<Auth-ID>>,<<Code-ID 1>>,1" (oder ",2" > Fingerabdruck der neu angelegten Berechtigung), wobei nichts mit dem Türschloss geschieht! Wenn hingegen der korrekte Zutritts-Code eingegeben wird, so kommt "3,0,<<Auth-ID>>,<<Code-ID 2>>,1" an, also ein von der <<Code-ID 1>> unterschiedene andere <<Code-ID 2>> (eben die mit Sperr-Erlaubnis, schließt z.B. wie gehabt die Tür). Bei falscher Code-Eingabe (also keiner Berechtigung entsprechend) kommt folgendes im MQTT an: "3,0,<<Auth-ID>>,0,1".
Der zweite Statusbaustein überführt also die eindeutigen MQTT-Eingänge in entsprechende zusammengeführte Values die einer Aktion entsprechen sollen für Schritt 6, z.B. Fingerabdruck oder Code = Val = 1 für die neue Berechtigung mit der Code-ID 1 soll das Garagentor öffnen o.Ä., die Zutritts-Code ID 2 soll noch die Alarmanlage entschärfen, falscher Code soll ein rotes Licht innen ausgeben...
6) Der zweite Status-Baustein kann nun also mit einem nachgeschalteten "Vergleich"-Baustein (=den zusammengeführten Val für die Aktion abfragen)und einer Flankenerkennung (wandelt de 10sek Puls in einen kurzen Puls bei "On" um) genutzt werden um weitere Funktionen zu triggern (z.B. Garagentor öffnen/schließen).
Kommentar