schon folgendes probiert, falls du womöglich die config kürzlich geändert haben solltest o.ä.?
hat bei mir schon so manche probleme, die vermeintlich unerklärlich waren, gelöst
schon folgendes probiert, falls du womöglich die config kürzlich geändert haben solltest o.ä.?
hat bei mir schon so manche probleme, die vermeintlich unerklärlich waren, gelöst
schon folgendes probiert, falls du womöglich die config kürzlich geändert haben solltest o.ä.?
hat bei mir schon so manche probleme, die vermeintlich unerklärlich waren, gelöst
Hello,
ich würde diesen thread gerne noch einmal wiederbeleben:
Wäre es mit den o.g. Scripts (die hervorragend funktiponieren) möglich das ganze auch unter der lovelace vis anzeigen zu lassen? Mithilfe der direkten Einbindung in einer 'Picture' bzw 'Picture Element' Karte hatte ich bisher keinen Erfolg.
Any possible Ideas?
@glasfaser
der poll interval is mitlerweile auf 180000 hoch gesetzt auf empfehlung von somfy, hat aber offentsichtlich auch nichts gebracht..
und dass der login fehlgeschlagen ist, ist mir klar - das ist ja das eigentliche problem, wie in post #1 beschrieben...
Update, nachdem es sich heute erneut gesperrt hat:
2021-02-11 15:32:05.850 - warn: tahoma.0 (1659) error during tahomalink request: null, request path: setup/gateways/xxxx-xxxx-xxxx with payload:{}
2021-02-11 15:32:05.863 - warn: tahoma.0 (1659) Response: {"statusCode":502,"body":"\n\n \n \n \n \n\n\n
\n
\n\n \n \n \n \n
\n
\n Server is down for maintenance
\n
\n We are sorry for the inconvenience.
\n Please try again in a few minutes.\n
\n
\n
\n\n\n\n\n","headers":{"date":"Thu, 11 Feb 2021 14:31:31 GMT","server":"Apache","strict-transport-security":"max-age=31536000; includeSubDomains","last-modified":"Mon, 16 Dec 2013 16:38:21 GMT","etag":"\"2c3-4eda970965940\"","accept-ranges":"bytes","content-length":"707","connection":"close","content-type":"text/html"},"request":{"uri":{"protocol":"https:","slashes":true,"auth":null,"host":"www.tahomalink.com","port":443,"hostname":"www.tahomalink.com","hash":null,"search":null,"query":null,"pathname":"/enduser-mobile-web/enduserAPI/setup/gateways/xxxx-xxxx-xxxx","path":"/enduser-mobile-web/enduserAPI/setup/gateways/xxxx-xxxx-xxxx","href":"https://www.tahomalink.com/enduser-mobile-web/enduserAPI/setup/gateways/xxxx-xxxx-xxxx"},"method":"GET","headers":{"User-Agent":"Mozilla/5.0 (X11; Linux x86_64; rv:73.0) Gecko/20100101 Firefox/73.0","cookie":"JSESSIONID=2D50AD046F49D2AD13DEC17B9ED0F9A2","accept":"application/json","content-type":"application/json","content-length":2}}}
2021-02-11 15:32:05.863 - warn: tahoma.0 (1659) Body: "\n\n \n \n \n \n\n\n
\n
\n\n \n \n \n \n
\n
\n Server is down for maintenance
\n
\n We are sorry for the inconvenience.
\n Please try again in a few minutes.\n
\n
\n
\n\n\n\n\n"
2021-02-11 15:33:42.970 - warn: tahoma.0 (1659) error during tahomalink request: undefined ->401 retry setup/gateways/xxxx-xxxx-xxxx
2021-02-11 15:33:43.657 - warn: tahoma.0 (1659) error during tahomalink request: undefined ->401 retry login
2021-02-11 15:33:44.278 - warn: tahoma.0 (1659) error during tahomalink request: undefined ->401 retry login
2021-02-11 15:33:44.919 - warn: tahoma.0 (1659) error during tahomalink request: undefined ->401 retry login
2021-02-11 15:33:45.588 - warn: tahoma.0 (1659) error during tahomalink request: undefined ->401 retry login
2021-02-11 15:33:45.589 - info: tahoma.0 (1659) Login failed three times, waiting 2 minutes before retrying.
2021-02-11 15:34:26.311 - warn: tahoma.0 (1659) error during tahomalink request: Error: connect ETIMEDOUT 178.32.15.131:443, request path: events/875e3d88-ac10-3e01-0169-e762f8196c6a/fetch with payload:{}
2021-02-11 15:35:45.799 - warn: tahoma.0 (1659) error during tahomalink request: undefined ->401 retry login
kann damit jemand etwas anfangen? nach anfragen bei somfy war deren server nicht down für irgendeine maintenance, warum also diese meldung?
Nachtrag nach weiteren Telefonaten mit somfy:
Es gibt eine vielzahl von logins seitens somfy, davon funktionieren bei mir (trotz vermeintlich gesperrten logins):
folgende funktionieren nicht:
Auch wurde die Aussage bestätigt, dass es in der Vergangenheit zu Login Sperrungen seitens somfy kam, da eine zu hohe anzahl von Zugriffsversuchen auf die Tahoma Cloud statt gefunden haben.
@StrathCole bzw. @apollon77 - kann mir jemand von euch eine Aussage darüber machen, wann bzw wieviele Zugriffe der adapter macht wenn er sich ganz normal mit somfy verbinden kann und verbunden ist?
Servus allerseits,
der Fehler im Titel dürfte wohl geläufig sein, da bereits mehrere dieses Problem haben/hatten. Kurz zum Verständnis, so sollte ein "normaler", sprich erfolgreicher Login des tahoma adapters aussehen:
2021-01-20 10:58:40.889 - info: host.iobroker "system.adapter.tahoma.0" enabled
2021-01-20 10:58:41.014 - info: host.iobroker instance system.adapter.tahoma.0 started with pid 6725
2021-01-20 10:58:45.840 - info: tahoma.0 (6725) starting. Version 0.3.3 in /opt/iobroker/node_modules/iobroker.tahoma, node: v12.19.0, js-controller: 3.1.6
2021-01-20 10:58:45.867 - info: tahoma.0 (6725) [START] Starting adapter tahoma v0.3.3.3
2021-01-20 10:58:45.871 - info: tahoma.0 (6725) [INFO] Configured polling interval: 60000
2021-01-20 10:58:48.172 - info: tahoma.0 (6725) eventRegisterID = 1f3b7c5c-ac10-3401-7548-14e5b09b0f1d
Bei mir sieht es allerdings (immer wieder, nachdem es gesperrt wurde) so aus:
Nach dutzenden Telefonaten mit Somfy und eigenen Versichen dem Problem auf die Schliche zu kommen, habe ich bereits vollgendes herausgefunden, was somit meinen aktuellen Stand darstellt:
Nachdem man 5 mal ein falsches Passwort mit seinen normalen Login-Daten eingibt, sperrt Somfy von sich aus den Login (nicht gleich den Account!). Interessanter Weise passiert dies nur für ioBroker & tahomalink. Ein Login per App (Android und IOS), sowie die Kontrolle per alexa sprachsteuerung funktionieren weiterhin!
Lässt man sich nun den Login von Somfy wieder freischalten (hotline per telefon anrufen, freischalten lassen und passwort neu vergeben per webpage) funktioniert auch der Login per tahoma-adapter im ioBroker wieder. Allerdings nur ein paar Tage... anscheinend von Freitag auf Samstag (mag auch nur zufall sein, bin mir nicht 100% sicher - war allerdings nun schon zum zweiten mal so) passiert dann der Fehler erneut: Der Login per ioBroker versucht sich erneut einzuloggen und produziert den o.a. Fehler, obwohl nie etwas an den Login Daten geändert wurde!
Die Frage ist also warum - weiß vll. jemand eine sinnige Begründung, warum von jetzt auf gleich der adapter anscheinend die Daten selbstständig ändern sollte (was für mich ziemlich aus der Luft gegriffen klingt)?
Die übrigen Lösungsansätze (neustarten, ausschalten & ausgeschaltet lassen, etc) habe ich bereits alle ausprobiert und brachten leider keinen Erfolg (offensichtlich, wenn serverseitig der Login zumindest teilweise gesperrt ist).
Liebe Grüße