NUKI Hub

[da.phreak]

Es gibt das Release 2.0, damit werden wie genannt LAN-Module der W5x00-Familie unterstützt (W5500, W5200, W5100). Wie das verkabelt wird steht in der Readme.

[da.phreak]

Und mit der Version 2.1 wird landet auch authorization id und name in mqtt (wenn eingeschaltet).

[Dragon]

So, habe Mal diesen ESP bestellt, programmiert und eingerichtet. Es funktioniert sogar tausend Mal besser als die originale Bridge. Bin extrem begeistert, vielen Dank dafür!

[Great SUN]

@dragon sagte in NUKI Hub:

So, habe Mal diesen ESP bestellt, programmiert und eingerichtet. Es funktioniert sogar tausend Mal besser als die originale Bridge. Bin extrem begeistert, vielen Dank dafür!

Ich bin auch dabei... Meiner kommt Freitag.

[da.phreak]

@dragon Das freut mich zu hören. Was ist denn da Deiner Meinung nach besser? Mir fehlt der Vergleich, ich hab mir erst garkeine Bridge gekauft.

[Dragon]

@da-phreak die Bridge fällt mir immer Mal wieder aus und reagiert nicht auf die Befehle. Der Hub war vorhin nicht mehr online. Mal schauen ob das ein einzelner Ausfall war oder ob das regelmäßig passiert...

[da.phreak]

@dragon Klingt ja nicht so gut

[Great SUN]

@da-phreak Ich hätte da noch so eine Frage...
Mit dem Setup von Dir. Wäre es da theoretisch auch möglich, dass ich mein Handy anlerne/koppele und dass immer wenn eine entsprechende Verbindung aufgebaut wird, das an ioBroker kommuniziert wird?

[Dragon]

@da-phreak Scheint ein Problem in meinem System gewesen zu sein. Kam nicht wieder vor. Also alles gut.
Es gibt aber ein kleines Problem. Der Punkt "mqtt.0.nuki.lock.action" ist ein Type "Number". Die Schriftzüge um die entsprechende Aktion auszulösen ist aber Text. Darum wird jedes mal ein Fehler angezeigt. Wenn ich es per Hand auf String ändere passt leider die Antwort vom Hub nicht mehr zum Datenpunkt. Macht zwar weniger Ärger ist aber immer noch nicht gut. Könntest du das bitte ändern?

[da.phreak]

@dragon Interessant ist mir garnicht aufgefallen. Den Typ setze ich garnicht explizit, sondern das findet die MQTT library selber raus. Wenn ich einen leeren string übergebe, macht sie daraus "number".

Im Release 2.2 setze ich den Knoten entweder auf "ack" oder auf "unknown_command", damit ist das dann ein string.

[Dragon]

@da-phreak super danke dir! Sonst funzt es problemlos!

[Great SUN]

@dragon Irgendwas mache ich falsch...
Ich bekomm das Nuki nicht gepaired.
Muss das Nuki denn jungfräulich sein, damit das geht, oder welche Basis brauche ich?

PIN habe ich übers WebInterface hinterlegt. Bridge ist stromlos und Disconnected. Bluetooth Pairing ist aktiv.

[Great SUN]

@da-phreak @Dragon Habs... Da gab es noch eine etwas versteckte Anleitung zum Pairing: https://github.com/technyon/nuki_ble/tree/e9fca7b48d6334591493dd03a6d63c7577c7604e
Kannst Du Die evtl. in der Haupt-Readme des Projektes noch unter Pairing verlinken?

Danke!

[Great SUN]

@da-phreak Ich hab da ein Problem gefunden, bei dem ich nicht direkt eine Lösung finde. Bei mir wird ab und an das WiFi disconnected, weil ich ein Mesh-Netz habe bei dem die Devices ab uns an von einem zum anderen AP geschoben werden.
Das macht Deine FW noch nicht mit, dann bleibt das Gerät offline
Kannst Du das bitte implementieren?

VIELEN LIEBEN DANK!!!

[da.phreak]

@great-sun Es steht doch in meiner Anleitung "enable pairing mode" ... den Button auf dem NUKI für einige Sekunden gedrückt halten. Genauso wie mein eine Handy, Bridge oder Fob anlernen werde.

Wifi gucke ich mir nochmal an, an sich sollte ein reconnect ausgelöst werden, wenn die Verbindung weg ist.

[Great SUN]

@da-phreak Vielleicht hängt der sich auch auf...
Ich hab die Anleitung im Github gelesen, da hab ich es, wenn, dann wohl überlesen... Aber wie dem auch sei
Ich schau gerade, dass ich das in meine MQTT Struktur rein bekomme, Apropos...
Wenn ich bei MQTT Path abc/blah/fasel eingebe, geht nix mehr mit Daten schicken, so wie es bei mir aussieht.

[Great SUN]

@da-phreak Aber richtig genial ist die Verbindungszeit... Das Ding ist immer das erste, wenn ich den MQTT Broker durchstarte

[da.phreak]

@great-sun Ich hab's mir mit WiFi reconnect grad nochml getestet, funktioniert bei mir. Ansonsten kannst Du Dir auch ein W5500 LAN-Modul kaufen und über LAN gehen.

Hat ansonsten noch wer Probleme mit WiFi?

[Great SUN]

@da-phreak sagte in NUKI Hub:

@great-sun Ich hab's mir mit WiFi reconnect grad nochml getestet, funktioniert bei mir. Ansonsten kannst Du Dir auch ein W5500 LAN-Modul kaufen und über LAN gehen.

Hat ansonsten noch wer Probleme mit WiFi?

4 bytes from 192.168.51.34: icmp_seq=832 ttl=255 time=405 ms
64 bytes from 192.168.51.34: icmp_seq=833 ttl=255 time=128 ms
64 bytes from 192.168.51.34: icmp_seq=834 ttl=255 time=152 ms
64 bytes from 192.168.51.34: icmp_seq=835 ttl=255 time=824 ms
64 bytes from 192.168.51.34: icmp_seq=836 ttl=255 time=208 ms
64 bytes from 192.168.51.34: icmp_seq=837 ttl=255 time=1788 ms
64 bytes from 192.168.51.34: icmp_seq=838 ttl=255 time=781 ms
64 bytes from 192.168.51.34: icmp_seq=839 ttl=255 time=2398 ms
64 bytes from 192.168.51.34: icmp_seq=840 ttl=255 time=1349 ms
64 bytes from 192.168.51.34: icmp_seq=841 ttl=255 time=326 ms
64 bytes from 192.168.51.34: icmp_seq=842 ttl=255 time=89.8 ms
64 bytes from 192.168.51.34: icmp_seq=843 ttl=255 time=421 ms
64 bytes from 192.168.51.34: icmp_seq=844 ttl=255 time=206 ms
64 bytes from 192.168.51.34: icmp_seq=845 ttl=255 time=157 ms
64 bytes from 192.168.51.34: icmp_seq=846 ttl=255 time=68.4 ms
64 bytes from 192.168.51.34: icmp_seq=847 ttl=255 time=981 ms
64 bytes from 192.168.51.34: icmp_seq=848 ttl=255 time=308 ms
64 bytes from 192.168.51.34: icmp_seq=849 ttl=255 time=118 ms
64 bytes from 192.168.51.34: icmp_seq=850 ttl=255 time=362 ms
64 bytes from 192.168.51.34: icmp_seq=851 ttl=255 time=1193 ms
64 bytes from 192.168.51.34: icmp_seq=852 ttl=255 time=131 ms
From 192.168.48.1 icmp_seq=861 Destination Host Unreachable
From 192.168.48.1 icmp_seq=862 Destination Host Unreachable
From 192.168.48.1 icmp_seq=863 Destination Host Unreachable
From 192.168.48.1 icmp_seq=864 Destination Host Unreachable
From 192.168.48.1 icmp_seq=865 Destination Host Unreachable
From 192.168.48.1 icmp_seq=866 Destination Host Unreachable
64 bytes from 192.168.51.34: icmp_seq=858 ttl=255 time=10343 ms
64 bytes from 192.168.51.34: icmp_seq=859 ttl=255 time=9332 ms
64 bytes from 192.168.51.34: icmp_seq=860 ttl=255 time=8341 ms
64 bytes from 192.168.51.34: icmp_seq=867 ttl=255 time=15767 ms
64 bytes from 192.168.51.34: icmp_seq=868 ttl=255 time=14745 ms
64 bytes from 192.168.51.34: icmp_seq=869 ttl=255 time=13753 ms
64 bytes from 192.168.51.34: icmp_seq=870 ttl=255 time=12706 ms
64 bytes from 192.168.51.34: icmp_seq=871 ttl=255 time=11682 ms
64 bytes from 192.168.51.34: icmp_seq=872 ttl=255 time=10709 ms
64 bytes from 192.168.51.34: icmp_seq=873 ttl=255 time=9663 ms
64 bytes from 192.168.51.34: icmp_seq=874 ttl=255 time=8639 ms
64 bytes from 192.168.51.34: icmp_seq=875 ttl=255 time=7689 ms
64 bytes from 192.168.51.34: icmp_seq=876 ttl=255 time=6645 ms
64 bytes from 192.168.51.34: icmp_seq=877 ttl=255 time=5622 ms
64 bytes from 192.168.51.34: icmp_seq=878 ttl=255 time=4622 ms
64 bytes from 192.168.51.34: icmp_seq=879 ttl=255 time=3574 ms
64 bytes from 192.168.51.34: icmp_seq=880 ttl=255 time=2551 ms
64 bytes from 192.168.51.34: icmp_seq=881 ttl=255 time=1550 ms
64 bytes from 192.168.51.34: icmp_seq=882 ttl=255 time=504 ms
64 bytes from 192.168.51.34: icmp_seq=883 ttl=255 time=1348 ms
64 bytes from 192.168.51.34: icmp_seq=884 ttl=255 time=2117 ms
64 bytes from 192.168.51.34: icmp_seq=885 ttl=255 time=1211 ms
64 bytes from 192.168.51.34: icmp_seq=886 ttl=255 time=185 ms
64 bytes from 192.168.51.34: icmp_seq=887 ttl=255 time=174 ms
64 bytes from 192.168.51.34: icmp_seq=888 ttl=255 time=119 ms
64 bytes from 192.168.51.34: icmp_seq=889 ttl=255 time=433 ms
64 bytes from 192.168.51.34: icmp_seq=890 ttl=255 time=145 ms
64 bytes from 192.168.51.34: icmp_seq=891 ttl=255 time=64.4 ms
64 bytes from 192.168.51.34: icmp_seq=892 ttl=255 time=117 ms
64 bytes from 192.168.51.34: icmp_seq=893 ttl=255 time=98.8 ms
64 bytes from 192.168.51.34: icmp_seq=894 ttl=255 time=263 ms
64 bytes from 192.168.51.34: icmp_seq=895 ttl=255 time=184 ms

Hab das bei dem selben Device mit Tasmota32 Bluetooth mal versucht, damit möglichst alle Begebenheiten nahe an das Setup mit Deiner FW kommen und hab da das Problem nicht sehen können.

Im Moment gibt es gerade nicht so viele "Aussetzer" aber es kam gestern z.B. schon öfter vor, dass ich das Ding neu starten musste, damit es wieder online kommt.
Kabel ist an der Stelle, wo es sein muss, um per Bluetooth eine Verbindung mit dem Schloss zu haben extrem schwer. Am Liebsten würde ich es sogar in die Wand bauen, da die Bluetooth Verbindung da wo es ist immernoch "nur" ca. 76db hat.

Daher würde ich es super toll finden, wenn das ganze dauerhaft stabil ans Laufen kommen könnte. Die Nuki Bridge lasse ich erstmal raus jetzt und versuche so gut es irgend geht beim debuggen zu helfen. Sag mir bitte gern einfach was ich genau machen soll (gern auch als PM).

Das zu Grunde liegende Gerät ist: Hailege ESP32 ESP-32S ESP-WROOM-32 Development Board 2.4GHz Dual Mode WiFi + Bluetooth Dual Cores Microcontroller Processor Integrated with Antenna RF AMP Filter AP STA IDE

Danke für Deine Unterstützung!!!

[da.phreak]

@great-sun Wie ist der WLAN-Empfang dort? Die ESP32-Devkits haben nicht grad tolle Antennen, da sollte schon guter Empfang sein. Ich würde fast behaupten da stört irgendwas bei dir, die Antwortzeiten streuen ja heftig, teilweise über 10 Sekunden ist schon extrem. Bei mir sind es fast immer unter 100ms.

Du könntest noch nen Laptop an den USB-Port anschließen und mit z. B. hterm gucken, was da passiert.

Man könnte sonst noch einbauen, daß der ESP sich selber neu startet, wenn über längeren Zeitraum keine Verbindung besteht.