Test Adapter Somfy Tahoma v0.3.x GitHub
-
@blackeagle998 Kannst du einmal die aus dem Git installieren, ob der Fehler da behoben ist?
-
@StrathCole
Adapter Version 0.3.1
Bleibt leider unverändert
-
@blackeagle998 Kommt denn irgendwas an Fehler oder Warnung im Log?
-
@StrathCole
Ich habe den Adapter auf DEBUG gestellt und das ioBroker LOG File auf einen Rollladen reduziert.
Ist trotzdem noch ganz schön umfangreich, kann ich dir das irgendwie so zukommen lassen (PN mit Anhang oder per Mail)? -
Falls aktuell niemand mehr ein akutes Problem mit dem Adapter hat, würde ich morgen die 0.3.1 veröffentlichen.
-
Hi
Nach der Erstinstallation war alles prima.
Nun, nachdem ich eine Reihe Adapter ugedatet habe (Admin, js, etc.) stoppt der
die Instanz mit folgender Meldungtahoma.0 2020-01-27 19:41:37.421 error (21093) uncaught exception: controller.login is not a function
Eine Idee ?
-
@S-Trohmer Könntest du mal die aktuellste GitHub Version installieren?
-
Ist die 0.3.1 von heute
bin ganz neu dabei
-
Nach Neuinstallation der 0.3.0 ist wieder alles gut
-
@S-Trohmer sagte in Test Adapter Somfy Tahoma v0.3.x GitHub:
Nach Neuinstallation der 0.3.0 ist wieder alles gut
Es wäre trotzdem hilfreich, ein paar weitere Infos dazu zu haben, also die kompletten Logzeilen des Fehlers und ob es die aktuelle Version aus github war.
-
Sorry, das Log habe ich gelöscht, nachdem alles wieder lief.
Mache ich das nächste Mal besser. -
@StrathCole
Hallo,das dritte Wochenende in Folge habe ich jetzt das Phänomen, dass sich der Adapter "aufhängt" und nicht mehr reagiert, bleibt aber im Status grün.
Laut Schedule hätten meine Rollläden um 17:35 Uhr schließen müssen, passiert ist nichts, obwohl die ClosureStates sauber mit 100% geschrieben wurden (= geschlossen). Trotzdem blieben die Rollladen im Status open, siehe hier:
Als ich das bemerkt habe, versuchte ich ein manuelles Schließen um 18:25Uhr per iQontrol (Visualisierung) und erhielt im LOG folgende Meldungen:
2020-02-02 18:25:20.971 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: events/0229f3fd-d9b6-8679-0606-16daac3bd30d/fetch with payload:{} 2020-02-02 18:25:30.996 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: events/0229f3fd-d9b6-8679-0606-16daac3bd30d/fetch with payload:{} 2020-02-02 18:26:01.039 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: events/0229f3fd-d9b6-8679-0606-16daac3bd30d/fetch with payload:{} 2020-02-02 18:26:11.060 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: /setup/devices/states/refresh with payload:{} 2020-02-02 18:26:11.061 - warn: tahoma.0 (5662) refresh device state failed 2020-02-02 18:26:41.113 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: /setup/devices/states/refresh with payload:{} 2020-02-02 18:26:41.114 - warn: tahoma.0 (5662) refresh device state failed 2020-02-02 18:26:51.132 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: events/0229f3fd-d9b6-8679-0606-16daac3bd30d/fetch with payload:{} 2020-02-02 18:27:11.201 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: events/0229f3fd-d9b6-8679-0606-16daac3bd30d/fetch with payload:{} 2020-02-02 18:28:01.246 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: events/0229f3fd-d9b6-8679-0606-16daac3bd30d/fetch with payload:{} 2020-02-02 18:28:11.256 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: events/0229f3fd-d9b6-8679-0606-16daac3bd30d/fetch with payload:{} 2020-02-02 18:28:21.260 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: /setup/devices/states/refresh with payload:{} 2020-02-02 18:28:21.261 - warn: tahoma.0 (5662) refresh device state failed 2020-02-02 18:28:51.305 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: events/0229f3fd-d9b6-8679-0606-16daac3bd30d/fetch with payload:{} 2020-02-02 18:29:01.335 - warn: tahoma.0 (5662) error during tahomalink request: null, request path: events/0229f3fd-d9b6-8679-0606-16daac3bd30d/fetch with payload:{}Zur Zeit des eigentlichen Schedules um 17:35Uhr gab es im LOG keinerlei Einträge.
Ein einfacher Adapter Restart löst das Problem und die Rollläden lassen sich wieder wie gewohnt steuern, allerdings zieht dann das Schedule nicht mehr nach, da die ClosureStates wieder mit 0% und open überschrieben werden.Vielleicht ist es nur Zufall, dass ich es immer am Wochenende merke und bisher als "kann ja mal vorkommen" abgestempelt habe, vielleicht ist es mir in der Woche auch noch nicht aufgefallen und das Problem behebt sich nach einiger Zeit von selbst?!
Momentan bin ich etwas ratlos, kann hier jemand ähnliches nachvollziehen?
-
@blackeagle998 Ja, leider habe ich das Problem selbst auch seit den Serverupdates, die Somfy am 21.1. vorgenommen hat. Ich bin gerade dabei, das näher zu untersuchen, allerdings klappt es bei manuellen Tests und morgens beim Öffnen problemlos bisher. Nur das Schließen am Abend geht nicht immer, den Grund habe ich noch nicht gefunden. Ich habe nun die Logausgabe dahingehend im Git noch erweitert.
-
Danke für die schnelle Rückmeldung.
Da bin ich etwas beruhigt, dass es kein lokales Thema bei mir ist.Ich werde mal einen Sicherheits-Timeout einbauen und den ClosureState gegen den OpenCloseState prüfen, nachdem ein Schedule ausgeführt wurde.
Dann kann ich ggf. den Adapter automatisch neustarten und das Schedule nachziehen. -
@blackeagle998 Ich verstehe noch nicht, wieso es bei mir ausschließlich beim Schließen auftritt und auch nur, wenn ich mehrere gleichzeitig schließe via setClosure. Wenn ich bei einzelnen im ioBroker auf "close" klicke, geht es. Total seltsam. Ich vermute, Somfy hat beim Serverupdate irgendwas geändert, aber das finde ich noch raus
-
@blackeagle998 Ich habe es bei mir jetzt gelöst. Das Problem war, dass ich einen Motor auf Werkseinstellungen zurücksetzen musste. Dadurch hatte ich im ioBroker die falsche DeviceURL, nachdem Tahoma sie neu gelernt hat.
Als ich dann alle Devices schließen gesetzt habe, antwortet Tahoma mit dem Fehler, den du auch hattest und dem Zusatz "Device not found" oder so ähnlich. Wenn du die aktuelle Version aus dem git installierst, bekommst du auch mehr Informationen im Log, warum ein Fehler aufgetreten ist. -
@StrathCole
Wie genau hast du es denn gelöst?
Bei mir wurden bereits mehrere Motoren getauscht und somit auch neu angelernt.
Ich installiere mal die Version und schaue was dann raus kommt -
@blackeagle998 Ich habe im Log geschaut, welche DeviceURL er als "Not Found" angibt und diese dann im Objektbaum von ioBroker gesucht. Dort hab ich dann das entsprechende Device komplett gelöscht. Du könntest aber auch den Adapter stoppen, den kompletten Objektbaum "tahoma.X" löschen und dann den Adapter neu starten. Dann sollte er ja alle Geräte neu einlesen.
-
@StrathCole
Heute ist das Problem leider wieder aufgetreten, die Rollläden wurden nicht geschlossen und auch auf manuelle Eingaben reagierte der Adapter nicht mehr.
Im LOG ist zur betreffenden Zeit 17:40Uhr nichts zu finden, erst ab 18:30Uhr erscheinen Meldungen bezüglich "Server down for Maintenance".Die Devices sehen jedenfalls alle gut aus und funktionieren ja sonst auch, da ist also kein Fehler erkennbar.
Ich bin echt ratlos, vielleicht stelle ich den Adapter mal dauerhaft auf DEBUG und hoffe dann auf mehr Informationen. -
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.3.x GitHub:
@StrathCole
Heute ist das Problem leider wieder aufgetreten, die Rollläden wurden nicht geschlossen und auch auf manuelle Eingaben reagierte der Adapter nicht mehr.
Im LOG ist zur betreffenden Zeit 17:40Uhr nichts zu finden, erst ab 18:30Uhr erscheinen Meldungen bezüglich "Server down for Maintenance".Das ist aber seltsam, denn irgendwas müsste eigentlich im Log stehen, wenn nichts passiert. Sonst würde das bedeuten, dass er gar keine Befehle an den Tahoma-Server sendet. Wahrscheinlich kann da wirklich nur das Debug-Log weiterhelfen.
