NEWS
Nuki Smart Lock 3.0 pro in ioBroker einbinden
-
@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.
-
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.") } });@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 -
@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@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
-
@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ß
Uwezusätzlich dieses simple blockly, das 3 sek nach jeder Änderung der "lockAction" diese wieder auf "null" setzt, sichert das auch nochmal ab.
-
@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
@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 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
@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ß
UweNachtrag: mit diesen Einstellungen läuft es jetzt einwandfrei.
Danke nochmal. -
zusätzlich dieses simple blockly, das 3 sek nach jeder Änderung der "lockAction" diese wieder auf "null" setzt, sichert das auch nochmal ab.
@kipferl meinst du den DP „lockAction“?
Oder nicht etwa die Datenpunkte „lock“ bzw. „unlock“?
Gruß
Uwe -
@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 ...
@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.
-
zusätzlich dieses simple blockly, das 3 sek nach jeder Änderung der "lockAction" diese wieder auf "null" setzt, sichert das auch nochmal ab.
-
@kipferl wie steuert man eigentlich das Türschloss?
Ich dachte durch Setzen der DP „lock“ und „unlock“ auf true.
Ist das nicht so?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.
-
@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
@sascha-roth Hi Sascha,
wie machst du das mit der VIS?
Welches Widget hast du für die Zustandsanzeige des Schlosses genommen?
Gruß
Uwe -
@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ß
UweSo, 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): 2Hier 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 -
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): 2Hier 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@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...
-
@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...
@dr-bakterius
Leider habe ich genau die gleichen Erfahrungen mit dem Nuki 3.0 gemacht. Plötzlich sind die auch via die Nuki App nicht mehr erreichbar, obwohl mein Accesspoint direkt neben der Türe hängt, oder er verliert einfach die MQTT Einstellungen. Die Original Akku meiner 3stk halten im Schnitt ca 3-4 Wochen, bei teilweise sehr seltenen drehvorgängen.Einer meiner 3stk macht beim Verlust des Wlan immer eine Türschliessung, was eigentlich ja eine gute Sache wäre, wenn er nur den Zylinder wieder in die Ruheposition zurück drehen würde. Ich habe den schon mehrfach abgenommen und neu positioniert, aber scheinbar werden da nicht alle Winkelschritte korrekt gezählt.
Grundsätzlich bin ich etwas frustriert, das man für soviel Geld es nicht besser hinkriegt.
Andi
-
@dr-bakterius
Leider habe ich genau die gleichen Erfahrungen mit dem Nuki 3.0 gemacht. Plötzlich sind die auch via die Nuki App nicht mehr erreichbar, obwohl mein Accesspoint direkt neben der Türe hängt, oder er verliert einfach die MQTT Einstellungen. Die Original Akku meiner 3stk halten im Schnitt ca 3-4 Wochen, bei teilweise sehr seltenen drehvorgängen.Einer meiner 3stk macht beim Verlust des Wlan immer eine Türschliessung, was eigentlich ja eine gute Sache wäre, wenn er nur den Zylinder wieder in die Ruheposition zurück drehen würde. Ich habe den schon mehrfach abgenommen und neu positioniert, aber scheinbar werden da nicht alle Winkelschritte korrekt gezählt.
Grundsätzlich bin ich etwas frustriert, das man für soviel Geld es nicht besser hinkriegt.
Andi
@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 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:
@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
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@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 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.
@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 -
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): 2Hier 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@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): 2Hier 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
WernerIch 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 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): 2Hier 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
WernerIch 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.
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.
793
Online32.4k
Benutzer81.5k
Themen1.3m
Beiträge