NUKI Smartlock Plugin

[SchmuFoo]

über die aktuelle Beta Firmware und die aktuelle BETA-App lässt sich schonmal der status des Smartlock auslesen. über die subscription nuki/NUKIID/# bekomme ich z.b. den Lock-status, Akkustand, usw.

Tauchen die Statusdaten des MQTT aktivierten Nuki SL3P auch im Bereich http://loxberry/admin/system/mqtt-ga...?form=incoming auf?

Ich kann das Nuki per MQTT steuern und sehe Statusänderungen unter http://loxberry/admin/system/mqtt-finder.cgi habe aber keine Ahnung, wie ich die Daten nun als virtuellen Texteingang anlege (Anders als die alexa2lox Daten, dort klappt das mit dem Virtual Input Copy Button perfekt)

[Haidy]

Ich hab batteryChargeState, connected & state angelegt, diese jeweils als "Virtueller Eingang", das klappt.

[SchmuFoo]

Haidy wie genau angelegt also was den Namen angeht? Und was ist mit der http://loxberry/admin/system/mqtt-ga...?form=incoming tauchen die bei Dir auf? Thx!

[SchmuFoo]

BTW: https://developer.nuki.io/t/app-upda...5/2?u=schmufoo

[Christian Fenzl]

Du musst im MQTT Gateway als Subscription nuki/# konfigurieren, damit diese Daten weitergeleitet werden.

[SchmuFoo]

Du musst im MQTT Gateway als Subscription nuki/# konfigurieren, damit diese Daten weitergeleitet werden.

Das war es, Danke!

Ich habe heute im Laufe des Tages oftmals beobachtet, dass ich einen Befehl zweimal absenden muss - Gerade mal einen Tracker angelegt um die genauen Zeiten zu bekommen. Kannst Du mir nen Tip gehen in welche Richtung ich troubleshooten kann?

[Christian Fenzl]

Ich bin verwundert, dass in deinem Log keine UDP IN: Zeilen stehen. Darauf musst du im Log achten, ob das vom Miniserver hereinkommt.

[SchmuFoo]

Es scheint sich zu bestätigen, nahezu jeder erste Versuch kommt nicht am Loxberry MQTT Broker (Logfile) an. Ich werde gleich mal einen tcpdump anschmeißen und schauen was im Problemfall passiert.

[SchmuFoo]

Ich bin verwundert, dass in deinem Log keine UDP IN: Zeilen stehen. Darauf musst du im Log achten, ob das vom Miniserver hereinkommt.

Ah ich hatte letzten Endes (per WUI) nur im mqttfinder.log geschaut:

09:53:00.897 INFO: LoxBerry Version 3.0.0.6 ( is_raspberry.cfg is_arch_armv7l.cfg )
09:53:00.897 INFO: Loglevel: 7
09:53:00.914 OK: Reading config
09:53:00.915 INFO: Connecting MQTT Server localhost:1883
09:53:00.915 INFO: Login at MQTT Server with user loxberry

Habe nun auch das mqttgateway.log entdeckt, hier sind allgemein gesprochen UDP:IN Einträge.

Habe nun mal auf dem Wire mitgeschnitten: Wenn das Problem auftritt, kommt vom Miniserver der mDNS Lookup für loxberry.local. und das versumpft (offenbar in meinen Unifi UDM Equipment?) aufgrund dessen nichts passiert :-/

[SchmuFoo]

Habe nun mal auf dem Wire mitgeschnitten: Wenn das Problem auftritt, kommt vom Miniserver der mDNS Lookup für loxberry.local. und das versumpft (offenbar in meinen Unifi UDM Equipment?) aufgrund dessen nichts passiert :-/[/COLOR][/FONT][/COLOR][/SIZE]

Da ich nur ein Netz/VLAN habe sollte das UniFi Equipment nicht reinspucken - Die Frage ist wie ich prüfen kann, ob der Loxberry immer auf die MQTT relevanten mDNS Anfragen antwortet und ob immer die UDP Packete ankommen.

• Hier mal ein Capture wenn es im ersten Anlauf keine Reaktion (am MQTT Server sowie Nuki) gibt:

---

• Und hier wenn es im zweiten Anlauf direkt klappt:

[SchmuFoo]

• Hier mal ein Capture wenn es im ersten Anlauf keine Reaktion (am MQTT Server sowie Nuki) gibt:

Christian Fenzl ich kann nun bestätigen dass die(se) Meldung im tcpdump immer und nur dann kommt, wenn es im ersten Anlauf nicht funktioniert

Miniserver:5353 > 224.0.0.251:5353: 0 A (QM)? loxberry.local. (32)

Danach kommen immer diverse Cache Flush Meldungen (siehe Screenshot).

Riecht nach einem Timeout/Caching Thema, aber ich kann nur grob sagen dass es nach dem ersten "Freipusten" immer für sagen wir bis zu ~ 5 Minuten geht.

[Christian Fenzl]

DNS bei dir kann ich nicht bewerten.
Wo sendest du denn im virtuellen Ausgang hin?

[SchmuFoo]

DNS bei dir kann ich nicht bewerten.
Wo sendest du denn im virtuellen Ausgang hin?

/dev/udp/loxberry/11884

Als Workaround habe ich nun von Digitalausgang auf analogem gewechselt, so schickt der den Befehl eigenständig 2 mal, wenn auch mit einem Delay.

[Christian Fenzl]

Hab gerade gesehen, dass 224.0.0.251:5353 ein mDNS Request ist.
Ich weiß nicht, warum Loxone das macht und warum loxberry.local abgefragt wird (wird "loxberry" in deinem Netz richtig aufgelöst?), aber du kannst es notfalls auch mal mit
/dev/udp/192.168.1.128/11884
probieren.

[SchmuFoo]

Hab gerade gesehen, dass 224.0.0.251:5353 ein mDNS Request ist.
Ich weiß nicht, warum Loxone das macht und warum loxberry.local abgefragt wird (wird "loxberry" in deinem Netz richtig aufgelöst?), aber du kannst es notfalls auch mal mit
/dev/udp/192.168.1.128/11884
probieren.

Die Standardeinstellung meines UniFi (Dream Machine SE) Networks lautet .localdomain - Ggf. gibt es hier einen Bug im Miniserver der daraus .local macht und dann mDNS machen will.

Ich werde erstmal die IP "festverdrahten" und dann mal bei Zeiten testweise von .localdomain auf .network etc. umstellen.

Dank Dir!

[SchmuFoo]

Ich werde erstmal die IP "festverdrahten" [..].

root@loxberry:~# tcpdump -i eth0 host 192.168.1.77 and port '(11884 or 5353)' -A
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

14:14:07.317911 IP 192.168.1.77.11884 > loxberry.11884: UDP, length 26
E..6".@.@......M.....l.l.".rnuki/330FC4FC/lockAction 1
14:14:10.323464 IP 192.168.1.77.11884 > loxberry.11884: UDP, length 26
E..6-.@.@......M.....l.l.".rnuki/330FC4FC/lockAction 1
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel​

Mal schauen wie es in ~ 5-10 Minuten rum'idlen aussieht

[SchmuFoo]

Mit dem Workaround klappt es nun zuverlässig. Ich frage mal bei Loxone nach was das sein könnte.

[SchmuFoo]

root@loxberry:~# tcpdump -i eth0 host 192.168.1.77 and port '(11884 or 5353)' -A
tcpdump: verbose output suppressed, use -v[v]... for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), snapshot length 262144 bytes

14:14:07.317911 IP 192.168.1.77.11884 > loxberry.11884: UDP, length 26
E..6".@.@......M.....l.l.".rnuki/330FC4FC/lockAction 1
14:14:10.323464 IP 192.168.1.77.11884 > loxberry.11884: UDP, length 26
E..6-.@.@......M.....l.l.".rnuki/330FC4FC/lockAction 1
^C
2 packets captured
2 packets received by filter
0 packets dropped by kernel​

Mal schauen wie es in ~ 5-10 Minuten rum'idlen aussieht

Loxone Ticket ist in der erweiterten Prüfung, das Debug Material (welches meine These bestätigt) aus folgendem Screenshot habe ich noch zur Verfügung gestellt