UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Hakemann]

@grrfield + @andibr: Danke für eure Rückmeldung. Werde es dann wohl mit dem Original Sensor machen. Dann habe ich das Schloss zumindest in seinen Grundfunktion mit Türsensor sauber wenn der IObroker mal nicht läuft oder sonst was spinnt ;-)

[Addy]

Hallo zusammen,

Konnte jemand den lockActionEvent state in MQTT im iobroker richtig anzeigen?
Wenn nein, welche alternative Lösung habt ihr ggf bereits gefunden.

Danke
Markus

[grrfield]

@addy Unter lockActionEvent werden Sonderzeichen angezeigt. Wenn Du unter Objekte auf den State gehst,

kannst Du den angezeigten Wert kopieren, in ein Javascript-Skript einfügen und dort die Sonderzeichen sehen, z. B.
Den State liest Du normal mit getState aus, kannst dann mit slice() die gelesenen Sonderzeichen separieren und mit den vorher ermittelten vergleichen. Hier ein Beispiel, das das Öffnen von Nuki detektiert:

let lastLock=getState('mqtt.0.nuki.3583F76C.state'/*nuki/3583F76C/state*/).val; // letzter Öffnungszustand
on({id: ['mqtt.0.nuki.3583F76C.lockActionEvent'/*nuki/3583F76C/lockActionEvent*/, 'mqtt.0.nuki.3583F76C.state'/*nuki/3583F76C/state*/], change: 'ne'}, obj => {
    if(obj.id == 'mqtt.0.nuki.3583F76C.lockActionEvent') {
        let trigger=obj.state.val;
        trigger=trigger.slice(1,2);
        if(trigger == '' && lastLock != 3) {    // Nur, wenn nicht bereits geöffnet
             log('Öffnen!');
        }
    } else {
        lastLock=obj.state.val;
    }
});

Statt des Fragezeichens steht im Javascript-Editor ein STX in rotem Kästchen:

Das ist der aus dem State kopierte Wert - wird hier leider nicht richtig angezeigt.

[MrDJSage]

@grrfield Deine Lösung bringt so leider nur nicht viel. Laut MQTT Doku von Nuki enthält das lockActionEvent eine Komma separierte Liste mit der ich unteranderem erfahren kann welcher Nutzer / Gerät (Fob etc.) z.B. die Tür geöffnet hat. Genau das ist aber die Information an die ich z.B. ran möchte. Dazu müssten die kryptischen Zeichen aber irgendwie lesbar oder dekodierbar gemacht werden können.

[RK62]

@mrdjsage Ich habe das NUKI im NUKI-Web eingebunden und lese dann via API die letzten Einträge aus der Log-Datei. Dort sind alles Schließvorgänge einzeln ausgewiesen.

[grrfield]

@mrdjsage Die Lösung ist ja nur als Vorlage zu verstehen. Du mußt ausprobieren, welche Sonderzeichen bei welchen Aktionen kommen und kannst dann darauf testen. In meinem Beispiel detektiere ich lediglich den Öffnungsvorgang des Schlosses, um daraus Aktionen abzuleiten.

[MrDJSage]

@grrfield aber ich kann mir nicht vorstellen, dass das generisch für alle möglichen Werte von lockActionEvent funktioniert. Denn die Sonderzeichen sind ja sehr allgemein wie "Start of Text", "End of Text", "Start of Heading" ...

@RK62 das hatte ich mir auch schon überlegt und werde ich sicherlich demnächst mal umsetzen. Danke für den Tipp.

[newbie2007]

@mrdjsage

[newbie2007]

@smarthomenew
Hallo,
ich habe seit 3 Tagen auch das Nuki 3.0 und den MQTT-Adapter installiert.
Funktioniert auch alles, aber bei mir geht nachts auch plötzlich die Haustür auf.
Gibt es denn schon nähere Erkenntnisse, wie das problem seseitigt werden kann?
Ansonsten geht ja alles.

Aber das plötzlich die Haustür aufsteht.......

Gruß
Uwe

[RK62]

@newbie2007 Hast du in der MQTT-Instanz alle Häkchen entfernt? Im Standard ist "Eigene States beim Verbinden publizieren" eingeschaltet. Wenn das letzte Signal "Tür öffnen" war, dann gibt der Adapter genau dieses Kommando bei jeder Neuverbindung nochmal an das Schloss.

Gruß, Ralf

[kipferl]

@newbie2007

zusätzlich dieses simple blockly, das 3 sek nach jeder Änderung der "lockAction" diese wieder auf "null" setzt, sichert das auch nochmal ab.

[MartinP]

@rk62 said in Nuki Smart Lock 3.0 pro in ioBroker einbinden:

@newbie2007 Hast du in der MQTT-Instanz alle Häkchen entfernt? Im Standard ist "Eigene States beim Verbinden publizieren" eingeschaltet. Wenn das letzte Signal "Tür öffnen" war, dann gibt der Adapter genau dieses Kommando bei jeder Neuverbindung nochmal an das Schloss.

Gruß, Ralf

EIGENTLICH muss man bei diesen Settings eine eigene MQTT-Instanz für die Nuki-Schlösser aufsetzen. Wenn ich das im Kopf so durchgehe wäre das Löschen einiger der Haken für viele meiner MQTT Geräte nicht vorteilhaft. Habt Ihr eigene Instanzen für die Schlösser?

Wie schaut das eigentlich mit der rechtlichen Seite solcher Integrierungen von Schließtechnik ins Smart Home aus? Wenn sich jemand Zugang ohne Einbruchsspuren zu hinterlassen verschaffen konnte, und man stellt hinterher fest, dass das Nuki-Schloss in das Smart Home integriert wurde, könnte das schon zu Problemen mit der Hausratversicherung führen ...

[newbie2007]

@rk62 Hallo,

nein, es waren noch Haken drin, habe sie jetzt alle rausgenommen und zusätzlich das Blockly installiert, womit die Datenpunkte wieder gelehrt werden.
Vielen Dank für den Tipp.
Gruß
Uwe

Nachtrag: mit diesen Einstellungen läuft es jetzt einwandfrei.
Danke nochmal.

[newbie2007]

@kipferl meinst du den DP „lockAction“?
Oder nicht etwa die Datenpunkte „lock“ bzw. „unlock“?
Gruß
Uwe

[smarthomeNew]

@martinp Würde es auch gerne mit eigener Instanz laufen lassen. Allerdings warte ich dafür noch auf die Möglichkeit, im Nuki einen eigenen Port mitgeben zu können. Hoffe das kommt bald.

[newbie2007]

@kipferl wie steuert man eigentlich das Türschloss?
Ich dachte durch Setzen der DP „lock“ und „unlock“ auf true.
Ist das nicht so?

[kipferl]

@newbie2007

ich mach es über die LockAction wie in der Nuki MQTT API beschrieben, weil man hier mehr optionen hat als "nur" lock und unlock wie zB "full lock" welches ich gerne Nachts verwende.

[newbie2007]

@sascha-roth Hi Sascha,
wie machst du das mit der VIS?
Welches Widget hast du für die Zustandsanzeige des Schlosses genommen?
Gruß
Uwe

[dwm]

So, ich hab jetzt auch mal mit Nuki und MQTT angefangen ...
Ich finde es schon störend, dass das LockActionEvent nicht richtig funktioniert - schon weil man immer die logs von der API abrufen muss, es evt. doch Probleme mit Synchronisation und Latenzzeiten gibt.

Deswegen hab ich mal den MQTT Adapter auf Debug gestellt, ob man da was sieht ... sehr interessant.
Beispiel: Die MQTT API sagt dem Nuki, es soll aufschließen ...

mqtt.0 (14027) Client [SL3P_123456XX] received publish package {"cmd":"publish","retain":true,"qos":0,"dup":false,"length":22,"topic":"nuki/123456XX/state","payload":{"type":"Buffer","data":[50]}}
mqtt.0 (14027) Server received "nuki/123456XX/state" (number): 2

Hier kommt also nach "state" der ... Status halt, also die Nummer zwei. In der ersten Zeile steht auch im data array die "50".
50 Dezimal, Hex 32, ASCII "2". Soweit alles klar.
Es folgt:

mqtt.0 (14027) Client [SL3P_123456XX] received publish package {"cmd":"publish","retain":false,"qos":2,"dup":false,"length":44,"topic":"nuki/123456XX/lockActionEvent","payload":{"type":"Buffer","data":[49,44,49,55,50,44,48,44,48,44,48]},"messageId":4}
Server received "nuki/123456XX/lockActionEvent" (string): "\u0001¬\u0000\u0000\u0000"

Erst mal also der publish, mit unserem bekannten data buffer. Wenn man jetzt mal das array händisch in ASCII Werte übersetzt, steht da:
"1,172,0,0,0"
also genau der erwartete String für das LockActionEvent, ausgelöst von MQTT - Trigger ist 172.
Das Problem liegt in der folgenden Zeile, der Server empfängt irgend was wild binäres und interpretiert das als String.

So, hier verlässt mich jetzt mein Wissen: Liegt das am Nuki oder am MQTT Broker? Wär schön, wenn die MQTT Profis das mal ankucken könnten.

CU
Werner

[Dr. Bakterius]

@dwm Ich habe es mit MQTT mittlerweile aufgegeben. Erstens funktioniert WLAN und damit MQTT nur, wenn die Nuki-Server erreichbar sind - es funktioniert also keine rein lokale Lösung. Zweitens ist der MQTT-Betrieb unzuverlässig. Mehrfach wurde aufgesperrt obwohl kein Befehl dazu gesendet wurde.

Da ich mit keinem anderen MQTT-Gerät auch nur ansatzweise solche Probleme habe, liegt die Schuld wohl eindeutig bei Nuki. Und ich befürchte, da wird sich auch nichts ändern. Der Fokus liegt jetzt auf dem Nuki 4.0 und Matter. Da wird sich beim "alten" Nuki 3.0 nicht mehr viel tun...