Willkommen im Loxone Community Forum. Um alle Funktionen nutzen und sehen zu können, registriere dich bitte zuerst. Dies gilt auch für das herunterladen von Dateien.
Bitte im Titel immer zuerst den Namen des Plugins hinschreiben
Christian Fenzl
Hab es getestet und es sieht jetzt gut aus.
Sorry, habe deine Nachricht komplett übersehen. Nächstes Mal ping mich gern 2 mal an und mach etwas Druck. ;-)
Das Problem von fs79 betrifft nur den Nuki Healthcheck, und nur mit mindestens zwei Nuki-Devices, und dann noch würfeln, wie die Geräte in die Config fallen 😉
Korrigiert einen Fehler im Selbsttest/Healthcheck, dass es bei mehreren Nuki-Geräten vorkommen konnte, dass der Fehler "Nicht alle Geräte gefunden" gemeldet wurde (das "@fs79 Problem")
Stündliche Überprüfung durch Cron: Wenn die Bridge ein Nuki-Gerät als Offline meldet, wird bei den drei Wiederholungsversuchen nun jeweils 10 Sekunden gewartet (hab sowas bei singertom im Log gesehen)
Interessant für die Opener-Benutzer:
In der Nuki Bridge BETA wird im Callback jetzt der ringactionState übergeben. Da dieser Wert am MQTT-Server auf 1 bleibt, kann in der Incoming Overview mit aktivierter Advanced Table Information der ringactionState mit dem Flag "Reset-After-Send" gekennzeichnet werden, dann wird der Eingang als Impuls übertragen.
Christian Das mit dem ringactionState für den Opener klingt super! Damit könnte man womöglich die Klingel vollständig in Loxone integrieren. Oder hat der Callback nochimmer eine starke Verzögerung von bis zu 30 Sekunden? Hättest Du allenfalls ein Konfigurationsbeispiel, denn ich sehe gerade noch nicht wie ich dies umsetzen könnte?
Ich nutze das Plugin schon länger mit einem Nuki 2.0 inkl. Bridge. Nun habe ich ein zweites Nuki mit einer zweiten Bridge in meinem Netz installiert (die zweite Bridge war wegen dem schlechten Empfang notwendig).
Ich sehe beide Bridges Online mit Token im Plugin. Ich sehe auch beide Nuki's, aber ein Nuki wird immer als Offline angezeigt, auch der RSSI ist rot bei -90.
In der Nuki APP habe ich je nur ein Nuki mit einer Bridge verbunden - dies auch nochmals kontrolliert.
Hab ich das richtig verstanden: Das neue Smartlock ist im Plugin noch der alten Bridge zugeordnet?
Lösch das Nuki Device im Plugin, und lass neu suchen, was dann passiert.
Das Plugin macht folgendes:
Es geht zu jeder Bridge und ruft dort die mit der Bridge verbundenen Devices ab.
Die Devices werden im Plugin dann mit der Zuordnung zur Bridge gespeichert.
Wenn ein Device die Bridge wechselt, ist das vielleicht ein nicht abgedeckter Randfall, weil es ja nicht möglich ist, dass mehrere Bridges das gleiche Device verwalten.
Wenn nach Löschen und neu Suchen jedoch das Device wieder zur alten Bridge kommt, dann liegt das an der Bridge.
Hier mal die Bridges in der Übersicht:
dann die Geräte, einmal aktualisiert sieht es so aus:
bei der zweiten Aktualisierung sieht es dann aber so aus:
Ich hatte bereits das Plugin gelöscht und alles ganz neu eingerichtet. Ich kann es nicht ändern dass das Plugin immer wieder zwischen den Bridge IDs wechselt.
Contribute to mschlenstedt/LoxBerry-Plugin-Nuki development by creating an account on GitHub.
Der dort verwendete Befehl an die Bridge ist /list
Laut Nuki Doku: Returns a list of all paired Nuki devices
Demnach hast du entweder ein SmartLock auf der anderen Bridge gepairt (du kannst mit der App / Verwaltung / Bridge / 10 Sek. drücken ...) das Pairing eines falschen SmartLocks aufheben), oder die API von NUKI ist falsch.
Deswegen bitte um das Logfile.
Christian Fenzl Ich kann bei mir das gleiche beobachten.
Habe drei Nukis mit jeweils einer eigenen Bridge laufen.
Bridge#1 war mit jedem Nuki mal gepaired, Bridge#2 mit zwei Nukis und Bridge#3 nur mit einem.
Die Abfrage /info API zeigt auch genau das an, es ist aber nur jeweils ein Nuki als
Code:
"paired": true
gelistet. Das gleiche auch in der App, ich sehe bei jeder Bridge nur das paired Nuki - unpaired Nukis werden in der App nicht angezeigt.
Ich habe bereits eine Bridge zurückgesetzt aber die API zeigt mir weiterhin unpaired Nukis als
Code:
"paired": false
an - würd ich als Bug seitens Nuki sehen, ein Reset sollte das alles löschen. Vielleicht ist es aber auch so von ihnen gewollt.
Der API Endpoint /list zeigt korrekterweise nur die Infos zum paired Nuki an - hier werden wohl die Infos der beiden Endpoints vermischt bzw. überschrieben.
Unter https://github.com/mschlenstedt/LoxB...index.cgi#L970 in der Methode searchdevices wird z.B. /list abgefragt und mit /info überschrieben wenn ich das richtig deute, möglicherweise liegts daran? Die Methoden checktoken und checkonline greifen nur auf /info zu. Ansonsten habe ich auf die Schnelle keine Calls auf /info gefunden.
hagor Genau das ist es!! Und es ist ein Fehler des Plugins, nicht von Nuki.
Der /info Request liefert alle Devices in Reichweite zurück, ob gepaired oder nicht.
So kommt's, dass das gleiche Device von verschiedenen Bridges gefunden wird, und je nach "kosmischer Strahlung" (Perl-Reihenfolge beim Loop durch einen Hash) kommt erst die eine oder die andere Bridge dran, und das Device ist einmal "paired" und einmal nicht.
Probiert's bitte mal den Master mit einer Korrektur aus:
Jetzt werden Devices, die an einer Bridge nicht gepaired sind, geskippt.
Wehrmutstropfen ist, man sieht ein Device überhaupt nicht mehr, wenn es noch nirgends gepaired wurde.
Wir verarbeiten personenbezogene Daten über Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen, Werbung zu personalisieren und Websiteaktivitäten zu analysieren. Wir können bestimmte Informationen über unsere Nutzer mit unseren Werbe- und Analysepartnern teilen. Weitere Einzelheiten finden Sie in unserer Datenschutzrichtlinie.
Wenn Sie unten auf "Einverstanden" klicken, stimmen Sie unserer Datenschutzrichtlinie und unseren Datenverarbeitungs- und Cookie-Praktiken wie dort beschrieben zu. Sie erkennen außerdem an, dass dieses Forum möglicherweise außerhalb Ihres Landes gehostet wird und Sie der Erhebung, Speicherung und Verarbeitung Ihrer Daten in dem Land, in dem dieses Forum gehostet wird, zustimmen.
Tweet
Kommentar