Netatmo Modul - 38_netatmo.pm (Support)

[Borkk]

Da ich meine gesamte Installation mittlerweile auf einer N100 Kiste mit Proxmox und Docker laufen habe, habe ich mir schon vor ein paar Monaten mal zum testen einen Home Assistant als VM gestartet. Was soll ich sagen, die Netatmo Anbindung war in 2 Minuten erledigt und läuft seit Monaten stabil durch. Auch nach div. Neustarts...

Ein Umstieg auf HA wäre mega aufwendig und eigentlich liebe ich mein FHEM, aber wenn hier so langsam die Module wegsterben, bliebt uns wohl keine Wahl.

Eigentlich Schade...

Ich werde mir jetzt erst mal damit helfen die benötigten Daten per MQTT von HA nach FHEM zu schicken. Dann kann ich das Modul hier entfernen.   

[Borkk]

So ich habe die Nase voll. Heute startet das "extra" FHEM für Netatmo (mal wieder) nicht mehr.. Ich nutze jetzt die Netatmo Integration in HomeAssisstant und übertrage die Werte per MQTT an FHEM. Klappt einwandfrei. Netatmo wird jetzt aus FHEM gelöscht. Waren eh nur noch Dummys, die sich per FHEM2FHEM die Werte, von der separaten FHEM Instanz geholt haben.

Ist schon komisch, 2013 konnte man die Netatmo Module nur über ein externes Python Script in FHEM integrieren
(https://forum.fhem.de/index.php?topic=14457.0)

Andre hatte dann auf meine Bitte hin und mit der API zu meinen Geräten über Nacht das erste Modul gebaut. Genau für solche Aktionen hab ich FHEM immer geliebt.

[KyleK]

Im Quellcode von 38_netatmo.pm steht an 3 Stellen ein konkreter Wert für `client_secret`.
Ist das so beabsichtigt?

Sollte nicht immer das persönliche client_secret verwendet werden?

[Adriano]

Im Quellcode von 38_netatmo.pm steht an 3 Stellen ein konkreter Wert für `client_secret`.
Ist das so beabsichtigt?

Sollte nicht immer das persönliche client_secret verwendet werden?

stimmt. das koennte das problem sein. hier wird hart "8ab584d62ca2a77e37ccc6b2c7e4f29e" benutzt und nicht der wert der variablen.

Code Auswählen Erweitern

sub
netatmo_getAppToken($)
{
  my ($hash) = @_;
  my $name = $hash->{NAME};

  return undef if(IsDisabled($name) || !defined($name));

  return Log3 $name, 1, "$name: No username was found! (getAppToken)" if(!defined($hash->{helper}{username}));
  return Log3 $name, 1, "$name: No password was found! (getAppToken)" if(!defined($hash->{helper}{password}));


  my($err,$data) = HttpUtils_BlockingGet({
    url => "https://app.netatmo.net/oauth2/token",
    method => "POST",
    timeout => 5,
    noshutdown => 1,
    header => "Content-Type: application/x-www-form-urlencoded; charset=utf-8\r\nUser-Agent: NetatmoSecurity/5.0.13 (com.netatmo.camera; build:809; iOS 13.5.0) Alamofire/5.6.4",
    data => {grant_type => 'password', client_secret => '8ab584d62ca2a77e37ccc6b2c7e4f29e', username => netatmo_decrypt($hash->{helper}{username}), password => netatmo_decrypt($hash->{helper}{password}), scope => 'security_scopes read_station', client_id => 'na_client_ios_welcome'},
  });


  netatmo_dispatch( {hash=>$hash,type=>'apptoken'},$err,$data );
}

...

netatmo_refreshAppToken($;$)
{
  my ($hash,$nonblocking) = @_;
  my $name = $hash->{NAME};

  if($hash->{network} eq "dns")
  {
    Log3 $name, 2, "$name: app token dns error, update postponed!";
    InternalTimer( gettimeofday() + 600, "netatmo_refreshAppTokenTimer", $hash);
    return undef;
  }

  if( defined($hash->{access_token_app}) && defined($hash->{expires_at_app}) ) {
    my ($seconds) = gettimeofday();
    return undef if( $seconds < $hash->{expires_at_app} - 300 );
  } elsif( !defined($hash->{refresh_token_app}) ) {
    Log3 $name, 2, "$name: missing app refresh token!";
    netatmo_getAppToken($hash);
    return undef;
  }

  delete($hash->{csrf_token});
  Log3 $name, 3, "$name: refreshing app token";


  if( $nonblocking ) {
    HttpUtils_NonblockingGet({
      url => "https://app.netatmo.net/oauth2/token",
      timeout => 30,
      noshutdown => 1,
      header => "Content-Type: application/x-www-form-urlencoded; charset=utf-8\r\nUser-Agent: NetatmoSecurity/5.0.13 (com.netatmo.camera; build:809; iOS 13.5.0) Alamofire/5.6.4",
      data => {refresh_token => $hash->{refresh_token_app}, scope => 'security_scopes read_station', grant_type => 'refresh_token', client_id => 'na_client_ios_welcome', client_secret => '8ab584d62ca2a77e37ccc6b2c7e4f29e'},
      hash => $hash,
      type => 'apptoken',
      callback => \&netatmo_dispatch,
    });
  } else {
    my($err,$data) = HttpUtils_BlockingGet({
      url => "https://app.netatmo.net/oauth2/token",
      timeout => 5,
      noshutdown => 1,
      header => "Content-Type: application/x-www-form-urlencoded; charset=utf-8\r\nUser-Agent: NetatmoSecurity/5.0.13 (com.netatmo.camera; build:809; iOS 13.5.0) Alamofire/5.6.4",
      data => {refresh_token => $hash->{refresh_token_app}, scope => 'security_scopes read_station', grant_type => 'refresh_token', client_id => 'na_client_ios_welcome', client_secret => '8ab584d62ca2a77e37ccc6b2c7e4f29e'},
    });

    netatmo_dispatch( {hash=>$hash,type=>'apptoken'},$err,$data );
  }
}
...


[Adriano]

Wer oder was ist "na_client_ios_welcome" 

[rcaspar]

Hi all

Ist jemand weitergekommen?
Aktuell geht bei mir nix mehr, "LOGIN FAILED" ist alles was ich noch raus bringe, obwohl die credentials stimmen. Letzter Update der Readings war am 7.12.24.

Habe auch schon versucht die bereits genannten 2 Punket im Code zu ersetzen:
client_secret => '8ab584d62ca2a77e37ccc6b2c7e4f29e' zu client_secret=> $hash->{helper}{client_secret}
client_id => 'na_client_ios_welcome' zu client_id => $hash->{helper}{client_id}

Leider ohne Erfolg

René

[rcaspar]

Hi all

Sorry, ich war zu doof - habe statt den Wert des "client secret" den "access token" eingetragen.... naja

Jetzt funzt es wieder, allerdings updated es bei den Temperatursensoren alle Werte ausser "Temperatur" und "Feuchtigkeit". Trend, Batterie, etc. wrden aktualisiert.

René

[Adriano]

ja, da hilft nur das entsprechende device loeschen und am hauptdevice autocreate aufrufen.

[Markus M.]

Wenn das disable des Moduls dann abgeschaltet wird, läuft das Logfile innerhalb kürzester Zeit so zu

Mit was genau?

Ich habe immer noch nicht verstanden ob das ein Problem der API ist oder ein Problem des Moduls. Bei letzterem verstehe ich nicht, warum das Problem seit vielen Monaten nicht gefixt wird???

Vermutlich des Moduls. Der Grund warum das nicht gefixt wird ist aber recht einfach: Keine Zeit.
Meine Netatmo Stationen liegen gerade fast alle in einer Umzugskiste, die nächsten Monate werde ich eventuell nicht mal eine laufende FHEM Instanz mein Eigen nennen.

Wie dem auch sei: Ich habe gerade mein FHEM neugestartet, Token Aktualisierung funktioniert sofort nach Neustart.
Dann habe ich mein FHEM hart beendet, funktioniert ebenfalls und holt nach dem Neustart einen neuen Token.
Ich kann das eben aktuell leider nicht reproduzieren, auch wenn ich das Problem ebenfalls schon hatte.
Es scheint nur dann schief zu gehen, wenn FHEM vorher schon blockiert ist und das Reading nicht geschrieben wird.

Im Quellcode von 38_netatmo.pm steht an 3 Stellen ein konkreter Wert für `client_secret`.
Ist das so beabsichtigt?

Ja, das ist so beabsichtigt um die App zu emulieren. Forecast und Karten funktionieren sonst nicht mehr.

ja, da hilft nur das entsprechende device loeschen und am hauptdevice autocreate aufrufen.

2-3h warten sollte auch funktionieren, dann sollten die Timer der Devices wieder starten.

[Rudi_Hirsch]

Vielleicht hilft die Beobachtung dass beim Löschen und wieder Importieren einer Mess-Station uralte Zeitstempel mit zugehörigen Werten auftauchen und es bis zum aktuellen Datensatz dauert. Dabei taucht statt "ok" "dead" auf. Nach ein paar Abrufzyklen sind die Daten der abgerufenen  Station wieder aktuell und die Station ist wieder "ok"

[Markus M.]

Vielleicht hilft die Beobachtung dass beim Löschen und wieder Importieren einer Mess-Station uralte Zeitstempel mit zugehörigen Werten auftauchen und es bis zum aktuellen Datensatz dauert. Dabei taucht statt "ok" "dead" auf. Nach ein paar Abrufzyklen sind die Daten der abgerufenen  Station wieder aktuell und die Station ist wieder "ok"

Je nachdem wie alt die Station ist, kommt da erst mal ein Jahrzehnt an Wetterdaten und blockiert FHEM.
Neu Anlegen ist eine schlechte Idee

[Adriano]

Vielleicht hilft die Beobachtung dass beim Löschen und wieder Importieren einer Mess-Station uralte Zeitstempel mit zugehörigen Werten auftauchen und es bis zum aktuellen Datensatz dauert. Dabei taucht statt "ok" "dead" auf. Nach ein paar Abrufzyklen sind die Daten der abgerufenen  Station wieder aktuell und die Station ist wieder "ok"

Je nachdem wie alt die Station ist, kommt da erst mal ein Jahrzehnt an Wetterdaten und blockiert FHEM.
Neu Anlegen ist eine schlechte Idee

schlechte idee? naja, es funktionierte dadurch sofort wieder. und "abwarten" hatte ich nach 1 woche aufgegeben. da hatte sich ncihts getan.

[Seli]

Ich habe es schon mehrfach in diesem Thread geschrieben, aber ich wiederhole es noch einmal, da es schon eine Zeit zurückliegt: Der Neustart funktioniert eigentlich immer. Wird danach ein hartes Beenden getestet, funktioniert dies auch. Wenn aber der Neustart eine Weile zurückliegt, und Netatmo in der Zwischenzeit per refresh ein neues acces-token geholt hat und DANN ein hartes Beenden gemacht wird (ohne save zu drücken!), dann funktioniert der Login nach dem Neustart nicht mehr! Es scheint so, dass das per refresh erhaltene neue refresh-token nicht so gespeichert wird, dass es nach einem harten Neustart verwendet wird. Ich hatte durch Logausgaben im Modul nachgewiesen, dass ein altes Refresh-Token verwendet wird (vom letzten save). Genau so verhält es sich auch bei mir. Wenn ich einen Neustart mache oder kurz vorher einen save, dann funktioniert es. Wenn FHEM aber so lange läuft, dass das access-token ungültig wird (laut Netatmo drei Stunden) und dann ein Absturz erfolgt, dann kann ich drauf gehen, dass der Login nicht mehr funktioniert.

Zweiter Punkt: Das Holen und Eintragen eines neuen Refresh-Tokens benötigt oft viele Versuche (1-10). Ich habe beobachtet: Immer dann, wenn das Modul keine Lust mehr hat und selbstständig das Device auf disabled setzt, dann ist der nächste Versuch ein neues Refresh-Token im DEF zu setzen erfolgreich! Das disabled-Attribut muss natürlich entfernt werden. Aber bis ich dahin erst mal komme, dauert es eben immer einige Versuche.

Das Fehlverhalten hat begonnen, seit Netatmo bei jedem refresh ein neues Refresh-Token ausstellt. Dies war vor ca. einem halben Jahr. Davor hat Netatmo immer das gleiche refresh-token geliefert, weswegen sich das Problem mit dem Aktualisieren dieses gespeicherten Refresh-Tokens nicht gestellt hat.

[Rudi_Hirsch]

Die Beobachtung kann ich nicht vollständig bestätigen. Das Refresh-Token wird nicht bei jedem Abruf aktualisiert. Insofern kommt es neben der Pause beim Restart auch auf den Zeitpunkt an.
Auch wenn das Modul nach einem Neustart überlebt und fehlerfrei läuft, werden bei mir die Daten der abgerufenen Wetterstation(en) nicht mehr abgespeichert.
Komisch ist auch, dass die Netatmo-API-Beschreibung zwischen historischen Daten und aktuellen Daten unterscheidet.

[Seli]

Die Beobachtung kann ich nicht vollständig bestätigen. Das Refresh-Token wird nicht bei jedem Abruf aktualisiert.

Wie ist dies zu verstehen? Laut Netatmo wird bei jedem Refresh ein neues Refresh-Token ausgegeben, das dann bei nächsten Refresh zu verwenden ist. Ist gemeint, dass dies nicht (immer) der Fall ist? Oder ist gemeint, dass das Modul das refresh-Token nicht bei jedem Abruf aktualisiert (in der Variable, im reading)? Bei Letzterem habe ich ja gerade die Beobachtung gemacht, dass die Aktualisierung dieses Tokens vom Modul nicht sauber gehandelt wird. Daher wäre dies kein Widerspruch. Oder habe ich das missverstanden?