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

[Dr. Bakterius]

@andibr Bei mir halten meine Eneloop-Akkus doch ein paar Monate durch, bei einigen Sperrvorgängen am Tag. Lässt sich dein Zylinder schwer drehen? Das benötigt dann natürlich mehr Strom.

Ich habe wegen der Sache einige Male mit Nuki hin und her geschrieben. Anfangs stellte man sich unwissend, dann die lapidare Antwort, dass WLAN deaktiviert wird wenn die Server nicht erreichbar sind und als ich einen Grund dafür verlangte und anmerkte, dass das eine Fehlkonstruktion ist und die Sicherheit einschränkt, kam nur zurück, dass sie mein Anliegen an die Zuständigen weiterleiten und die meinen "Vorschlag" evaluieren. (Sorry wegen dem Megasatz.)

Ja, es ist ein Trauerspiel... :confused:

[andibr]

@dr-bakterius
Leider wird so aus einer guten Idee, eben ein unbrauchbares Produkt. Es ist mit schon klar, dass ein kraftaufändigeres drehen, mehr Energie aus dem Speicher zieht. Auch ist WLAN und Bluetooth ja nich gerade als "stromsparend" bekannt. Damit könnte ich ja noch leben, denn mit einer PV-Anlage auf dem Dach ist Strom ein anderes Thema, aber einfach auf "taub" schalten wenn die Verbindung nicht aufgebaut werden kann ist schon eher kritisch.

Ich stelle mir einfach die Frage: haben nur die Nuki 3.0 dieses Problem oder sind die älteren mit der Bridge auch betroffen?

Es ist sicher auch eine Firmenstrategie wenn Probleme auftauchen einfach ein neues Produkt zu realisieren und das alte einfach zu ignorieren. Denn wer braucht schon Matter, das noch viel mehr auf eine zentrale Überwachungsdatenbank hinarbeitet. Es wird der Zeitpunkt kommen, wo uns die Politiker sagen wann wir in unsere Haus dürfen und wir ermöglichen ihnen das mit allen diesen Clouds sogar freiwillig noch.

Sorry, für mein etwas heftiges Statement (bin etwas desillusioniert)
Andi

[Dr. Bakterius]

@andibr sagte in Nuki Smart Lock 3.0 pro in ioBroker einbinden:

haben nur die Nuki 3.0 dieses Problem oder sind die älteren mit der Bridge auch betroffen?

Bei den älteren SmartLocks gibt es kein MQTT. Also kann da das Problem nicht auftreten. Denn die Bridge braucht man da nur für den Fernzugriff. Wenn mir einmal langweilig ist, kann ich das 3.0 pro mit einer alten Bridge verbinden und schauen ob mit dieser Konstellation WLAN und damit MQTT ohne Internetzugriff der Bridge gegeben bleibt. Aber ich traue MQTT hier nicht über den Weg wenn ohne Befehl aufgesperrt wird.

[andibr]

@dr-bakterius
Schon klar das mit dem MQTT, ich habe aber eigentlich die normale WLAN Funktion gemeint. Ich denke es liegt auch nicht explizit an der implentation von MQTT sondern viel tiefer bei der WLAN Schnittstelle.

Rein theoretisch könnte ich meine 3 Stk eben auch mit Bluetooth direkt betreiben, sofern das stabiler wäre. Denn bei mir ist die Haustüre und Wohnung EG und Wohnung 1.OG alles im Sichtbereich von der EG Wohnugstüre. Darum die Idee das ganze mit einer Bridge zu erweitern und stabilisieren. Nur leider habe ich absolut keine Idee wie ich dann denn Iob einbinden kann.

Oder eben alles wegwerfen und was besseres kaufen, nur was ist "besser".
Andi

[kipferl]

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

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

Ich finde die analyse interessant, und würde mich auch freuen wenn sich das jemand mit mehr Kenntnis anschauen könnte.

Übrigens mein Nuki 3.0 Pro funktioniert einwandfrei über MQTT, ohne ungewollte Öffnen- oder Schließ-Durchführungen.

[dwm]

Die ungewollten Öffnungsversuche hab ich ganz am Anfang gesehen - das ist genau das hier beschriebene Problem mit "Publish after Subscribe" - das ist unter Kontrolle.
Was ich halt gern machen würde wär speziell bei "Unlatch" rauszufinden wer's war.
Der Adapter ist von @Bluefox, wenn ich mich nicht irre ... ich mach da mal ein issue rein.

[martin]

Ich habe mein Nuki jetzt auch mit einer eigenen MQTT-Instanz im IOB.
Frage jetzt wie kann ich in einem Blockly-Skript einstellen, dass er das Nuki z. B. in der Nacht wenn die Haustüre abgesperrt ist öffnet etc.?

[dwm]

@martin
... müsst jetzt bei Blockly schauen, ich verwende da direkt Javascript ...

Grundsätzlich repräsentieren die MQTT Datenpunkte ja die Nuki MQTT API wie hier im PDF beschrieben: https://developer.nuki.io/t/mqtt-api-specification-v1-4/19223

D.h. Du schreibst nach "LockAction" eben die zum Beispiel die 1 für "unlock", dann sperrt das Ding auf.

Folgende Lock Actions sind möglich:
1 unlock activate rto
2 lock deactivate rto
3 unlatch electric strike actuation
4 lock ‘n’ go activate continuous mode
5 lock ‘n’ go with unlatch deactivate continuous mode
6 full lock

Fallen in die man tappen kann:

• die MQTT API muss für "sperren" freigeschaltet sein, sonst macht es halt nix.
• Wie in diesem Thread beschrieben, sollte eine LockAction nach ein paar Sekunden mit "null" und dem Ack Flag überschrieben werden, das Nuki macht alle paar Stunden einen reconnect, und wenn in der LockAction dann ein gültiges Kommando steht, wird das - je nach Einstellung des Adapters - halt NOCHMAL geschickt. Das Ergebnis ist dann, dass um halb vier Uhr morgens die Tür aufgeht.
  Bei richtiger Einstellung des MQTT Adapters sollte es das nicht brauchen, aber sicher ist sicher :)
  Kleines Code-Snippet zur Illustration:

var MqttAdapterId ='mqtt.0';
var NukiId = '1234565x';

// reset MQTT lockAction data point to null after 5 sec. for security reasons
on ({id: [
            MqttAdapterId+'.nuki.'+NukiId+'.lockAction',
            MqttAdapterId+'.nuki.'+NukiId+'.lock',
            MqttAdapterId+'.nuki.'+NukiId+'.unlock'
         ], valNe: null, change: 'any'},
    function(dp) {
        setStateDelayed ( dp.id, null, 5000, true );
});

[dwm]

Vielleich noch ein paar Worte zum "LockActionState" ...
Hab da mal auf github beim MQTT Adapter ein issue eingetragen, und ich glaub die bei Nuki haben das auch schon gehört ;) ... braucht halt alles Zeit.
Es gibt bei den Nukis übrigens grade anscheinend ne Beta-Firmware, die angeblich die angesprochenen Problemchen mit WLAN und MQTT lokal etc. adressiert. Mal schaun.

Ich hab jetzt mal einen extrem üblen und grauslichen Workaround gebaut ...
Grundidee: Nachdem die richtigen Daten ja im debug log stehen, muss man die ja eigentlich nur da rausholen ...

Also:

• mqtt Adapter auf debug stellen, so dass alles getraced wird. Im log müssen die Meldungen auftauchen, wie paar Beiträge weiter oben beschrieben.
• Eigene logparser Instanz, mit den Einstellungen für den Parser:
  Name: NukiLockActionEvent
  Whitelist UND: /mqtt.[0-9].*lockActionEvent.*payload/
  Häkchen bei "Debug" gesetzt
  Max 1024
  Bereinigen: /mqtt.[0-9].*publish\spackage\s/
  Leeren nach 2 Tagen

Ich hab die Liste auf 20 Einträge beschränkt. Damit hab ich eine Liste mit den 20 letzten MQTT LockEvent data payloads :)

Wenn jetzt auf mqtt.0 ein LockActionEvent kommt (das Event ist ja da, auch wenn mehr oder weniger Unsinn drinsteht), mache ich beim Logparser ein "ForceUpdate", und lese bisschen später das payload aus dem log aus. Voila.

Grobes Code Snippet zur Illustration:

function bin2String(arr) {
  let result = '';
  for (let i = 0; i < arr.length; i++) {
    result += String.fromCharCode(arr[i]);
  }
  return result;
}

function getLastestLockActionEvent(){
    let result = {
        lockActionEventStr : null,
        ts              : null,
    };

    let logEntry = getState('logparser.1.filters.NukiLockActionEvent.json'/*Json*/).val;

    try {
        let logObj = JSON.parse(logEntry);
        if (logObj.length == 0) return null;
        
        let logMessage = JSON.parse(logObj[0].message);
        result.lockActionEventStr = bin2String(logMessage.payload.data);
        result.ts = logObj[0].ts;
        let dt = new Date(result.ts);
        result.timeStamp = dt.toISOString();
    } catch (e) {
        return null;
    }
    return result;
}

function NukiLockActionEventVerification(){
    let lockActionEvt = getLatestLockActionEvent();
    // debug output
    console.log(JSON.stringify(lockActionEvt));

    if (lockActionEvt !== null){
        let tokenized = lockActionEvt.lockActionEventStr.split(',');
              
        // act accordingly ... 
    } else {
        // error handling
   }
}

function NukiLockActionEventChange(dp){              
    setStateDelayed('logparser.1.forceUpdate'/*Force updating all states immediately*/, true,50);
    setTimeout( NukiLockActionEventVerification , 250, dp.ts );
}

on ({id: MqttAdapterId+'.nuki.'+NukiId+'.lockActionEvent', change: 'any' }, NukiLockActionEventChange );

Ich hoffe mal, das ist einigermassen verständlich.
Das Ganze klappt grundsätzlich ganz nett, aber ist aber halt schon recht komplex dafür, dass der String ja einfach so dastehen sollt ... :face_with_rolling_eyes: .

[martin]

@dwm Danke. Das hilft mir schon mal weiter.
Was ich nicht verstehe ist "Ack Flag". Dass da nach ein paar Sekunden wieder "null" rein soll habe ich verstanden. Aber wer, wie, was ist Ack Flag?

[mooly]

Hallo!

Kann mir bitte jemand einen Tipp geben:

Wie kann ich die States des Door-Sensors und der Schließzustandes ausgeben lassen in meiner VIS? Ich verstehe das Prinzip, aber wie setze ich das um?

Also ich will im ersten Schritt einfach nur sehen ist die Tür offen oder geschlossen und ist die Tür verriegelt oder entriegelt?

Ich würde mich freuen wenn mir jemand helfen könnte. MQTT läuft ohne Probleme, aber ich bekomme es nicht hin mir die States ausgeben zu lassen.

[mooly]

@sascha-roth said in Nuki Smart Lock 3.0 pro in ioBroker einbinden:

@rk62
Das mit dem .lockActionEvent stimmt nicht, was du schreibst, wenn ich das Schloss per Mosquito MQTT Server verbinde, auf meinem Proxmox per LXC, und dann mit dem MQTT Explorer das ganze auslese, zeigt er mir Werte wie in der Nuki MQTT Api beschrieben an.
Nutze ich dann den MQTT ioBroker MQTT Client Adapter kommen genauso wie wenn ich den MQTT Broker Adapter nutze nur diese komischen zeichen an, somit gehe ich davon aus, das es am ioBroker Mqtt Adapter liegt!

Das mit Nur bei Änderungen publizieren kann ich ebenfalls bestätigen, bzw. auch wenn alle Haken raus sind, hat das Schloss kein eigenleben mehr, bzw. Schließt nicht aufeinmal Automatisch auf! Problem wird sein, das im Lock Action State die Zahl stehen bleibt, die als letztes gewält wurde, selbst wenn es die 2 ist, was abschließen ist, ist die türe bereits abgeschlossen, und bekommt dann nach Trennung oder neu Verbindung wieder den State 2 mach das Schloß Lock & Go und Tür öffnen, dies konnte ich mehrfach reproduzieren! Dadurch, steht dann die Türe aufeinmal komplett offen!

3.4 Lock Actions

1 > unlock = aufschließen
2 > lock = abschließen
3 > unlatch = Türe öffnen
4 > lock ‘n’ go = Lock ‘n’ Go
5 > lock ‘n’ go with unlatch = Lock ‘n’ Go & Türe öffnen
6 > full lock = abschließen
80 > fob (without action) =
90 > button (without action) =

3.3 Lock States

0 > uncalibrated = Türe unkalibriert
1 > locked = Türe abgeschlossen
2 > unlocking = Türe aufschließen
3 > unlocked = Türe aufgeschlossen
4 > locking = Türe abschließen
5 > unlatched = Tür öffnen
6 > unlocked (lock ‘n’ go) = Lock ‘n’ Go
7 > unlatching = Lock ‘n’ Go & Türe öffnen
253 > -
254 > motor blocked = Motor Blockiert
255 > undefined = nicht definiert

Hallo!

Das sieht wirklich klasse aus. Kannst du mir verraten, wie du die Lockstates bzw. Doorstates abfrägst? Ich habe MQTT eingerichtet, aber ich habe noch keinen genauen plan, wie ich diese abfrage, weil es ja keinen true/false wert z.B. zum Tür offen/zu gibt, sonder ich diese States von 1-5 z.B. auslesen muss um sie entsprechend in der VIS darstellen zu können. OMG leicht noobig ausgedrückt, sorry. Ich denke du weisst was ich meine.

DANKE!

LG

[andibr]

@mooly

Also ich habe für meine 3stk Nuki 3.0 aus dem "vis-inventwo" so ein "Multi-Widget" genommen, damit kann man mehrere Zustände im gleichen Widget definieren. Sprich ich habe dort den Status aus den Objekten eingefügt und dann entsprechend die einzelnen Zustände konfiguriert.
Gruss Andi

[mooly]

@andibr

soweit war ich auch schon... aber woher weiß das Widget, dass z.B. Lock-Status "2" geschlossen heisst? Drücke ich mich unverständlich aus? Also welchen Datenpunkt hast du im Multi-Widget genutzt um die anzeigen zu lassen, wie der Tür-Status ist?

[Longbow]

Hallo in die Runde,

ich habe ein Nuki Smart Lock 3.0 pro, also da mit Wlan und ohne Bridge.
Jetzt habe das Schloss in der App alles freigegeben, was MQTT angeht.
Im MQTT Explorer sehe ich das Schloss, wie auch den DoorSensor, mit Werten etc.

Wenn ich bei ,,state'' jetzt einen anderen Wert/ Zahl eingebe, schreibt er das überall, spricht im iobroker wie auch in dem MQTT Explorer. Somit denke, ich dass die zusammen kommunizieren, aber es passiert einfach nichts am Schloss selbst.

Somit stimmt doch was oder sehe ich das falsch. Wenn ich in der App sagen abschließen, sehe ich im ioborker den Wert und im Explorer, aber es passiert nicht.

Wann was kann das liegen? Wie bekommt man das Schloss am besten in den ioborker?

Wenn wir uns dieses Jahr nicht mehr lesen, Euch einen guten Rutsch ins neue Jahr

[andibr]

@mooly
Das ist relativ einfach, es ist der Datenpunkt "state" und für den gibt es hier weiter oben eine Tabelle in der steht was welcher Wert bedeutet und mit diesem habe ich dann ein Bild definiert

so kannst du im Widget eine Abfrage im Feld "Wert(x)" erstellen und das entsprechende Bild erscheinen lassen. Da ich das ganz bis jetzt nur zur Anzeige nutze, kann ich dir nicht sagen ob man mit diesem Widget auch ein Skript zum absetzen eines schliess/öffnungs-Befehl aufrufen kann. Aber es gibt im invetwo auch Widget die als Taster definiert werden können.

[Percy]

Gibt es neue Erkenntnisse bezüglich des lockactionstate Problems? Löst die beta Firmware des Nuki das Problem?

[crazyskater]

Ich habe seit 3 Wochen ein Problem, dass beim aufschließen also LOCKACKTION 3, das Schloß sich 5x aufschließt.
Im mqtt Log sehe ich jede Nachricht, egal ob aufschließen oder zuschließen die per mqtt ans Schloß geht 11x.
dann kommt die Meldung:
Client [SL3P_1234DC6C] Message 2 deleted after 11 retries
Es sieht so aus, als merkt der mqtt Adapter nicht, dass es vom Schloß empfangen ist.
Will der Adapter eine Response vom Schloß? Ich dachte er gibt die Nachricht an tcpstack und der macht retry, wenn das tcp ACK fehlt.
Im tcpdump sehe ich die Nachrichten auch rausgehen, und ab der 2ten ist auch das DUP Flag gesetzt.

Dieses Verhalten jetzt sind sehr komisch.

[andibr]

@crazyskater
Ich habe es aufgegeben das ganze mit Smart Home zu machen. Ich habe im Iobroker den zusätzliche MQTT Adapter gelöscht und auch alle Objekte dazu. Den Gerüchten zu folge wird da beim Nuki 3.0 auch nichts mehr geschehen in Richtung neuer Firmeware.

Leider fokussieren die sich nun auf Appel und Matter und kennen die alten Produkte gar nicht mehr.
Das ganze Konzept war genau bis zum Entscheid für Matter ganz gut. Seither kommen nur noch Dinge die am besten zu Appel passen.

Vermutlich werfe ich meine 3stk beim nächsten Problem weg. Denn auch die versprochene Notfunktion mit die Schlüssel von aussen geht nicht. Auch nach mehrmaligem neuen synchronisieren und abgleichen geht nach dem ersten Abschiessvorgang der Schlüssel von aussen nicht mehr. Oder das einer bei mir ohne Programierung einfach plötzlich auf oder zu schliesst. Sobald WLAN weg ist bewegt er sich einfach in die andere Richtung egal wo er war.

Darum kann es sein das ich bald 3stk über hab.
Ich bin massiv entäuscht.

[Walter White]

@andibr also bei mir funktioniert das Schloss mit mqtt wunderbar.

Und Nuki verspricht gar keine notfallfunktion, sondern empfiehlt dringend ein Zylinder mit notfallfunktion zu verwenden bevor man das Schloss anbaut.
Das heißt wenn bei dir die notfunktion nicht funktioniert, dann ist der Zylinder einfach nicht geeignet.