NEWS
Warnung für Nuki im betrieb mit MQTT !!
-
Hallo zusammen.
Nimmt Mann mit wenig wissen über das ganze ( so wie ich ) ,
das Nuki mit den Standardeinstellungen des MQTT Brokers in Betrieb.
Ist es Möglich das sich eine ungünstige Vorkonfiguration ergibt.Startet der MQTT Adapter neu, bzw. der IO Broker, Bzw. der Container, bzw der Server,
schließt das schloss im dümmsten Fall auf !!!!Hier habe ich einen Beitrag gefunden der das gut beschreibt und gleich die lösung liefert:
""
In der MQTT-Instanz des IOBrokers gibt es unter den MQTT-Einstellungen einen Konfigurationspunkt „Eigene States beim Verbinden veröffentlichen“. Nimm da mal den Haken raus. Der ist standardmäßig aktiviert.
Bei mir ist die Tür sporadisch aufgegangen (auch komplett auf). Fan und ich bin nicht so lustig. Bis ich dann bemerkte, dass dieses Verhalten auftritt, sobald der Raspbery mit dem IOBroker gebootet wurde oder die Adapterinstanz neu gestartet wurde. Vermutlich auch, wenn der IOBroker neu gestartet wird.Die jeweils letzte Aktion am NUKI zB „zusperren“, merkt sich der Datenpunkt vom IOBroker! Wenn Du dann neu startest und damit die Verbindung erneut herstellst, sendet der MQTT-Adapter des IObrokers erneut den gemerkten Zustand und schließt wieder zu. Wenn dann die letzte Aktion vor dem Reboot „Tür öffnen“ war, steht irgendwann zB nach einem Stromausfall Deine Tür auf.
""Testen könnt ihr ob der Fehler besteht in dem ihr eben den adapter neu startet und wartet bis er sich wieder eigenständig mit dem Nuki verbindet.
Mir läufts noch eiskalt den Rücken runter :-)
Balu
-
Hallo zusammen.
Nimmt Mann mit wenig wissen über das ganze ( so wie ich ) ,
das Nuki mit den Standardeinstellungen des MQTT Brokers in Betrieb.
Ist es Möglich das sich eine ungünstige Vorkonfiguration ergibt.Startet der MQTT Adapter neu, bzw. der IO Broker, Bzw. der Container, bzw der Server,
schließt das schloss im dümmsten Fall auf !!!!Hier habe ich einen Beitrag gefunden der das gut beschreibt und gleich die lösung liefert:
""
In der MQTT-Instanz des IOBrokers gibt es unter den MQTT-Einstellungen einen Konfigurationspunkt „Eigene States beim Verbinden veröffentlichen“. Nimm da mal den Haken raus. Der ist standardmäßig aktiviert.
Bei mir ist die Tür sporadisch aufgegangen (auch komplett auf). Fan und ich bin nicht so lustig. Bis ich dann bemerkte, dass dieses Verhalten auftritt, sobald der Raspbery mit dem IOBroker gebootet wurde oder die Adapterinstanz neu gestartet wurde. Vermutlich auch, wenn der IOBroker neu gestartet wird.Die jeweils letzte Aktion am NUKI zB „zusperren“, merkt sich der Datenpunkt vom IOBroker! Wenn Du dann neu startest und damit die Verbindung erneut herstellst, sendet der MQTT-Adapter des IObrokers erneut den gemerkten Zustand und schließt wieder zu. Wenn dann die letzte Aktion vor dem Reboot „Tür öffnen“ war, steht irgendwann zB nach einem Stromausfall Deine Tür auf.
""Testen könnt ihr ob der Fehler besteht in dem ihr eben den adapter neu startet und wartet bis er sich wieder eigenständig mit dem Nuki verbindet.
Mir läufts noch eiskalt den Rücken runter :-)
Balu
Über welchen der beiden Adapter sprechen wir?
Mit dem 'nuki-extended' ist mir das noch nie untergekommen.Edit: Also direkt per mqtt?
-
Über welchen der beiden Adapter sprechen wir?
Mit dem 'nuki-extended' ist mir das noch nie untergekommen.Edit: Also direkt per mqtt?
-
Über welchen der beiden Adapter sprechen wir?
Mit dem 'nuki-extended' ist mir das noch nie untergekommen.Edit: Also direkt per mqtt?
-
verstehe ich das richtig das die 2 Nuki adapter auch ohne cloud / internet Lokal funktionieren ?
@balu-0 sagte in Warnung für Nuki im betrieb mit MQTT !!:
verstehe ich das richtig das die 2 Nuki adapter auch ohne cloud / internet Lokal funktionieren ?
Soweit ich weiß schon. Wobei ich den 'nuki-extended' genau deswegen verwende, weil der mit der web-API besser zurande kommt.
-
Hallo zusammen.
Nimmt Mann mit wenig wissen über das ganze ( so wie ich ) ,
das Nuki mit den Standardeinstellungen des MQTT Brokers in Betrieb.
Ist es Möglich das sich eine ungünstige Vorkonfiguration ergibt.Startet der MQTT Adapter neu, bzw. der IO Broker, Bzw. der Container, bzw der Server,
schließt das schloss im dümmsten Fall auf !!!!Hier habe ich einen Beitrag gefunden der das gut beschreibt und gleich die lösung liefert:
""
In der MQTT-Instanz des IOBrokers gibt es unter den MQTT-Einstellungen einen Konfigurationspunkt „Eigene States beim Verbinden veröffentlichen“. Nimm da mal den Haken raus. Der ist standardmäßig aktiviert.
Bei mir ist die Tür sporadisch aufgegangen (auch komplett auf). Fan und ich bin nicht so lustig. Bis ich dann bemerkte, dass dieses Verhalten auftritt, sobald der Raspbery mit dem IOBroker gebootet wurde oder die Adapterinstanz neu gestartet wurde. Vermutlich auch, wenn der IOBroker neu gestartet wird.Die jeweils letzte Aktion am NUKI zB „zusperren“, merkt sich der Datenpunkt vom IOBroker! Wenn Du dann neu startest und damit die Verbindung erneut herstellst, sendet der MQTT-Adapter des IObrokers erneut den gemerkten Zustand und schließt wieder zu. Wenn dann die letzte Aktion vor dem Reboot „Tür öffnen“ war, steht irgendwann zB nach einem Stromausfall Deine Tür auf.
""Testen könnt ihr ob der Fehler besteht in dem ihr eben den adapter neu startet und wartet bis er sich wieder eigenständig mit dem Nuki verbindet.
Mir läufts noch eiskalt den Rücken runter :-)
Balu
@balu-0 Hi, ich weiß nicht ob das nützlich ist, aber von meiner Seite aus kann ich Folgendes sagen:
Ich habe den Nuki 4 Pro wegen des WiFi und MQTT gekauft und ihn mit dem MQTT Broker/Client genutzt. Dabei habe ich festgestellt, dass das Nuki MQTT nicht ohne deren Server funktioniert, was für mich ein Unding ist. MQTT sollte im eigenen Heimnetz ohne externe Verbindung funktionieren, außer man möchte es anders (ich nicht). Inzwischen scheint laut deren Entwickler Forum MQTT auch ohne den Nuki-Server zu funktionieren, was ich jedoch nicht getestet habe, da ich inzwischen den Nuki Hub über einen ESP-32 und dem MQTT Broker/Client nutze.
Ein schöner Nebeneffekt: Ohne WiFi hält der Akku länger. Außerdem bleibt die Tür versperrt, egal was ich mache – weder beim Neustart des MQTT-Adapters, des ioBroker noch des Servers.
-
@balu-0 Hi, ich weiß nicht ob das nützlich ist, aber von meiner Seite aus kann ich Folgendes sagen:
Ich habe den Nuki 4 Pro wegen des WiFi und MQTT gekauft und ihn mit dem MQTT Broker/Client genutzt. Dabei habe ich festgestellt, dass das Nuki MQTT nicht ohne deren Server funktioniert, was für mich ein Unding ist. MQTT sollte im eigenen Heimnetz ohne externe Verbindung funktionieren, außer man möchte es anders (ich nicht). Inzwischen scheint laut deren Entwickler Forum MQTT auch ohne den Nuki-Server zu funktionieren, was ich jedoch nicht getestet habe, da ich inzwischen den Nuki Hub über einen ESP-32 und dem MQTT Broker/Client nutze.
Ein schöner Nebeneffekt: Ohne WiFi hält der Akku länger. Außerdem bleibt die Tür versperrt, egal was ich mache – weder beim Neustart des MQTT-Adapters, des ioBroker noch des Servers.
Ich hatte das gleiche Problem wie der TE, Nuki 3.0 über MQTT in IOBroker eingebunden, es konnte zu dem Zeitpunkt für mich nicht befriedigend gelöst werden.
Hierzu hatte ich auch schon einen Thread im Nuki-Forum aufgemacht: https://developer.nuki.io/t/nuki-3-0-pro-offnet-automatisch-die-tur-uber-mqtt/25521Aktuell steuere und überwache ich den Nuki (3.0 pro) ausschließlich mit Home Assistant über MQTT und hatte jetzt über 1/2 Jahr keinerlei böse Überraschungen.
-
@jolic said in Warnung für Nuki im betrieb mit MQTT !!:
@balu-0 Hi, ich weiß nicht ob das nützlich ist, aber von meiner Seite aus kann ich Folgendes sagen:
Ich habe den Nuki 4 Pro wegen
Inzwischen scheint laut deren Entwickler Forum MQTT auch ohne den Nuki-Server zu funktionieren, was ich jedoch nicht getestet habe, da ich inzwischen den Nuki Hub über einen ESP-32 und dem MQTT Broker/Client nutze.Ein schöner Nebeneffekt: Ohne WiFi hält der Akku länger. Außerdem bleibt die Tür versperrt, egal was ich mache – weder beim Neustart des MQTT-Adapters, des ioBroker noch des Servers.
Das mit dem Internet habe ich gleich wie folgt getestet:
-Stecker aus der Telefondose-
Schloss ist steuerbar.Für mich ist es sehr wichtig das es ohne netz läuft,
hoffe da kann man sich drauf verlassen.Die apps scheinen ja auch ohne netz zu laufen.
Hast du für die ESP Geschichte eine schöne Deutsche Seite mit Beschreibung ?
Mein Ziel ist es einen Panzerriegel auf der innenseite mit einem zweiten Nuki steuern zu lassen.
da Mietwohnung kann ich den nicht nach außen schließen lassen.Läuft das nicht einwandfrei müsste ich eine brokrohne an der richtigen stelle ansetzen :-)
-
Ich hatte das gleiche Problem wie der TE, Nuki 3.0 über MQTT in IOBroker eingebunden, es konnte zu dem Zeitpunkt für mich nicht befriedigend gelöst werden.
Hierzu hatte ich auch schon einen Thread im Nuki-Forum aufgemacht: https://developer.nuki.io/t/nuki-3-0-pro-offnet-automatisch-die-tur-uber-mqtt/25521Aktuell steuere und überwache ich den Nuki (3.0 pro) ausschließlich mit Home Assistant über MQTT und hatte jetzt über 1/2 Jahr keinerlei böse Überraschungen.
-
Ich hatte das gleiche Problem wie der TE, Nuki 3.0 über MQTT in IOBroker eingebunden, es konnte zu dem Zeitpunkt für mich nicht befriedigend gelöst werden.
Hierzu hatte ich auch schon einen Thread im Nuki-Forum aufgemacht: https://developer.nuki.io/t/nuki-3-0-pro-offnet-automatisch-die-tur-uber-mqtt/25521Aktuell steuere und überwache ich den Nuki (3.0 pro) ausschließlich mit Home Assistant über MQTT und hatte jetzt über 1/2 Jahr keinerlei böse Überraschungen.
-
@jolic said in Warnung für Nuki im betrieb mit MQTT !!:
@balu-0 Hi, ich weiß nicht ob das nützlich ist, aber von meiner Seite aus kann ich Folgendes sagen:
Ich habe den Nuki 4 Pro wegen
Inzwischen scheint laut deren Entwickler Forum MQTT auch ohne den Nuki-Server zu funktionieren, was ich jedoch nicht getestet habe, da ich inzwischen den Nuki Hub über einen ESP-32 und dem MQTT Broker/Client nutze.Ein schöner Nebeneffekt: Ohne WiFi hält der Akku länger. Außerdem bleibt die Tür versperrt, egal was ich mache – weder beim Neustart des MQTT-Adapters, des ioBroker noch des Servers.
Das mit dem Internet habe ich gleich wie folgt getestet:
-Stecker aus der Telefondose-
Schloss ist steuerbar.Für mich ist es sehr wichtig das es ohne netz läuft,
hoffe da kann man sich drauf verlassen.Die apps scheinen ja auch ohne netz zu laufen.
Hast du für die ESP Geschichte eine schöne Deutsche Seite mit Beschreibung ?
Mein Ziel ist es einen Panzerriegel auf der innenseite mit einem zweiten Nuki steuern zu lassen.
da Mietwohnung kann ich den nicht nach außen schließen lassen.Läuft das nicht einwandfrei müsste ich eine brokrohne an der richtigen stelle ansetzen :-)
@balu-0 said in Warnung für Nuki im betrieb mit MQTT !!:
Hast du für die ESP Geschichte eine schöne Deutsche Seite mit Beschreibung ?
Nein, aber wenn du dafür einen Thread auf machst (z.B.: Nuki mit ESP-32 und Nuki-Hub), kann ich gerne helfen.
-
@balu-0 said in Warnung für Nuki im betrieb mit MQTT !!:
Hast du für die ESP Geschichte eine schöne Deutsche Seite mit Beschreibung ?
Nein, aber wenn du dafür einen Thread auf machst (z.B.: Nuki mit ESP-32 und Nuki-Hub), kann ich gerne helfen.
-
Hallo zusammen.
Nimmt Mann mit wenig wissen über das ganze ( so wie ich ) ,
das Nuki mit den Standardeinstellungen des MQTT Brokers in Betrieb.
Ist es Möglich das sich eine ungünstige Vorkonfiguration ergibt.Startet der MQTT Adapter neu, bzw. der IO Broker, Bzw. der Container, bzw der Server,
schließt das schloss im dümmsten Fall auf !!!!Hier habe ich einen Beitrag gefunden der das gut beschreibt und gleich die lösung liefert:
""
In der MQTT-Instanz des IOBrokers gibt es unter den MQTT-Einstellungen einen Konfigurationspunkt „Eigene States beim Verbinden veröffentlichen“. Nimm da mal den Haken raus. Der ist standardmäßig aktiviert.
Bei mir ist die Tür sporadisch aufgegangen (auch komplett auf). Fan und ich bin nicht so lustig. Bis ich dann bemerkte, dass dieses Verhalten auftritt, sobald der Raspbery mit dem IOBroker gebootet wurde oder die Adapterinstanz neu gestartet wurde. Vermutlich auch, wenn der IOBroker neu gestartet wird.Die jeweils letzte Aktion am NUKI zB „zusperren“, merkt sich der Datenpunkt vom IOBroker! Wenn Du dann neu startest und damit die Verbindung erneut herstellst, sendet der MQTT-Adapter des IObrokers erneut den gemerkten Zustand und schließt wieder zu. Wenn dann die letzte Aktion vor dem Reboot „Tür öffnen“ war, steht irgendwann zB nach einem Stromausfall Deine Tür auf.
""Testen könnt ihr ob der Fehler besteht in dem ihr eben den adapter neu startet und wartet bis er sich wieder eigenständig mit dem Nuki verbindet.
Mir läufts noch eiskalt den Rücken runter :-)
Balu
@balu-0 Also ich habe den Haken entfernt, allerdings bringt das bei mir keine Änderung.
Wenn der Datenpunkt unlock=true ist, öffnet sich das Schloss, nach jeder neuen Verbindung, (start/stop) der Instance.
Es bleibt einem wohl nichts anderes übrig, als immer ein False nachzusenden! -
@balu-0 Also ich habe den Haken entfernt, allerdings bringt das bei mir keine Änderung.
Wenn der Datenpunkt unlock=true ist, öffnet sich das Schloss, nach jeder neuen Verbindung, (start/stop) der Instance.
Es bleibt einem wohl nichts anderes übrig, als immer ein False nachzusenden!Etwas OFF TOPIC gibt es eigentlich auch "dumme" Schlüsselantriebe? Also rein Elektromotor und Mechanik/Gehäuse? Zwei Klemmen für den Motor ...
Den hier habe ich schon entdeckt:
https://ei23.de/smarthome/smarter-tuerschlossantrieb-selbst-gebaut/ -
@balu-0 Also ich habe den Haken entfernt, allerdings bringt das bei mir keine Änderung.
Wenn der Datenpunkt unlock=true ist, öffnet sich das Schloss, nach jeder neuen Verbindung, (start/stop) der Instance.
Es bleibt einem wohl nichts anderes übrig, als immer ein False nachzusenden! -
Etwas OFF TOPIC gibt es eigentlich auch "dumme" Schlüsselantriebe? Also rein Elektromotor und Mechanik/Gehäuse? Zwei Klemmen für den Motor ...
Den hier habe ich schon entdeckt:
https://ei23.de/smarthome/smarter-tuerschlossantrieb-selbst-gebaut/@martinp
das hier wir nur über binäreingänge gesteuert.
https://www.automatikshop.de/geze-motorschloss-iq-lock-el-setan sowas zum dranschrauben hätte ich auch Interesse
-
Die Einstellungen sind nicht optimal - rechts oben muss ein hacken rein. Das Retain-flag kann ebenfalls für ein unerwartetes Verhalten sorgen.
https://schroederdennis.de/mqtt/mqtt-funktionen-qos-retain-letzter-wille/
-
Die Einstellungen sind nicht optimal - rechts oben muss ein hacken rein. Das Retain-flag kann ebenfalls für ein unerwartetes Verhalten sorgen.
https://schroederdennis.de/mqtt/mqtt-funktionen-qos-retain-letzter-wille/
-
Wenn du das retain flag setzt wird die gesendete Meldung immer an den Client gesendet wenn dieser sich verbindet. Um die zu überschreiben ist eine andere Mitteilung auf dem gleichen Topic mit retain flag nötig und um es zu löschen einen leere Meldung.
EDIT: Wenn der ausschließlich über iobroker gesteuert wird ist das kein problem, wenn du aber auch über einen anderen mqtt client oder eine weboberfläche das Gerät steuerst bleibt die alte Meldung als retain stehen und wenn der iobroker/Adapter/Gerät neustartet bekommt es diese Meldung.
-
Wenn du das retain flag setzt wird die gesendete Meldung immer an den Client gesendet wenn dieser sich verbindet. Um die zu überschreiben ist eine andere Mitteilung auf dem gleichen Topic mit retain flag nötig und um es zu löschen einen leere Meldung.
EDIT: Wenn der ausschließlich über iobroker gesteuert wird ist das kein problem, wenn du aber auch über einen anderen mqtt client oder eine weboberfläche das Gerät steuerst bleibt die alte Meldung als retain stehen und wenn der iobroker/Adapter/Gerät neustartet bekommt es diese Meldung.
866
Online32.5k
Benutzer81.8k
Themen1.3m
Beiträge