Nuki Smartlock Plugin - Support Thread

[pfischi]

Hallo zusammen,

das ist der Support-Thread für das Nuki-Lock Plugin. Alle Fragen, Anregungen und gesichtete Fehler bitte hier rein.

HOW-TO Nuki Plugin

Gruss,

Stefan

[psilo]

schon mal danke für das plugin! wisst ihr, ob es mit mehreren nukis bereits klarkommt? wg der callback url? überlege noch ein 2tes anzuschaffen!

[pfischi]

Habe leider nur eins. Kaufe ein zweites und versuchs Ich nehme gerne deine Logs und programmiere was wenn es nicht gehen sollte.

Gruss,

Stefan

[psilo]

Sooo also das Plugin tut mit 2 Nukis jetzt recht gut. Ich habe im DEV einen kleinen Fix gepusht, der die Exceptions wegen der 503er von der Nuki Bridge etwas mildern müsste.. Problem ist, dass die Abfrage nach Callback URLs dann gegen die Bridge geht, wenn ein Nuki gerade schaltet.. Dann lehnt die Bridge das laut Doku mit einem 503er ab.. Nicht schön, aber ist so..

2 Nukis gleichzeitig zu schalten dürfte so nicht möglich sein.. Ich durchdenke mir noch, ob man ein Sperritem setzen und (solange das gesetzt ist) weitere Schaltoperationen queuen könnte.

Zudem habe ich dem Plugin ein Web Interface spendiert, mit dem man testweise auch das Nuki schalten kann!

nuki.png

[psilo]

PS: Bitte alle mal testen.. Sollte zwar alles passen, ich alleine als Tester fühle mich aber als zu wenig an

[pfischi]

Coole Sache. Hab leider nur ein Nuki, deshalb kann ich dir dahingehend nur bedingt Feedback geben.

Gruss,

Stefan

[pfischi]

Zu dem Callback-Problem: könnte man nicht eine FIFO-Funktionalität implementieren? Event-Queue? Manchmal hatte ich auch das Gefühl, das einzelne Kommandos von der API geschluckt werden, eventuell würde man das so robuster bekommen. Ich würde mir das so vorstellen, das ein API-Call dann solange versucht wird, bis die Bridge mit dem Code 200 antwortet. Danach würde dann der nächste API-Call verarbeitet werden usw.

Gruss,

Stefan

[psilo]

pfischi das problem tritt auch bei nur einem nuki auf.. das plugin pollt ja zyklisch nach callback urls oder sowas. wenn dieser call genau dann passiert, wenn das schloss schaltet, knallt es (503er).

Also hier:

    def _scheduler_job(self):
        # will also be executed at start
        self._get_paired_nukis()
        self._register_callback()
        self._get_nuki_status()

ist funktional weniger tragisch als ein 2tes schloss zu schalten, ist aber eben noch nicht 100% reif im plugin..

ich hatte gedacht, dass ich irgendwie noWait verwenden kann um rauszukriegen, ob die bridge wieder befehle ausführt. ich glaube aber trotz mit "wait" abgeschlossenem request sind die 503er oft noch etwas länger zu beobachten

Bitte den Stand im DEV auch mit nur einem Nuki testen.. ich habe unter der Haube doch einiges geändert, auch am Logging.. und das Webif sollte mit einem Nuki natürlich auch gehen!

[psilo]

habs gerade nachgestellt. zwar dauert der GET request mit noWait so lange, bis das schloss bspw zu ist, schalte ich direkt danach, kriege ich trotzdem nen 503er

2018-11-03  10:07:16 DEBUG    plugins.nuki     _api_call        Plugin 'nuki': noWait is 0                                                                                                                          
2018-11-03  10:07:16 DEBUG    plugins.nuki     _api_call        Plugin 'nuki': starting API Call to Nuki Bridge at http://192.168.178.102:8080/lockAction with payload {'action': 2, 'nukiID': xxxxxxxxx, 'token': 'xxxxxx', 'noWait': 0}.                                                                                                                                                                                              
2018-11-03  10:07:16 DEBUG    plugins.nuki     _api_call        Plugin 'nuki': finishing API Call to Nuki Bridge at http://192.168.178.102:8080/lockAction.                                                        
2018-11-03  10:07:16 ERROR    plugins.nuki     _api_call        503 Server Error: Service Unavailable for url: http://192.168.178.102:8080/lockAction?action=2&nukiID=xxxxxxxxx&token=xxxxxx&noWait=0              
2018-11-03  10:07:16 ERROR    plugins.nuki     update_item      Plugin 'nuki': no response.

Der Nuki Support hatte dazu übrigens das hier geantwortet:

Der 503er bedeutet, dass die Bridge die Anfrage gerade nicht abarbeiten kann, weil noch eine andere Anfrage aktiv ist.
Ich werde das in der Doku korrigieren.

Es sollte immer abgewartet werden, bis eine Antwort auf die Anfrage gekommen ist und dann erst die nächste gesendet werden.

[psilo]

sehr seltsam. ich habe no_wait jetzt via plugin.yaml explizit auf True gesetzt und aktuell geht gleichzeitiges schalten ohne 503er.. Mit noWait = False wie oben kommen sie..

lass ich no_wait weg, müsste aber der default aus der pluginspezifischen plugin.yaml greifen, der auch True ist.. ich analysiere das mal weiter

[psilo]

im DEV habe ich jetzt erstmal ne boolsche lock variable eingebaut, die dafür sorgen müsste, dass api requests erst raus dürfen, nachdem ein laufender beendet wurde.

[psilo]

kurze info: mit nuki 2.0 geht alles nach wie vor.. die neue info zum zustand der tuere (offen/geschlossen) versuche ich mittelfristig noch zu ergänzen.. derzeit gibt es noch eine upgrade aktion, für die die auch auf nuki 2.0 umstellen möchten.