Netatmo Modul - 38_netatmo.pm (Support)

[FHEM-Tester]

Hallo,

ich muss mich leider anschließen: nach jedem Neustart von FHEM ist der Access Token futsch und ich muss einen neuen erstellen

https://helpcenter.netatmo.com/hc/en-us/community/posts/20007691851538-API-REST-Refresh-Token

[Seli]

Hallo,

ich muss mich leider anschließen: nach jedem Neustart von FHEM ist der Access Token futsch und ich muss einen neuen erstellen

Ja, das kann ich so bestätigen. Ich habe eigene Logausgaben im Netatmo-Modul hinzugefügt, die das auch belegen! Ein einfacher shutdown restart genügt, um das Refresh-Token kaputt zu machen. Getestet darf das erst, wenn das Modul mindestens einen Refresh erfolgreich durchgeführt hat, da dann die DEF nicht mit den internen Variablen übereinstimmt. Dies scheint die Ausgangsproblematik zu sein.

Ablauf/Logauszug (Token auf 4 Zeichen verkürzt):

Letzter refresh setzt Token auf 52fbd

Von mir hinzugefügte Logausgaben zeigen, dass die internen (helper-)Variablen korrekt gesetzt werden:

2024.08.03 11:44:16 1: NWetter: parseToken: Setting helper+refresh_token to ...52fbd
2024.08.03 11:44:16 1: NWetter: parseToken: Updating hidden .refresh_token to ...52fbd

(Token in fhem.cfg DEF ist noch auf b9be!)

Neustart mit "shutdown restart"

Das refresh_token wird mit dem alten Token b9be initialisiert, der folgende Refresh schlägt dadurch fehl!

2024.08.03 11:50:04 1: NWetter: helper/refresh_token set to ...b9be (!!!! FEHLER !!!!)
2024.08.03 11:50:04 3: NWetter: poll (ACCOUNT)
2024.08.03 11:50:04 3: NWetter: refreshing token
2024.08.03 11:50:04 2: NWetter: json message error: invalid_grant
2024.08.03 11:50:04 2: NWetter: invalid refresh ticket, retrying once
2024.08.03 11:50:04 2: NWetter: invalid refresh ticket, setting helper-refresh-token to
...
2024.08.03 11:52:11 1: NWetter: No refresh token found
2024.08.03 11:52:11 1: NWetter: No refresh token found, calling netatmo_getToken
2024.08.03 11:52:11 1: NWetter: No helper-refresh token was found!

Die intern gesetzten Variablen überleben somit den Neustart nicht oder sie werden nach dem Neustart nicht für die Initialisierung verwendet!

[Borkk]

Ich schließe mich an, nach jeden Neustart ist der Token hin. 

[Pati_Alpha]

Hey,

ich habe auch ein Problem mit dem Netatmo Modul. Es geht um die Daten.
In der Map auf deren Webseite sehe ich diverse, mich umgebende Wetterstationen mit plausiblen Daten.

Im Netatmo Modul gibt mir ein get public mit den entsprechenden Koordinaten ebenfalls eine identische Liste MIT(!) identischen, plausiblen Wetterdaten aus.
Füge ich jedoch eine beliebige dieser Stationen mit dem Pfeil als Device hinzu, steht dort immer sowas wie hier:

Code Auswählen Erweitern

active dead 2024-08-14 10:42:25
humidity 85 2017-12-25 09:52:05
pressure 1016.8 2017-12-25 09:32:20
temperature 8.1 2017-12-25 09:52:05

Heißt: Dort werden die Stationen dann immer als "dead" gemeldet und die Messwerte sind von Anno-Tuck (immer Unterschiedlich je Station, mal 2017, mal 2022...). :/

[tomcat.x]

Hast Du mal einen Moment gewartet und dann ein Update gemacht? Das hat bei mir funktioniert. Ich bin auch nur darauf gekommen, weil ich das gleiche bei meiner eigenen Station beobachtet habe, nachdem ich aufgrund oben besprochener Problematik öfters ein neues Token definieren musste.

[gramtoc]

Hallo,
habe auch das Tokenproblem. Nach einer gewissen Zeit kommt in den logs "No access token was found!" und FHEM hängt sich auf.
Ich erklär mal kurz mein Vorgehen um das Ganze zu beheben (Vielleicht mach ich dabei einen Fehler):
Ich stoppe fhem über ssh, resette über die netatmo-developer-site die keys der App, generiere dann einen neuen scope, dann trage ich
die neue client id, client secret und den refresh token direkt in die bestehende Gerätedefinition in die fhem.cfg ein und starte dann
wieder fhem über ssh. Dann funktioniert das Ganze wieder, leider nur für eine gewisse Zeit. Hab auch schon eine neue App auf der Developersite generiert.

Was mir aber jetzt aufgefallen ist:
In den Internals des Netatmo-Devices gibt es ja vier Token Einträge (access_token, access_token_app, refresh_token und refresh_token_app).
Im Zustand "Login failed" fehlt dann der access_token Eintrag.

Wenn ich nach der "Reparatur des Devices", so wie oben beschrieben, diese Token-Einträge mit der Developer-Site vergleiche,
finde ich die Tokenwerte der Site in keinem der 4 Internals-Einträge, aber das Device funktioniert komischerweise bis zum nächsten Login failed

Vielleicht kann mir auch jemand erklären, was genau diese 4 Internals-Einträge für Bedeutung haben?

Wär cool wenn man das ganze irgendwann mal beheben könnte.

Gruß
Tom

[tomcat.x]

Hallo Tom,

so wie ich das verstanden habe, ist es so: Man braucht das Refresh-Token um ein neues Access-Token zu bekommen, über das dann der Update läuft. Beide sind aber nur noch ein paar Stunden (3?) gültig. Sie werden durch das Modul immer wieder aktualisiert. Die Werte von der Developer-Seite findest Du daher nach kurzem nicht mehr im Modul. Man trägt ja auch nur das Refresh-Token ein.

An Deiner Vorgehensweise kann ich keinen Fehler finden, außer dass es zu aufwändig ist. Er reicht neue Token zu generieren und das Refresh-Token im Device einzutragen, ohne fhem neu zu starten.

Bei mir läuft das dann, bis ich eine Neustart ohne vorheriges "save" mache oder bis fhem ungeplant abstürzt, was bei mir so gut wie nie vorkommt. Eigentlich sollte es nach den letzten Modul-Änderungen einen Neustart ohne save überleben, das scheint bei einigen aber nicht zu funktionieren. In einem Test habe ich das auch nicht hinbekommen.

Was ich aber nicht habe, dass das im laufenden Zustand irgendwann nicht mehr funktioniert. Hatte schon mal gefragt, ob bei denen mit diesem Problem vielleicht die Internet-/ WLAN-Verbindung nicht dauerhaft da ist. Da kam aber keine Rückmeldung. Gleiches Problem hätte man, wenn man fhem für längere Zeit stoppen würde. Dann wären die Token nicht mehr gültig und es könnten keine neuen generiert werden. Wenn ich das richtig in Erinnerung habe, sind die Token wie gesagt 3 Stunden gültig und nach 2 Stunden 20 (oder 40?) Minuten werden schon neue generiert. Egal welcher Wert richtig ist, nach einer Stunde Downtime oder ohne Internet würde das schon nicht mehr funktionieren.

Viele Grüße
Thomas

[gramtoc]

Danke tomcat.x für deine Ausführungen bzw. Tips.

[topa_LE]

Kann ich ebenfalls bestätigen, nach den Restart ist der Token kaputt.

[WolfgangV]

...ebenso bei mir schon wiederholte Male auch im laufenden Betrieb ohne sichtbaren Anlass.
Plötzlich die bekannte Fehlermeldung und Modul disabled. Wenn disable auf 0 gesetzt wird, läuft das Logfile mit Fehlermeldungen so zu, dass FHEM abstürzt.

Gruß

Wolfgang

[ohosch]

Das ist sehr sonderbar.
Beim letzten Neustart war das Modul nach eigener Aussage noch Connected, allerdings kamen keine autuellen Werte zur Temperatur oder Feuchtigkeit mehr an.
Sonderbarerweise wurden Updates zu Temp_min und Temp_max empfangen.

Jetzt habe ich das Modul aktualisiert und den Refresh Token neu erzeugt.
Mal sehen wie lange das jetzt hält.

Viele Grüsse,
Oliver

[tomcat.x]

@ohosch: Das gleiche hatte ich auch schon beobachtet. Die Werte kamen aber später. Da waren dann vorher auch uralte Zeitstempel dahinter.

Zumindest direkt hatte ein Update vom Account-Grät und danach den anderen auch nichts gebracht. Habe ich dann mit Abstand mehrfach versucht. Ob es ohne das Update von alleine irgendwann wieder funktioniert, habe ich noch nicht ausprobiert.

[Pati_Alpha]

@ohosch: Das gleiche hatte ich auch schon beobachtet. Die Werte kamen aber später. Da waren dann vorher auch uralte Zeitstempel dahinter.

Na das Problem habe ich generell auch! Siehe ein paar Posts weiter oben! :O
Funktioniert es denn bei dir irgendwie, diese alten Zeitstempel wegzubekommen?

[tomcat.x]

Also bei mir sind die "nach einiger Zeit" weg, also Werte und Zeitstempel. Wie geschrieben, mache ich mehrfach get ... update, aber weiß nicht, ob es nur dadurch irgendwann aktualisiert wird oder auch so.

[ohosch]

Aktuell kommen die Updates wieder rein. Ich vermute mal, bis es wieder einen Neustart es FHEM gibt. Da müssen wir einfach weiter beobachten.