Nuki Smartlock Plugin - Support Thread

[psilo]

Leider treten die Probleme bei mir die letzten Wochen wieder massiv auf. Ich komme dem ganzen jetzt via Debug Logs langsam auf die Schliche. Wenn die Bridge einen Callback auf den Webservice des Nuki Plugins macht, scheint das Lock-Flag (dass dafür sorgt, dass die bridge nur einen request nach dem anderen bekommt) "hängen" zu bleiben und er looped permanent in einem time.sleep... Mit jedem neuen zyklischen Request hängen dann mehr threads.

ich versuche das mal weiterzuverfolgen und die ursache zu finden. Ich denke der Callback muss auch in das Lock-Flag aufgenommen werden.

Ich habe jetzt mal die 2 statischen Methoden in "normale" Methoden umgebaut und mehr Debug-Logging integriert. Aktuell läuft es. Nachdem das manchmal erst nach Tagen kam, werde ich vor einem Push aber erstmal weiter testen.

[psilo]

Neuster Codestand ist gepusht. Seit 2 Tagen stabil.

[psilo]

Am dritten Tag bin ich wieder in das Problem gelaufen. Es ist def. das Lock - warum auch immer landet er in einem State, wo er unbegrenzt auf den Lock-Release wartet. Fehler gibt es keinen, ich vermute ein Request landet nicht im "Finally" Block...

Testweise habe ich jetzt mal das selber implementierte Request-Locking auf "from threading import Lock" umgebaut und den while loop entfernt. Jetzt wieder abwarten.

[hijacker7]

Hi,
nur eine kleine Anmerkung:
Im README bei der Beschreibung von battery unter nuki_trigger sollte

nuki_trigger: battery

stehen.
https://github.com/smarthomeNG/plugi...p/nuki#battery

LG

[psilo]

hijacker7 danke, ist gefixt.

[psilo]

Zwecks des Locking Problems: vielleicht hat einer eine Idee, warum manchmal offenbar der Finally Block hier nicht ausgeführt wird:
https://github.com/smarthomeNG/plugi...init__.py#L336

Das Lock bleibt offenbar hängen, egal mit welcher Technologie ich es implementierte und dann werden zyklisch weitere Threads gespawned.. Bin langsam etwas ratlos -allerdings auch nicht mehr sicher, warum überhaupt mal ein request locking implementiert wurde... problem dürfte nur sein, wenn ein aufruf via shng parallel zu einem callback von der bridge erfolgt.. sehe aber wohl auch das problem nicht wirklich.

[psilo]

Sieht so aus, als antwortet die Bridge manchmal einfach nicht, wirft aber auch keinen Fehler.. Habe jetzt mal wie weiter oben vorgeschlagen auch einen Timeout reingebaut und siehe:
2024-02-23 13:47:51 ERROR plugins.nuki _api_call HTTPConnectionPool(host='192.168.178.48', port=8080): Read timed out. (read timeout=60)
2024-02-23 13:47:51 DEBUG plugins.nuki _api_call Plugin 'nuki': Lock removed.
2024-02-23 13:47:51 INFO plugins.nuki _get_nuki_status_via_list Plugin 'nuki': Getting Nuki status ... Response is None.

irgendwie tritt das aber nur ganz selten auf und imho müssten die services die jetzt implementiert sind, auch beim fahren des schlosses gehen.. um 13:47 hat zudem ganz sicher keiner bei uns das schloss gefahren... vielleicht hat die bridge einfach sporadisch "aussetzer".

Ich schaue mal ob ich mehr rauskriege. Mit Timeout sollte es gehen, das lock wird dann auch released und man sieht halt manchmal Fehler im Log, für die das Plugin erstmal nichts kann ;-)

[psilo]

So, die Version mit timeout habe ich jetzt in den develop gepusht.. in meinen beobachtungen sehe ich zudem manchmal auch noch längere blocks der api funktion. Meiner Meinung nach packt die Nuki Bridge manchmal schlicht die Requests nicht. bei mir funktioniert es aber relativ fein inzwischen. Nur heute morgen war sie länger via wifi komplett "unresponsive"... Mit der aktuellen Implementierung sollte SHNG aber nicht mehr crashen.. ob die sporadischen timeouts wirklich etwas ausmachen, wage ich zu bezweifeln.

[SwenS]

Hallo zusammen,

ich habe am KNX je Tür zwei Eingänge Anliegen. (Tür Zu und Tür verschlossen) Ist es möglich diese über das Plugin an den Nuki Smart Look Pro (5. gen) zu senden?

Vielen Dank

Swen

[psilo]

SwenS mit den alten ging das auf jeden Fall nicht. Da eines meiner 2er Nukis jetzt kaputt ist (Kleber war am Ende..) habe ich für eine der Türen ein 5er bestellt. Muss dann sicher die Integration eh nochmal checken. Wenn ich was sehe schreibe ich hier.
Ich verstehe richtig, dass Du den AUF/ZU Status in den AUF/ZU Wert des Nukis übertragen willst, damit das Nuki bescheid weiß?

[SwenS]

psilo genau. also das gleiche wie die Door Sensoren von Nuik... die wollt ich wenn es geht weg lassen.

Vielen Dank

[psilo]

SwenS also das wird wohl dauern. meinem verständnis nach hat das neue nuki keinerlei lokale api mehr, nur noch via cloud - was dumm ist, wenn das internet weg ist. mqtt geht nur mit user, mein broker ist aber ohne. auf dem broker läuft meine komplett PV und ladestationssteuerung, so dass ich da auch nicht rumspielen will. mal sehen wie ich weiter verfahre.. etwas nervig ist das schon. damit ist für die neueren modelle ja das plugin sinnlos.. ich checke jetzt mal, ob ich noch mit der bridge verbinden kann.

update: offenbar geht lokaler zugriff jetzt über die matter api... muss ich mir noch tiefer anschauen. das plugin braucht aber sicher eine erweiterung

update2: habs jetzt via mqtt eingebunden, der neue user stört den rest wohl nicht. jetzt plugin erweitern...

update3: doch er stört den rest... 3 tasmotas kriegen keine verbindung mehr.. braucht wohl mehr zeit

update4: es wird immer interessanter. ich habe das nuki erst mit user und passwort konfiguriert, jetzt das passwort file aus dem broker wieder entfernt und die nuki verbindung bleibt weiter online... ich schlafe ne nacht drüber..

[psilo]

Nur als weitere Info: bin beim Erweitern des Plugins auf MQTT.

Update: die States funktionieren jetzt schon, als nächstes kommt der interessante Teil, wie ich via MQTT das Schloss steuern und Werte überschreiben kann.

[psilo]

SwenS sieht nicht so aus, als ob Deine Anforderung geht: https://developer.nuki.io/uploads/sh...IjYSU3g0O4.pdf

Ich sehe nur Befehle zum Steuern des Schlosses selber.