Netatmo Modul - 38_netatmo.pm (Support)

Begonnen von Markus M., 17 Mai 2016, 12:37:34

Vorheriges Thema - Nächstes Thema

aski71

Kann ich bestätigen.
Bei mir ging netatmo auch ohne Neustart wieder auf LOGIN FAILED.
Half nur, bei netatmo neuen Token generieren.
Ich fürchte, da muss ein Entwickler des netatmo Moduls ran.

Rainer H.

kann ich leider auch bestätigen  :'(

tobias.vorberg


tomcat.x

Ist denn bei Euch die Internet-Verbindung (oder Netzwerk/WLAN) zwischendurch unterbrochen? Das Access-Token ist ja nur 3 Stunden gültig und zur Erneuerung wird eine Verbindung zu netatmo benötigt. Bisher hätte es aber auch nach Ablauf mit dem gleichbleibenden Refresh-Token noch funktioniert, ein neues zu generieren. Das funktioniert jetzt nicht mehr.
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.00), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

no_Legend

Hab das gleiche Problem.
FHEM ist dann komplett, durch das Netamo Modul blockiert.

Wäre es nicht sindvoll, dass wenn 5mal hintereinander ein Einloggen möglich ist, das Modul seine versuche einstellt?
Das ist doch so kein Zustand.
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

tomcat.x

Ja, klar. Aber da kann nur der Modul-Autor helfen und der kommt wohl gerade nicht dazu. Alles in den letzten Einträgen hier sind nur Workarounds. Das Refresh-Token müsste gespeichert werden, so dass es einen Neustart übersteht und die Erneuerungsversuche dürften nicht zum blockieren führen. Dazu gab es übrigens schon einen Versuch (https://forum.fhem.de/index.php?msg=1296426), allerdings ohne Rückmeldung.

Trotzdem müsste geklärt werden, warum der Fehler auch ohne Neustart auftritt. Denn dass das Token nur noch 3 Stunden gültig ist, kann auch der Modulautor nicht beeinflussen.
FHEM: 6.3 auf Raspi 3B+, Raspbian (Buster), Perl v5.28.1
Sender/Empfänger: 2 x CULv3, Duofern Stick, HM-MOD-RPI-PCB
Gateways: FRITZ!Box 6591 (OS: 8.00), Trädfri, ConBee 2,  piVCCU, OpenMQTTGateway
Sensoren/Aktoren: FRITZ!DECT, FS20, FHT, HMS, HomeMatic, Trädfri, DuoFern, NetAtmo

aski71

Wer ist denn der Autor? Hat den mal jemand versucht, aktiv zu kontaktieren?
Ich fürchte, ohne ihn geht's nicht weiter.

no_Legend

Nach dem SVN war die letzte Änderung vom user "moises"
Docker FHEM immer aktuell,4x HMLAN, CUL443, CUL868 -homekit/siri -tablet ui -homebridge
Device, diverse:
Homematic, Shelly, Tasmota, MQTT, Unifi Network usw.

aski71

Ich habe gerade mal in der Netatmo Developer Doc nachgesehen zum Token Refresh.
Dort steht:

invalid_grant:
This is caused by an URI issue. Either you're not specifying the same URI in your calls; \ror the one you specified didn't match the one you associated with your app in your account settings.

Weiß jemand, was die mit "the same URI" meinen? Die gleiche URI wie was?
In den API-Einstellungen der bei Netatmo definierten App kann man ja redirectURI und webhookURI eingeben. Beides ist leer.
Kann es sein, dass man da neuerdings verpflichtend was eintragen muss, damit der Refresh klappt?
Aber was?

Markus M.

Hallo zusammen,

das Modul ist eigentlich schon seit einiger Zeit für die neuen Netatmo Prozesse vorbereitet.
Ich habe bei mir auch keine Probleme damit.
Wenn ihr natürlich neu startet ohne zu speichern, ist eventuell der Refresh Token verloren.
Generell morgen mal ein Update machen, das sollte zumindest die Blockaden verhindern.

Zitat von: aski71 am 07 Juni 2024, 18:23:54Ich habe gerade mal in der Netatmo Developer Doc nachgesehen zum Token Refresh.
Dort steht:
invalid_grant:
This is caused by an URI issue. Either you're not specifying the same URI in your calls; \ror the one you specified didn't match the one you associated with your app in your account settings.

Weiß jemand, was die mit "the same URI" meinen? Die gleiche URI wie was?
In den API-Einstellungen der bei Netatmo definierten App kann man ja redirectURI und webhookURI eingeben. Beides ist leer.
Kann es sein, dass man da neuerdings verpflichtend was eintragen muss, damit der Refresh klappt?
Aber was?

Bei mir steht in der App bei webhookURI diese auch drin, also z.B. http://user:pass@dynamic.dns/fhem/netatmo
redirectURI ist leer.
Probier das bitte mal aus ob es was hilft die webhookURI einzutragen.
Aktuell weder Smarthome noch FHEM vorhanden

aski71

Zitat von: Markus M. am 08 Juni 2024, 00:25:17
Zitat von: aski71 am 07 Juni 2024, 18:23:54Ich habe gerade mal in der Netatmo Developer Doc nachgesehen zum Token Refresh.
Dort steht:
invalid_grant:
This is caused by an URI issue. Either you're not specifying the same URI in your calls; \ror the one you specified didn't match the one you associated with your app in your account settings.

Weiß jemand, was die mit "the same URI" meinen? Die gleiche URI wie was?
In den API-Einstellungen der bei Netatmo definierten App kann man ja redirectURI und webhookURI eingeben. Beides ist leer.
Kann es sein, dass man da neuerdings verpflichtend was eintragen muss, damit der Refresh klappt?
Aber was?

Bei mir steht in der App bei webhookURI diese auch drin, also z.B. http://user:pass@dynamic.dns/fhem/netatmo
redirectURI ist leer.
Probier das bitte mal aus ob es was hilft die webhookURI einzutragen.

Versteh ich das richtig? Bei dev.netatmo.com in den App-Einstellungen die webhookURI mit Kennung und Passwort im Klartext eingeben? Das käme mir spooky vor. 🤔 Zudem ist mein fhem ja nicht von außen zugänglich.

Markus M.

Zitat von: aski71 am 08 Juni 2024, 08:29:13Versteh ich das richtig? Bei dev.netatmo.com in den App-Einstellungen die webhookURI mit Kennung und Passwort im Klartext eingeben? Das käme mir spooky vor. 🤔 Zudem ist mein fhem ja nicht von außen zugänglich.
Verstehst du richtig, meins schon. Das ist dann natürlich eine eigene FHWEB Instanz, die nicht besonders viel kann.
Das wird aber nur bei Benutzung der Webhooks benötigt.
D.h. der Netatmo Server pingt dein FHEM wenn was passiert. Was z.B. für die Kameras sehr praktisch ist, da du quasi Real-Time Notifications bekommst wer oder was gerade gesehen wird.


Aber zurück zum eigentlichen Problem hier:
Ich rate jetzt einfach mal, dass alle bei denen es partout nicht funktionieren will und die jedes mal invalid_grant bekommen, den Netatmo Account ohne den ersten Parameter "ACCOUNT" definiert haben.
Oopsie! ;D   Macht morgen nochmal ein Modul Update, dann funktioniert es wieder.

Aktuell weder Smarthome noch FHEM vorhanden

aski71

Zitat von: Markus M. am 08 Juni 2024, 23:21:46
Zitat von: aski71 am 08 Juni 2024, 08:29:13Versteh ich das richtig? Bei dev.netatmo.com in den App-Einstellungen die webhookURI mit Kennung und Passwort im Klartext eingeben? Das käme mir spooky vor. 🤔 Zudem ist mein fhem ja nicht von außen zugänglich.
Verstehst du richtig, meins schon. Das ist dann natürlich eine eigene FHWEB Instanz, die nicht besonders viel kann.
Das wird aber nur bei Benutzung der Webhooks benötigt.
D.h. der Netatmo Server pingt dein FHEM wenn was passiert. Was z.B. für die Kameras sehr praktisch ist, da du quasi Real-Time Notifications bekommst wer oder was gerade gesehen wird.

Ok, ich nutze nur die Wetterstation und habe auch nur den scope read_station enabled.
Dann sollte ich das nicht benötigen, oder?

Zitat von: Markus M. am 08 Juni 2024, 23:21:46Aber zurück zum eigentlichen Problem hier:
Ich rate jetzt einfach mal, dass alle bei denen es partout nicht funktionieren will und die jedes mal invalid_grant bekommen, den Netatmo Account ohne den ersten Parameter "ACCOUNT" definiert haben.
Oopsie! ;D   Macht morgen nochmal ein Modul Update, dann funktioniert es wieder.

Da muss ich Dich leider enttäuschen. Der Netatmo Account ist bei mir schon immer mit dem ersten Parameter ACCOUNT definiert. 😅 Ich habe Dir per Email logs geschickt und kann das morgen nochmal machen.
Aber, wenn Du im Modul nochmal was geändert hast, installiere ich gerne erstmal nochmal das neue und schaue, was passiert.

Markus M.

Zitat von: aski71 am 08 Juni 2024, 23:59:06Ok, ich nutze nur die Wetterstation und habe auch nur den scope read_station enabled.
Dann sollte ich das nicht benötigen, oder?

...

Da muss ich Dich leider enttäuschen. Der Netatmo Account ist bei mir schon immer mit dem ersten Parameter ACCOUNT definiert. 😅 Ich habe Dir per Email logs geschickt und kann das morgen nochmal machen.
Aber, wenn Du im Modul nochmal was geändert hast, installiere ich gerne erstmal nochmal das neue und schaue, was passiert.

Bei denen ohne ACCOUNT hat es jedenfalls definitiv nicht persistent funktioniert.
Check morgen mal ob expires_at einen sinnvollen Timestamp enthält und ob bei dir nach diesem Zeitpunkt dann ein Internal last_refresh auftaucht.
Du kannst auch mal beobachten ob sich die Tokens aktualisieren.

Wenn das der Fall ist, liegt es am scope. Ehrlich gesagt denke ich dass es nur noch daran liegen kann.
Du musst der App den vollen Scope geben, d.h.:
read_thermostat write_thermostat read_camera write_camera access_camera read_doorbell access_doorbell read_presence write_presence access_presence read_homecoach read_carbonmonoxidedetector read_smokedetector read_station
Das kannst du auch jetzt gleich mal ausprobieren.
Aktuell weder Smarthome noch FHEM vorhanden

aski71

Als über nacht jetzt folgender Stand:

Neue Tokens generiert um ca. 23:30 Uhr

Letzte erfolgreiche Aktualisierung der Tokens im Log um 6:42:

2024.06.09 06:42:54 5: netatmo: refreshing token (timer)
2024.06.09 06:49:22 5: netatmo: refreshing app token (timer)
2024.06.09 06:49:22 3: netatmo: refreshing app token
2024.06.09 06:49:22 4: netatmo: dispatch (apptoken)
2024.06.09 06:49:22 4: netatmo: dispatch return: apptoken
2024.06.09 06:49:22 5: {
  'access_token' => '< ... token ... >',
  'expire_in' => 10800,
  'refresh_token' => '< ... token ... >',
  'scope' => [
               'security_scopes',
               'read_station'
             ],
  'expires_in' => 10800
}


Dann update auf das neue Modul und Restart fhem um 8:19:

2024.06.09 08:18:19 3: netatmo: refreshing token
2024.06.09 08:18:19 4: netatmo: dispatch (token)
2024.06.09 08:18:19 4: netatmo: dispatch return: token
2024.06.09 08:18:19 5: {
  'error' => 'invalid_grant'
}

2024.06.09 08:18:19 2: netatmo: json message error: invalid_grant
2024.06.09 08:18:19 3: netatmo getDevices (devicelist)
2024.06.09 08:18:19 1: netatmo: No access token was found! (getDevices)
2024.06.09 08:18:19 3: netatmo: refreshing token
2024.06.09 08:18:19 4: netatmo: dispatch (token)
2024.06.09 08:18:19 4: netatmo: dispatch return: token
2024.06.09 08:18:19 5: {
  'error' => 'invalid_grant'
}

Habe jetzt neue Tokens generiert mit dem vollen Scope, netatmo ACCOUNT in der fhem.cfg damit redefiniert und neu gestartet. Läuft jetzt wieder mit:

expires_at 1717923450
expires_at_app 1717923451