Der Instanz-Status „HTTP-Fehler“ ist ja sehr allgemein. Ein Problem mit der Anmeldung/dem Token würde anders lauten („Authorisierung fehlerhaft“, „fehlende Berechtigung“).
Auch wenn die Anmeldung jetzt nur noch mit einem Hack und damit etwas umständlich funktioniert, kann ich (noch) keinen Zusammenhang damit erkennen. Ich habe auch seit vielen Monaten kein Problem mehr gehabt, weder bei NetatmoWeather noch bei NetatmoSecurity.
Insofern wäre es durchaus mal interessant zu sehen, was (in der IO-Instanz) fehlschlägt.
Da das ja u.U. recht lange dauert bis der Fehler auftritt, muss der Debug in eine Datei umgelenkt werden. Aufgrund der Größe der Datei ist vermutlich eine Zusendung des Logs per Mail besser (demel42@web.de). Und bitte unbedingt mit Angabe des Zeitpunkt des Auftretens des Problems.
jetzt wieder geschehen. Nach ein paar Tagen geht es nicht mehr.
Dann habe ich den Refreshtoken neu generiert und eingefügt.
Aber das funktioniert auch nicht.
This is caused by an URI issue. Either you’re not specifying the same URI in your calls; or the one you specified didn’t match the one you associated with your app in your account settings.
Das ist ziemlich aussagefrei.
Der gleiche Abruf klappt bei mir auf jeden Fall (natürlich haben client_id und client_secret andere Werte (weil das ja Konto-spezifisch ist) und refresh_token ist ja natürlich auch permanent anders).
Nun kannst DU ja bei Netatmo beliebig viele Apps anlegen - falls Du mehr als ein Netatmo-Produkt im Einsatz hast, hast Du das ja sowieso.
Mein Vorschlag wäre es, das DU eine weiter App anlegst und die neuen Daten in der IO-Instanz einträgst und einen neuen refresh_token. Das entsprechende Debug bitte auch zu mir.
Gute Frage, hoffen wir es. Eine Erklärung dafür kann ich leider nicht liefern, nur vermuten, das er mit dieser ClientID ab und an ein Problem hat.
Der Dump enthält leider nicht die Eingabe des refresh_token und die erste Kommunikation, ist aber erstmal egal und war nur eine Vorbereitung für eventuelle weitere Debugs
Schade, war ein Versuch wert, aber hat offensichtlich nicht geholfen.
Mit fällt derzeit nichts mehr ein, was ich jetzt machen könnte. Leider ist der Netatmo-Support wenig hilfreich - es dauert zT Wochen, bis man eine echte Reaktion bekommt und ich habe bisher nur immer zu hören bekommen, das es nicht an denen liegen kann.
Bei den Problem mit dem OAuth-Locgin war es soi, das es mit wenigen Benutzern anfing und dann im Laufe einiger Monate um sich griff - also ziemlich klar mit irgendwas mit den Benutzer-Konten zu tun hatte und auch klar, das es bei deren Login-Webseite liegt - und die einzige Reaktion von Netamo war, das es mit deren Testkonto laufen würde.
Un das Netatmo den Zugang über das Entwicklerlogin deaktiviert hatten (warum auch immer), bliebt nur diese lahme Krücke als einzige Möglichkeit über. Also das frühere Login mit Entwicklerdaten über die Netatmo-Webseite zu machen und die Authentifizierungs-Token dann in das Modul zu übernehme und nutzen. WIchtig ist dabei nur, das die ENtwickler-App nur für ein Produkt benutzt wird und bei der Refresh-Token-Generierung auch die richtigen Scopes selektiert werden.
Das Problem, das du schilderst ist mir im Forum (bisher) auch noch nicht begegnet - weder mit Weather, Security (Kamera, Rauchmelder) noch Aircare. und die 3 Module sind (nach der Anzahl der Downloads) sehr viel im Einsatz.
Ich werde natürlich noch weiter schauen, was irgendwie möglich ist, kann aber leider nichts versprechen.
Das seltsame ist ja das der Refreshtoken ein bis drei Tage geht. Dann plötzlich ist der Disconnect wieder da.
Wenn ich dann zu Netatmo auf die Seite https://dev.netatmo.com/apps/ gehe ist der Refreshtoken weg und ich muss den Scope wieder neu eintragen und den Refreshtoken neu generieren.
Das sieht sehr danach aus das es einen Zyklus bei Netatmo gibt der eine Art "Zwangstrennung " vollzieht.
Für mich ist das auch nicht nachvollziehbar.
Der AccessToken ist nur eine bestimmte Zeit gültig und wird dann unter Zuhilfenahme des RegreshToken erneuert. In diesem Zug wird i.d.R auch der RefreshToken erneuert.
Wie lange der AccessToken gültig ist, ist je nach OAuth-Implementierung unterschiedlich und wird in dem Feld „expires_in“ oder „expirarion“ bei Erzeugen des AccessToken mit geliefert.
die Spanne geht von wenigen Minuten bis mehrere Monate.
Kann sein, das es bei Netatmo 3 Tage sind - das wird bei der Eingabe des RefreshToken und der folgenden ersten Generierung des AccessToken im Debug ausgegeben („valid until …“)
Ich habe es nicht mehr vor Augen, ob beim Anmelden zum Netat-Dev-Konto ein Haken „angemeldet bleiben“ vorhanden ist. Ein Zusammenhang wäre zwar weit hergeholt, aber wir fischen sehr im Trüben.
Ansonsten könnte ich dir nur anbieten, das ich mit deinem Netatmo-Konto bei mir versuche, das nachzustellen.
Servus zusammen, mein Netatmo Modul wird seit geraumer Zeit nicht mehr erreicht. Die IO Instanz
lässt sich nicht mit der Anmeldung im Web verbinden.
Nach Anmeldung im Browser und akzeptieren der Verbindung kommt das in der Doku erwähnte Pop leider nicht hoch.
Der Zugang via Symcon/OAuth geht schon seit langem nicht mehr. Bleibt die Umstellung auch „Entwickler-Schlüssel“, seinerzeit hier beschrieben: [Modul] NetatmoWeather - #195 von demel42
Ein Hinweis: ich habe in dem Modul das WebOAuth-Login, basierend auf dem eigenen Entwicklerschlüssel realisieren können; das setzt nur ein aktive Symcon-Connect voraus (für das Login wird eine erreichbare CallBack-URL benötigt). Ohne Symcon-Connect bleibt es bei dem bisherigen Verfahren.
Verfügbar erstmal im Modulstore als Beta
Ich habe immer wieder Probleme mit dem Modul Netatmo. Nach einiger Zeit ist das Modul nicht zu gebrauchen weil der Token nicht mehr gilt.
Ich habe den Netatmo Support mal angeschrieben.
Das kam von denen zurück: Please note that the access_token value must be refreshed every 3 hours to maintain connectivity.
Das würde auch mein Problem erklären.
Ich frage mich nur „Warum läuft das bei Euch und bei mir nicht ?“.
Der access_token wird regelmäßig ungültig, die Dauer der Gültigkeit wird bei den Abruf des token in dem Feld expire_in mitgeteilt.
Dann wir mittels des refresh_token ein beuer access_token geholt. Dabei wird der bisherige refresh_token ungültig und es wird mit dem access_token ein neuer refresh_token geliefert.
Die Gültigkeit wird bei jedem Zugriff überprüft.
Warum bei Dir immer wieder mal der refresh_token ungültig wird, kann ich nicht sagen.
In der aktuellen Beta habe ich ja eine Anpassung gemacht, was das Holen des Token angeht ( setzt ein aktives Symcon-Connect voraus)
Wird aber nichts daran ändern, das bei Dir der Refresh-Token regelmässig ungültig eird.