Nuki Smartlock Plugin - Support Thread

[psilo]

stephan68 ich habe seit dem letzten Post hier auch nie wieder Probleme gehabt. Nur als Feedback

[stephan68]

psilo Heute morgen ist das Problem gegen 6:36 Uhr wieder aufgetaucht, die Bridge ist nach wie vor direkt an der FritzBox angemeldet. Im Logfile findet sich eigentlich nichts zu diesem Zeitpunkt, die letzte Meldung im Bezug auf das Nuki-Plugin ist von gestern:

2023-11-05 14:59:25 ERROR plugins.nuki HTTPConnectionPool(host='192.168.2.11', port=8080): Max retries exceeded with url: /list?token=SS372022839865 (Caused by NewConnectionError('<urllib3.connection.HTTPConnec tion object at 0x7f88202142b0>: Failed to establish a new connection: [Errno 110] Connection timed out'))

Ich habe jetzt mal den Loglevel für das Nuki-Plugin auf DEBUG gesetzt und lasse das separat loggen. Mal sehen, ob sich da was ergibt. Hast du sonst noch Ideen, was ich machen könnte?

[psilo]

stephan68 Ideen: eben nur zu schauen, auf welchem Access Point die Bridge derzeit registriert ist, falls es daran liegt. Bei mir nach wie vor alles ruhig.

[stephan68]

psilo Daran scheint's nicht zu liegen, die Bridge hängt nach wie vor direkt an der FritzBox

[psilo]

Ich habe derzeit auch wieder Probleme.. Kann es sein, dass das evtl mit schwachen Batterien im Nuki Lock zu tun haben könnte?

[stephan68]

psilo Ich habe bei einem meiner Schlösser gerade die Batterien getauscht, beim anderen sind noch die ersten drin. Hatte aber vorher und nachher schon wieder Probleme...

[stephan68]

psilo: aktuell tritt das Problem wieder vermehrt auf, da ich sowieso ein Nagios laufen habe, lasse ich die Threads-Anzahl jetzt überwachen und starte SHNG ggf. automatisiert neu.

Aber was mir dabei auch noch aufgefallen ist: Laut Dokumentation und WebIF gibt es für schließen und öffnen jeweils einen eigenen Status, den ich gerne nutzen würde um den -doch etwas längeren- Ver-/Entriegelungs-Vorgang zu visualisieren. Aber das Status-Objekt sendet diese Werte nie. Weder wenn das Schloß per App bedient wird, noch per SmartVisu. Ist das nicht implementiert, oder stimmt hier was nicht?

[psilo]

stephan68 ich schaus mir mal an, habe jetzt endlich frei... Mich nervt das Thema auch. Warum auch immer habe ich derzeit auch wieder Probleme.. Kann nicht ausschließen, dass die Bridge inzwischen neue Updates hat. Das Plugin ist alt... Erklärt für mich aber die Probleme trotzdem nicht wirklich.

[psilo]

Aber das Status-Objekt sendet diese Werte nie.

-> kannst Du das nochmal genauer darlegen? Um welches Item geht es und mit welchem Item im WebIf sieht man diesen fehlenden Status?

[psilo]

Ich glaube ich habe das Thema gefunden, der von mir aufgerufene Webservice "/lockState" ist während des Schließens/Öffnens nicht verfügbar, da dieser wohl direkt auf das Schloß zugreift. Der "list" Webservice scheint aber zu gehen, da dieser wohl direkt auf die Bridge geht. Ich überlege mal ob man das umbauen kann bzw dann infos fehlen.Evtl hängt das auch mit dem Problem mit den Threads zusammen.

image.png

Den Scheduler hab ich jetzt mal auf den "/list" Webservice umgestellt. Wo ich nicht sicher bin ist, ob ich den schließenden / öffnenden Status auch via CallBack Funktion bekomme: Der Scheduler läuft ja nur alle 300 Sekunden und im WebIf wird direkt aktualisiert. Wenn das Schloß sperrt/öffnet nutze ich aber den CallBack, um DIREKT Rückmeldung zu bekommen. Hier scheint der Zwischenstatus nicht zu kommen. Vielleicht kann ich im Callback-Fall den Status dann via "/list" beziehen. Ich vermute aber, dass der Callback nur im OPEN oder CLOSED State ausgelöst wird.

[psilo]

Der callback gibt mir in der Tat nur locked und unlocked zurück. Ich muss mal schauen, ob ich nach den schalten einfach /list aufrufen kann. Mglw hat meine änderung das Threads problem bereits behoben. Ich pushen in den Develop sobald ich durch meine derzeitige Coronainfektion durch bin. Komm aus dem Bett kaum hoch.

[psilo]

@stephan68 Die neue Version ist jetzt im Develop. Bitte mal testen. Der 503er Webservice sollte während des Schließens jetzt nicht mehr gecalled werden. Zudem update ich nach einem Statechange den Status nochmals zusätzlich über den immer verfügbaren "/list" Webservice.

Seit der ersten Änderung hatte ich keine Threadprobleme mehr, kann aber auch Zufall sein.

Update: Gerade noch einen kleinen Fix für die Stati 4: schließend und 7: aufklinkend gepusht, bei mir klappt es.

[stephan68]

psilo Habe das Plugin grade aktualisiert, das Update des lock state funktioniert nun perfekt, vielen Dank für den super Support

Das Thread-Problem behalte ich mal mit im Auge und melde mich dazu nochmal...

[psilo]

stephan68 ich habe das threadproblem inzwischen wieder.. ich gehe nochmal den ganzen code durch.. aber an der 503 zurückgebenden schnittstelle hats eigentlich auch nicht liegen können. irgendwas muss den thread blockieren, mir nur ein rätsel was und warum nur manchmal.

[psilo]

stephan68 Ich habe glaube ich noch was entdeckt. Die self._register_callback() wurde alle 5 Minuten neu aufgerufen. Eigentlich reicht es ja, denn Callback nur einmal zu registrieren. Habe das jetzt mal aus der gescheduleten Funktion rausgenommen und teste lokal. Kann mir schon vorstellen, dass die Bridge nicht mag, wenn mal 1000mal den gleichen Callback registriert.

Klappt wohl weiterhin alles. Ist jetzt im DEVELOP. Lass uns das jetzt mal beobachten. Wenn es immer noch zu viele Threads gibt, muss ich an
self._get_paired_nukis()
self._get_nuki_status_via_list()
nochmal ran.

Die These wäre aber, dass ggf. die erste Funktion noch Probleme macht. Die Frage ist, ob man die braucht.Die geht wohl auch nur auf den "list" Webservice und setzt die paired_nukis bei jedem loop neu (kapiere nicht so 100%, warum man das braucht?). pfischi weißt Du noch warum Du das so gebaut hattest? Für den Fall, dass man zur Laufzeit ein Nuki dazunimmt oder entfernt?

Zumindest könnte man das wohl in den gleichen Aufruf packen und dadurch 1 Call / Iteration entfernen. Aber jetzt erstmal beobachten.

Update: erste nacht bisher ohne thread-probleme
Update 2.1.24: seit der Änderung weiterhin KEINE Threading Probleme!