core: Netatmo entities unavailable after restart

The problem

After the upgrade to core-2021.9.2 I noticed that Netatmo entities were unavailable. Removing the integration and re-adding solves the problem, but after a restart of HA the entities are unavailable again.

I use authentication via configuration.yaml instead of cloud since I have a Netatmo Presence

What is version of Home Assistant Core has the issue?

core-2021.9.2

What was the last working version of Home Assistant Core?

core-2021.9.0 - I think. Might have been core-2021.8.8

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Netatmo

Link to integration documentation on our website

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/netatmo/__init__.py", line 198, in register_webhook
    await hass.data[DOMAIN][entry.entry_id][AUTH].async_addwebhook(webhook_url)
  File "/usr/local/lib/python3.9/site-packages/pyatmo/auth.py", line 351, in async_addwebhook
    resp = await self.async_post_request(WEBHOOK_URL_ADD, {"url": webhook_url})
  File "/usr/local/lib/python3.9/site-packages/pyatmo/auth.py", line 306, in async_post_request
    async with self.websession.post(

Additional information

No response

About this issue

  • Original URL
  • State: closed
  • Created 3 years ago
  • Comments: 44 (22 by maintainers)

Most upvoted comments

Thanks to the support of @Mk4242 and others we were able to close in on this. It happens when the Netatmo relay becomes unavailable. Subsequently the thermostats and valves attached to it will be rendered unavailable and wont be able to recover unless you reload the integration or restart HA. I am working on a fix but right know I don’t have quick solution that wont be a regression in other parts.

Until the fix is available, one can also identify why relays get kicked out of the WiFi network and act accordingly, especially when it occurs at recurring times, in my case disabling the WiFi AI feature on one specific access point in my UniFi network greatly improved the availability of the Netatmo Relays.

the issue occured again this morning around the same time for me - showing as unavailable from 03:03:25

2021-10-08 02:45:30 DEBUG (MainThread) [homeassistant.components.netatmo.data_handler] 
[...]
2021-10-08 02:51:30 DEBUG (MainThread) [homeassistant.components.netatmo.data_handler] 
2021-10-08 03:03:25 DEBUG (MainThread) [homeassistant.components.netatmo.data_handler] No device found, errors in response
2021-10-08 03:04:25 WARNING (MainThread) [homeassistant.components.media_player] Updating androidtv media_player took longer than the scheduled update interval 0:00:10
[...]

I’ll try to replicate this on the weekend as I won’t be near a computer before that. If one of you could join me on discord to dissect this issue should I not be able to reproduce it in my dev environment it would be of great value.

Just joined the beta-channel and will report back when it is failing again.

Thanks for your help so far!

This depends on what type of installation you’ve deployed. In the case of core you can simply pip install -i https://test.pypi.org/simple/ pyatmo==6.0.1.dev25 and start HA with hass --skip-pip. For container based installation we’d probably need to put together a custom component for ease of testing.

I’m also experiencing issues with the netatmo integration and climate components recently, after a while, occurs usually at least once a day, log file shows: 2021-10-03 01:08:24 DEBUG (MainThread) [homeassistant.components.netatmo.data_handler] No device found, errors in response

Then climate entities become unavailable and system does not recover unless restarted.
Also using netatmo integration for weather, weather station sensors not affected by the issue. Running the docker version of HomeAssistant, 2021.9.7.

I upgraded pyatmo to 6.0.1.dev25 and moved netatmo to a custom component to ease troubleshooting, will report - if any - findings here.

@cgtobi Running for 9 days now without any problems. Seems to work great!

Thank you!

@cgtobi Thanks a lot for the custom component, on my installation I can confirm that with it the entities automatically restore after unavailability.

However I noticed a change in behaviour: when manually setting a valve temperature, thus overriding the scheduled target temp, the valve target temperature gets reverted to the scheduled temperature upon next synchronisation (every 5 minutes), this shouldn’t happen, manual boost default is 2 hours and controlled through Netatmo settings. This occurs whatever the source of the manual boost is: in Netatmo app, in HomeAssistant, or changing it on the valve itself.

That would be helpful is someone else could confirm the above.

Custom component is now up and running. Had the problem this night around 1:30, but no suspicious entries in the routers log. (still the standard component of course)

Will report back then.

Hi, I’ve put together a custom component with the latest evolution of the underlying library and the integration code. It is easily installable via HACS.

https://github.com/cgtobi/netatmo_custom

Be aware, this is not polished code and still throws a few errors related to a new feature but as far as I can tell it’s working and fixes the issue. Feel free to give it a try. Any feedback is highly valuable to me.

This is not a permanent fix but only an early test.

@cgtobi you are correct I appear to have opened a duplicate of this here https://github.com/home-assistant/core/issues/57050

based on last few days I am observing a similar pattern (although I am GMT) around 03:05 as per history component screenshots. I have enabled debug logging on homeassistant.components.netatmo unfortunately I forgot to capture this before I rebooted this morning for an unrelated issue and appear to have lost the logs. I will post these next time it happens

Screenshot 2021-10-05 at 15 12 21 Screenshot 2021-10-05 at 15 12 08

the only way I have found to recover this is a reboot

@cgtobi so far nothing to report, sensors were again unavailable this morning but the logs didn’t contain the Server response: message I was expecting. Seeing you merged the debug logs into pyatmo 6.1.0 I bumped the dependency to this version this morning. Further looking at the time patterns I see the sensors get unavailable every night around 3:10 +/- 15 minutes (1:10 GMT).

Just FYI, since my last restart (and setting the component logger to debug) I haven’t experienced the problem. No idea why. In case it fails again I will provide the logs.

Here or the forums (PM) would be just as fine.