Netatmo driver doesn't seem to be working with fresh install weewx 5.0
Re-Install from weewx did not solve the Problem. I need help please.
Raspberry PI 4 - 4GB
:~ $ uname -a
Linux 6.6.31+rpt-rpi-v8 #1 SMP PREEMPT Debian 1:6.6.31-1+rpt1 (2024-05-29) aarch64 GNU/Linux
:~ $ cat /etc/issue
Debian GNU/Linux 12
:~ $ sudo dpkg -l weewx
weewx 5.0.2-1 all weather software
netatmo: netatmo-client: failed attempt 1 of 5 to get data: HTTP Error 400:
netatmo: netatmo-client: waiting 10 seconds before retry
netatmo: netatmo-client: url: https://api.netatmo.com/oauth2/token data: b'grant_type=refresh_token&refresh_token=refresh_token_as_num_hidden&client_id=client_id_as_num_hidden&client_secret=client_secret_as_hidden' hdr: {'Content-Type': 'application/x-www-form-urlencoded;charset=utf-8'}
cat /etc/weewx/weewx.conf
station_type = netatmo
[netatmo]
# mode = sniff
mode = cloud
username = **********
password = **********
client_id = **********
client_secret = **********
refresh_token = *********
# access_token = **********
driver = user.netatmo
# port = 80
# host = 70:********
# device_id = 70:*********
Comments
13 comments
Hello,
Did you apply the modification concerning the refresh_token process we pushed yesterday ?
When you refreshed an access_token using the associated endpoint https://api.netatmo.com/oauth2/token, Netatmo servers responded with a couple of tokens : an access_token and a refresh_token. If the previous access_token was still valid, the refresh_token value was never renewed
Starting from now, this behavior changed to be compliant with the recommendations of the RFC of the OAuth2 Authorization Framework (section 10.4) and improving the security of the data of our users
When refreshing tokens, access_token and refresh_token values will be automatically renewed and former tokens invalidated
So, if you do not update and use the new refresh_token value when refreshing your access_token, your users will be disconnected after 3 hours and you will retrieve an “invalid_grant” error
To fix it, you need to update the tokens value as soon as you get the newly generated ones
Have a good day,
Leslie - Community Manager
Hello Leslie,
i have generate a new Access_Token and a new Refresh_Token.
Jun 05 16:43:33 wetterstation weewxd.py[4769]: netatmo: netatmo-client: failed attempt 1 of 5 to get data: HTTP Error 400:
Jun 05 16:43:33 wetterstation weewxd.py[4769]: netatmo: netatmo-client: waiting 10 seconds before retry
Jun 05 16:43:43 wetterstation weewxd.py[4769]: netatmo: netatmo-client: url: https://api.netatmo.com/oauth2/token data: b'grant_type=refresh_token&refresh_token=******&client_id=******&client_secret=******' hdr: {'Content-Type': 'application/x-www-form-urlencoded;charset=utf-8'}
Jun 05 16:43:43 wetterstation weewxd.py[4769]: netatmo: netatmo-client: failed attempt 2 of 5 to get data: HTTP Error 400:
I don't know any solution. Thank you
I wrote a comment to another user on GitHub having the same problem here. Basically, Netatmo's API change has broken the weewx-netatmo driver until we can figure out a way to safely store the new "refresh_token" from the API between restarts. Storing it in memory is easy, but that will only work provided the weewx service is not restarted or the host/container rebooted.
For now, the ONLY fix is to go to dev.netatmo.com and generate a new refresh token, replace the old one in the weewx config file, then restart weewx. HOWEVER, after a restart, the same problem will occur.
Thank you james,
this is exactly the same problem I am having. Is there anyone who maintains the Netatmao driver?
thank you for your response.
uweheidrich - I have done some work on that driver previously with some of the other devs. However, having to store the refresh token between restarts is not something that was ever anticipated and there are no native mechanisms for doing so in weewx. Adding this will present some unique challenges.
Of course, Netatmo could also provide an API that isn’t so brain-dead in the name of “security”. Obviously there is some potentially sensitive information returned (like station lat/long, and other identifiers) but I don’t see why they can’t provide a more simplistic API call that returns anonymised/sanitised weather information information without all this unnecessary complexity for that task.
Fully agree with James' comment!
I'm waiting exhilarated for the fullmoon_token that would have to be retrieved every 28 days ^^
Joke aside, if the Netatmo dev team don't understand that the principle of an API is to be stateless and automatable (without human action after a reboot for example...) they might offer at least a way to push or pull my own data and access full scope actions from my local network - where the damn holy security will be under my full responsibility.
Also @DevTeam,
> 400 Bad Request "The request could not be understood by the server due to malformed syntax"
Last one was Authentication update (second notice) 1st of march:
BTL. I had to spent 2 hours making a dirty hack with memcache ttl for access_token and filesystem caching for refresh_token over https://github.com/Netatmo/Netatmo-API-PHP and i'm currently not sure it'll work in any non standard case
I forgot a technical point, to avoid my dirty TTL countdown on my side hoping you & I are NTP sync...
How can I check if access_token still valid (without disabling my cached refresh token)?
I think you miss some steps after the fourth in https://dev.netatmo.com/apidocumentation/oauth with a "isValid" method for access_token to know if I had to renew it or not.
Hello,
I'll forward your remarks to the concerned teams
The access_token is always valid for 3 hours. So, once your /token request launched you'll know that it will expire in 10800 seconds
Have a good day,
Leslie - Community Manager
Hallo, I wish I could read the data from my weather station directly from my network like I used to. Sniff. Please forward this request to the relevant team.
Sincelery Uwe
@james Thanks for the work on this.
@Leslie Following and awaiting an update \ fix.
Regards,
Gavin
FWIW - this was the last straw for me. I’ll run my Netatmo station until it dies, but I’ve purchased a new station from a supplier with sensible and stable API who understands the reason for such services (automation, integration etc). So, even if Netatmo fix their API or Weewx finds a way to work with this current brain-dead API, I’ve already jumped ship. The failure of my systems to retrieve the atmospheric information I need has highlighted how much I actually rely on it, and I can’t trust Netatmo to maintain sensible access to my data ¯\_(ツ)_/¯
@james thanks for that, out of interest what station have you gone for?
@anderson.gavin - I went with an Ambient Weather Ws-2000 setup. They are user-serviceable, robust, have a range of additional sensors (lightning detection, soil moisture etc) and can be upgraded too. I’ll probably replace the vane-style anemometer with the ultrasonic alternative when it inevitably wears out. Most importantly their API is widely deployed with libraries for Python, Go, JavaScript and lots of others too. Solid system and reasonably priced.
Please sign in to leave a comment.