Netatmo values updating like once per 1-2 hours

Not sure, if it some todays Netatmo API problem, but all Weatherstation values are irregularly updated like once per 1-2 hours. When I reload the integration or HA restart, fresh values are updated. Havent found anything in logs except " Webhook not registered - https and port 443 is required to register the webhook" which is present since my HA installation.

I have no connectivitry issues, all other cloud-based services are updating without any issues.

I attach history screenshot of one of my Netatmo sensors updated 35 minutes ago. When I check in Netatmo app, data refreshes each 10 minutes.

  • 2025.9.3
  • Supervisor2025.09.0
  • Operating System16.2

1 Like

Netatmo has complex cloud polling code to minimize the number of api calls

It looks like it’s minimum polling time is 10 minutes between each update.

I.e. this is expected behavior. If you don’t care about update calls, make an automation that calls homeassistant.update_entity at whatever frequency you desire. Just understand that there may be repercussions (from netatmo) if you do this.

OK, so this is a standard behaviour of Netatmo HA integration, that values are updated once per 1-2 hours? I was thinking, if I have something broken inside my HA installation / configuration. I think yesterday or previous day all Netatmo values were updated like each 15 minutes…

So for now I have not received fresh data for 3 hours, this could not be normal, when I reloaded the integration, it updated immediatelly. I dont think this is normal behaviour, Netatmo API is working, I fetch the data also through NodeRed for other projects and it works.

1 Like

Understood, but when I reload integration manually it fetches data correctly for some time - it refreshes automatically (in minutes) - that is the reason, why I don’t understand it. This is also expected?

Anyway - Can I use

homeassistant.reload_config_entry

for automating reload of all Netatmo entities, so I don’t need to specify all 59 entities individually?

You don’t need to specify 59 entities. You can just write a template that does it for you. “{{ integration_entities(‘netatmo’) }}”

you can also use the reload config entry service

1 Like

FYI have you seen this? It’s a feature request, but it’s alluding that there were netatmo changes. These changes may be affecting you at the moment.

I can confirm the same issue with hours without any update.

An workaround forcing to reload the entities is working:

1 Like

Yes, I saw that, accepted TC but nothing changed.

Thanks for reporting that, but they close those tickets immediately, I have searched for other ones closed with same comment - it is expected behavior. Than it quite don’t make sense to have weather station integration where values update once per 3 hours :frowning: I have forced reload_config if value does not change for 30 minutes and it seems as suitable workaround for now.

I have had this exact same problem for a while now. And really, this is OK and normal behaviour from HA point of view, really?

Yes, I can confirm this as well.
The problem started around half of August, and is slowly getting worse.
This is a pity, because it makes it impossible to reliably use the Netatmo data as trigger input.
This are some screen grabs from some of my outside temperature sensors showing this effect during the last few weeks:

The blue values are from my Netatmo outside temperature sensor.

There were several other posts about this problem already:

How to setup Netatmo integration using webhooks to speed up device status update response times

Netatmo data acquisition with gaps
Here it is reported that the Netatmo servers are reporting a “too many requests” warning.

So it looks like the problem comes from the Netatmo servers being overloaded, causing slowly increasing blocking periods.

The best solution would be the Netatmo API allowing a higher request rate, so we have to contact Netatmo itself for that.
But may be it would also be possible for the Netatmo Integration owners to modify the integration such that the requests are done less often?
The Netatmo internal data rate has always been rather slow: it is only updated every 5 minutes, also in the Netatmo web interface itself. So it cannot be faster than that anyhow.
As I understand it now, the polling rate in the integration is every 10 minutes now.
May this has to be changed to every 15 minutes?

I am not clear on how the integration is fetching the data now via the Netatmo API: how often does the API have to be contacted? Is this once for every value, or are all values fetched at one cycle?
Us Netatmo users are the owners of the measured data, and so we are always able to download the data from the Netatmo cloud servers in CSV format.
So another option might be the integration to download the required data like every 10 minutes or so in CSV format? Or is this already happening?

What I understood there is API limit / hour, for someone with one station update can happen more often than for someone like me - 59 entities to be updated each refresh (3x indoor module, 1 main module, 1 outside module, 1 rain gauge, 1 wind module), I understand it is probably not HA issue, but I have integrated Netatmo also to Node-RED and I am fetching data each 15 minutes without any issue…

Yes, I am in the same boat, having the exact same setup.

Well, isn’t that an indication that it would be better if the Home Assistant integration would fetch the data every 15 minutes from the Netatmo API instead of the current 10 minutes?

The code appears to be built in a way that all HA users don’t ping the servers at the same time in combination with the polling rate being 10 minutes. This was likely done to minimize API stampeding. I.e. reduces a surge of identical requests to a server at the same time.

The developer reopened it.
Please, write also there to show that I’m not alone :slight_smile:

Same issue on my HA

*

  • Core2025.9.3
  • Supervisor2025.09.0
  • Operating System16.2
    20250903.5

You can also rise your hands there:

2 Likes

Not sure if the author of the Netatmo Integration is available anymore, so there is an workaround available here while the pull request is waiting.