Wenn dies dein erster Besuch hier ist, lies bitte zuerst die Hilfe - Häufig gestellte Fragen durch. Du musst dich vermutlich registrieren, bevor du Beiträge verfassen kannst. Klicke oben auf 'Registrieren', um den Registrierungsprozess zu starten. Du kannst auch jetzt schon Beiträge lesen. Suche dir einfach das Forum aus, das dich am meisten interessiert.
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!
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.
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:
Code:
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!
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
Code:
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.
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
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.
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.
Hallo zusammen,
habe am Wochenende auf die aktuelle Version vom smarthomeNG migriert und mir ein Nuki 2.0 gekauft. Habe das nuki-plugin aktiviert und bekomme es leider nicht richtig eingebunden. Erhalte immer den Fehler:
Logfile:
ERROR nuki HTTPConnectionPool(host='xxx.xxx.xxx.xxx', port=xxxx): Max retries exceeded with url: /callback/remove?token=123456&id=0 (Caused by NewConnectionError('<urllib3.connection.HTTPConnec tion object at 0x7f841b38b198>: Failed to establish a new connection: [Errno 111] Verbindungsaufbau abgelehnt',))
Wenn ich die Requests einzeln von der smarthomeNG Instanz per curl in der shell aufrufe ist es kein Problem.
Kann jemand helfen oder hat eine Idee wonach ich noch gucken könnte?
Danke für die Antwort, Token und IP der Bridge sind korrekt im SHNG eingetragen.
Habe als Workaround nun die Callback-URL "von hand" in der Bridge angelegt. So werden die Items erst aktualisiert nachdem das Nuki einmal betätigt wurde....besser als gar keine Funktion.
Werde weiter ein Auge auf das Problem haben. Hab auch eine "einfrieren" meiner smartVISU nach ca. einem Tag mit SHNG 1.6 festgestellt. Vielleicht hängt das ja alles zusammen. Dazu muss ich mich aber erst im anderen passenden Thread schlau lesen.
Wir verarbeiten personenbezogene Daten über die Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen. Weitere Informationen findest Du in unserer Datenschutzerklärung.
Indem Du unten auf "ICH stimme zu" klickst, stimmst Du unserer Datenschutzerklärung und unseren persönlichen Datenverarbeitungs- und Cookie-Praktiken zu, wie darin beschrieben. Du erkennst außerdem an, dass dieses Forum möglicherweise außerhalb Deines Landes gehostet wird und bist damit einverstanden, dass Deine Daten in dem Land, in dem dieses Forum gehostet wird, gesammelt, gespeichert und verarbeitet werden.
Kommentar