Test Adapter Somfy Tahoma v0.3.x GitHub
-
@blackeagle998 Danke, habe ich gerade im git behoben. Tritt auf, wenn nach der Anfrage an Tahomalink kein Antwortobjekt kommt (Anfrage-Timeout bspw).
-
@StrathCole
Adapter Version: 0.2.6Funzt astrein, trotzdem noch eine kleine Sache, folgendes Szenario:
- Alle Rollläden hoch (oder runter)
- kurz danach alle Rollläden stop
--> bis hier hin funktioniert das
Nach etwa 15 - 30 Sekunden gehen die Rollläden dann trotzdem weiter hoch (oder runter).
Hier wird irgendwo der Befehl vor STOP trotzdem weiter ausgeführt, das macht aber keinen Sinn, wenn ich STOP drücke
Das "Problem" besteht auch weiterhin mit der Adapterversion 0.3.0.
Der Datenpunkt moving hat den Wert "up", dann kommt "stopped" und dann geht er nach ca. 2 Sekunden automatisch wieder auf "up". -
@blackeagle998 sagte in Test Adapter Somfy Tahoma v0.3.x GitHub:
@StrathCole
Adapter Version: 0.2.6Funzt astrein, trotzdem noch eine kleine Sache, folgendes Szenario:
- Alle Rollläden hoch (oder runter)
- kurz danach alle Rollläden stop
--> bis hier hin funktioniert das
Nach etwa 15 - 30 Sekunden gehen die Rollläden dann trotzdem weiter hoch (oder runter).
Hier wird irgendwo der Befehl vor STOP trotzdem weiter ausgeführt, das macht aber keinen Sinn, wenn ich STOP drückeDas "Problem" besteht auch weiterhin mit der Adapterversion 0.3.0.
Der Datenpunkt moving hat den Wert "up", dann kommt "stopped" und dann geht er nach ca. 2 Sekunden automatisch wieder auf "up".Bewegen sie sich denn dann auch wieder oder ist es nur ein falscher Statuswert?
-
@StrathCole
Sie bewegen sich in den Endzustand (ganz hoch oder ganz runter). -
@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.
