Nuki Smart Lock 3.0 pro in ioBroker einbinden

[smarthomeNew]

@vazi Hallo, in der Instanz muss auf jeden Fall Port 1883 eingestellt sein, da Nuki diesen Port benutzt.

[A Former User]

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

@vazi Hallo, in der Instanz muss auf jeden Fall Port 1883 eingestellt sein, da Nuki diesen Port benutzt.

Danke. Wenn dieser aber wie erwähnt bereits belegt ist, spielt dies keine Rolle? @RK62 weisst ja daraufhin. Mit 1883 bleibt der Adapter rot.

Wenn ich den Sonoff-Adapter stoppe, dann funktioniert es. Kann ich den Port von Sonoff einfach ändern? Welcher?

[arteck]

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

Wenn ich den Sonoff-Adapter stoppe, dann funktioniert es. Kann ich den Port von Sonoff einfach ändern? Welcher?

klar kannst du den ändern ..musst nur alle Geräte die an Sonoff adapter senden auch umändern ..

nimm irgendwas 1888 als beispiel

[smarthomeNew]

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

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

@vazi Hallo, in der Instanz muss auf jeden Fall Port 1883 eingestellt sein, da Nuki diesen Port benutzt.

Danke. Wenn dieser aber wie erwähnt bereits belegt ist, spielt dies keine Rolle? @RK62 weisst ja daraufhin. Mit 1883 bleibt der Adapter rot.

Wenn ich den Sonoff-Adapter stoppe, dann funktioniert es. Kann ich den Port von Sonoff einfach ändern? Welcher?

Hallo, es geht nur ein Port pro Instanz. Also entweder warten, bis (ob?) Nuki nachliefert, dass man einen Port in der App einstellen kann.
Oder du änderst den Port des Sonoff Adapters und dann eben auch den Port bei allen Geräten in den MQTT Einstellungen, die mit dem Sonoff Adapter verbunden sind.

[smarthomeNew]

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

@smarthomenew
Bei mir funktioniert es wirklich blitzschnell
Auch der Status vom Türsensor wird innerhalb einer Sekunde aktualisiert.
Im Gegensatz zur Bridge funktioniert MQTT extrem schnell und zuverlässig

Kannst du bitte mal einen Screenshot deiner MQTT Instanz Einstellungen posten?

[ste_glei]

Kannst du bitte mal einen Screenshot deiner MQTT Instanz Einstellungen posten?

Hier der Screenshot

[Heiko 0]

Moin, was mache ich hier verkehrt? Ich kann bei der Rednote Einbindung nur auf den ersten Ordner zugreifen. Damit kann ich leider keine Statusmeldungen nutzen

Gruß Heiko

[A Former User]

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

klar kannst du den ändern ..musst nur alle Geräte die an Sonoff adapter senden auch umändern ..

nimm irgendwas 1888 als beispiel

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

Hallo, es geht nur ein Port pro Instanz. Also entweder warten, bis (ob?) Nuki nachliefert, dass man einen Port in der App einstellen kann.
Oder du änderst den Port des Sonoff Adapters und dann eben auch den Port bei allen Geräten in den MQTT Einstellungen, die mit dem Sonoff Adapter verbunden sind.

Ich danke Euch beiden.
Habe es nun so angewandt und es funktioniert.
Ja, da müsste NUKI nochmals über die Bücher, denn ich bin sicher nichtg der Einzige hier, der dieses Problem hat.
Ausser, dass ich einem Sonoff, welches mit Tasmota geflasht wurde nun nicht mehr erreichen kann, da dieser - warum auch immer - nach Benutzername und Passwort fragt... und ich kann mich weder daran erinnern, dass ich ein gesetzt habe, noch ... welches.... Mir ist nicht bewusst, dass ich beim Àndern des Ports auf dem Gerät in den Einstellungen unter MQTT eins gesetzt hätte....? Das Problem ist nun, dass ich zu diesem Gerät eher schlecht ran komme um es irgendwie zurückzusetzen...

Jemand eine Idee für mich?

[smarthomeNew]

@vazi
Du könntest einen Reset des Geräts durchführen, wie hier unter "Fast Power Cycle Device Recovery" geschrieben.

Eventuell hängt das Gerät in einer Steckdose mit extra Sicherung oder nur wenig anderen Geräten? Dann kannst du zum stromlos machen einfach die Sicherung an und ausschalten?

[A Former User]

@smarthomenew . Dankeschön.

War zu "vorschnell"..... Hatte das falsche Gerät angepeilt - falsche IP... Das Problem hat sich von selber gelöst, nachdem ich die richtige IP des Sonoff herausgefunden habe.

[smarthomeNew]

Bei mir scheint es jetzt auch zuverlässig zu funktionieren, Doku lesen hilft manchmal doch.
Vielleicht hilft es jemandem, hier meine Einstellungen:

MQTT Instanz:

• 
• 

.

Nuki App:

• Mit WLAN verbunden
• MQTT eingerichtet:
  
  .

Javascript Code:

        await setStateAsync('mqtt.0.nuki.00000000.lockAction', '2'); // ack=false
        await setStateAsync('mqtt.0.nuki.00000000.lockAction', '', true); // ack=true to clear the command

[RK62]

@smarthomenew Die Einstellung scheinen so noch nicht sicher zu funktionieren, bei mir wurde diese Nacht durch MQTT die Tür geöffnet. Siehe Log, scheinbar wurde hier ein neuer Connect durch das Wechseln eines Secrets ausgelöst. Ich weiß noch nicht wie ich diese Situation zum Testen nachstellen soll, ich habe jetzt im Adapter mal das Häkchen bei "States bei subscribe publizieren" raus genommen.

2023-04-20 03:02:14.420 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] reconnected. Old secret 1681779816410_2224. New secret 1681952534420_7130
2023-04-20 03:02:26.684 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] subscribes on "mqtt.0.nuki.xxxxxxxx.lockAction"
2023-04-20 03:02:26.684 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] subscribes on "mqtt.0.nuki.xxxxxxxx.lock"
2023-04-20 03:02:26.884 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] publishOnSubscribe
2023-04-20 03:02:26.885 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] publishOnSubscribe
2023-04-20 03:02:27.808 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] subscribes on "mqtt.0.nuki.xxxxxxxx.unlock"
2023-04-20 03:02:28.010 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] publishOnSubscribe
2023-04-20 03:02:31.184 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] Received pubrel for unknown message ID: 16
2023-04-20 03:02:31.185 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] Received pubcomp for unknown message ID: 2
2023-04-20 03:02:31.185 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] Received pubcomp for unknown message ID: 2

[homecineplexx]

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

@smarthomenew Die Einstellung scheinen so noch nicht sicher zu funktionieren, bei mir wurde diese Nacht durch MQTT die Tür geöffnet. Siehe Log, scheinbar wurde hier ein neuer Connect durch das Wechseln eines Secrets ausgelöst. Ich weiß noch nicht wie ich diese Situation zum Testen nachstellen soll, ich habe jetzt im Adapter mal das Häkchen bei "States bei subscribe publizieren" raus genommen.

2023-04-20 03:02:14.420 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] reconnected. Old secret 1681779816410_2224. New secret 1681952534420_7130
2023-04-20 03:02:26.684 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] subscribes on "mqtt.0.nuki.xxxxxxxx.lockAction"
2023-04-20 03:02:26.684 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] subscribes on "mqtt.0.nuki.xxxxxxxx.lock"
2023-04-20 03:02:26.884 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] publishOnSubscribe
2023-04-20 03:02:26.885 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] publishOnSubscribe
2023-04-20 03:02:27.808 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] subscribes on "mqtt.0.nuki.xxxxxxxx.unlock"
2023-04-20 03:02:28.010 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] publishOnSubscribe
2023-04-20 03:02:31.184 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] Received pubrel for unknown message ID: 16
2023-04-20 03:02:31.185 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] Received pubcomp for unknown message ID: 2
2023-04-20 03:02:31.185 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] Received pubcomp for unknown message ID: 2

ich habe das selbe problem...passiert nicht jede nacht, aber immer wieder mal und das ist dann sehr spooky, wenn dich das aufweckt.
solltet ihr eine lösung dafür wissen, wäre ich sehr froh darüber, denn meine frau macht mir deswegen das leben zur hölle

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

@smarthomenew Die Einstellung scheinen so noch nicht sicher zu funktionieren, bei mir wurde diese Nacht durch MQTT die Tür geöffnet. Siehe Log, scheinbar wurde hier ein neuer Connect durch das Wechseln eines Secrets ausgelöst. Ich weiß noch nicht wie ich diese Situation zum Testen nachstellen soll, ich habe jetzt im Adapter mal das Häkchen bei "States bei subscribe publizieren" raus genommen.

2023-04-20 03:02:14.420 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] reconnected. Old secret 1681779816410_2224. New secret 1681952534420_7130
2023-04-20 03:02:26.684 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] subscribes on "mqtt.0.nuki.xxxxxxxx.lockAction"
2023-04-20 03:02:26.684 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] subscribes on "mqtt.0.nuki.xxxxxxxx.lock"
2023-04-20 03:02:26.884 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] publishOnSubscribe
2023-04-20 03:02:26.885 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] publishOnSubscribe
2023-04-20 03:02:27.808 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] subscribes on "mqtt.0.nuki.xxxxxxxx.unlock"
2023-04-20 03:02:28.010 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] publishOnSubscribe
2023-04-20 03:02:31.184 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] Received pubrel for unknown message ID: 16
2023-04-20 03:02:31.185 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] Received pubcomp for unknown message ID: 2
2023-04-20 03:02:31.185 - info: mqtt.0 (8239) Client [SL3P_xxxxxxxx] Received pubcomp for unknown message ID: 2

[smarthomeNew]

Hallo,
hatte ich tatsächlich direkt in der Nacht nach meinem Erfolgs-Post auch.
Habe das ganze gelöst durch ein kleines JavaScript, das die MQTT Eingaben zurücksetzt und auch nochmal MQTT Einstellungen angepasst.
Läuft bei mir bisher seit Montag ohne komische Ereignisse.

Meine aktualisierten MQTT Instanz Einstellungen:

JavaScript zum Zurücksetzten der MQTT Datenpunkte:

on({id: 'mqtt.0.nuki.xxx.lock', change:"any"}, function (obj) {
    if (obj.state.val != "") {
        setState(obj.id,"");
        console.log(obj.id + " geleert.")
    }
});

on({id: 'mqtt.0.nuki.xxx.unlock', change:"any"}, function (obj) {
    if (obj.state.val != "") {
        setState(obj.id,"");
        console.log(obj.id + " geleert.")
    }
});

on({id: 'mqtt.0.nuki.xxx.lockAction', change:"any"}, function (obj) {
    if (obj.state.val != "") {
        setState(obj.id,"");
        console.log(obj.id + " geleert.")
    }
});

[Sascha Roth]

@ste_glei

Hallo, kannst du, oder irgendeiner von euch über MQTT den Datenpunkt lockActionEvent sauber auslesen?
Über den Mqtt Adapter von iObroker kommen nur komische zeichen wenn überhaupt, bzw. werden angezeigt, hatte einen LXC mit Moaquitto am Laufen, da sehe ich über den MQTT Explorer die States mit allem was dazu gehört, aber weder über über den Client Mqtt Adapter verbundem mit dem Mosquitto noch mit der MQTT als Broker , werden mir werte angezeigt, hast du oder jemand anderer ne Idee, bzw. oder wie schaut es bei euch damit aus?

MFG
Sascha

[ste_glei]

@sascha-roth

auch das gleiche Problem

[docugraf]

Ich hab jetzt den ganzen Nachmittag verbracht, mein SL3p zum Ab- und Aufsperren zu bewegen. MQTT-Kontakt ist vorhanden zum IObroker (Daten wurden ausgelesen und im IOb-Objektbaum dargestellt)

Gibt's schon JS-/ Blockly Snipets, die funktionieren?

Und bei mir (v3.6.5) bietet keinen *.lockActionEvent-Eintrag? Die Freigabe in der App unter MQTT zum sperren ist freigeschaltet

[docugraf]

Aber MQTT scheint zu arbeiten, immerhin blieb die Tür geschlossen, hab aber den Vorgang zeitlich nicht mitbekommen, somit weiss ich nicht, ob da jetzt auch die Hardware Aktion gezeit hat oder nur eine reine MQTT-Info im Log steht.

[RK62]

@docugraf

• .lockActionEvent wird scheinbar noch nicht sinnvoll seitens NUKI gefüllt. Ich lese das Log weiter mit der WebAPI aus.
• Ich habe in der MQTT-Instanz nur bei Nur bei Änderungen publizieren das Häkchen gesetzt. Damit scheint es beim Reconnect zu keinen Schliessvorgängen zu kommen.
• Sicherheitshalber setze ich mit JS die States nach Verwendung wieder zurück:

// Schlosssteuerung nach 3 Sekunden zurück setzen
on({id: /^mqtt\..*\.nuki\..*\.(lock|unlock|lockAction)$/, change: "any"}, function (obj) {
// ------------------------------------------------------------------------------------------ 
    const cRESET = 'null';
    if (obj.state.val == cRESET) return;
    setStateDelayed(obj.id, cRESET, false, 3000, true, function () {
        log(`${obj.id} zurück gesetzt.`);
    })
// ------------------------------------------------------------------------------------------ 
})

[Sascha Roth]

@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