Netatmo away present mode not working since last update

Configuration
1

Has any thing changed in the Netatmo integration? Since last update, the preset mode “away” no longer works in my system, despite it is listed in the attribute states:

hvac_modes:
  - auto
  - heat
  - 'off'
min_temp: 7
max_temp: 30
target_temp_step: 0.5
preset_modes:
  - away
  - boost
  - Frost Guard
  - Schedule
current_temperature: 21.8
temperature: 19.5
hvac_action: idle
preset_mode: Schedule
attribution: Data provided by Netatmo
selected_schedule: Invierno
friendly_name: Termostato
supported_features: 17

Trying to set such preset mode issues the following warning:

Logger: homeassistant.helpers.script.websocket_api_script
Source: components/netatmo/climate.py:318
First occurred: 19:13:38 (6 occurrences)
Last logged: 20:09:00

websocket_api script: Error executing script. Unexpected error for call_service at pos 1: 400 - Bad request - Invalid mode (21) when accessing 'https://api.netatmo.com/api/setroomthermpoint'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 451, in _async_step
    await getattr(self, handler)()
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 684, in _async_call_service_step
    await service_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 1738, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1775, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 207, in handle_service
    await service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 678, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 931, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 715, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/netatmo/climate.py", line 318, in async_set_preset_mode
    await self._room.async_therm_set(PRESET_MAP_NETATMO[preset_mode])
  File "/usr/local/lib/python3.10/site-packages/pyatmo/room.py", line 111, in async_therm_set
    await self._async_set_thermpoint(mode, temp, end_time)
  File "/usr/local/lib/python3.10/site-packages/pyatmo/room.py", line 165, in _async_set_thermpoint
    await self.home.auth.async_post_api_request(
  File "/usr/local/lib/python3.10/site-packages/pyatmo/auth.py", line 351, in async_post_api_request
    return await self.async_post_request(
  File "/usr/local/lib/python3.10/site-packages/pyatmo/auth.py", line 389, in async_post_request
    raise ApiError(
pyatmo.exceptions.ApiError: 400 - Bad request - Invalid mode (21) when accessing 'https://api.netatmo.com/api/setroomthermpoint'

However, if I change “away” to “Away” (first letter to uppercase), the action executes fine and no error is issued, although the Away mode is not actually set in the thermostat/valves (neither the climate entity state and the Netatmo App states are changed). Other commands still run fine. It looks like the way either the API or integration handle this specific preset mode has changed.

Is anyone else having the same problem?

1 Like
2

A lot has changed in 2022.10. I’ll take a look ASAP.

3 Likes
3

yes same for me…

For the moment I catched the error and sent a turn_off :wink:

4

Yes. I’ve done the same: Changed actions from setting away preset mode to turning them off. I’d rather to be able to use the “away” option though, because it sets a minimum temperature for anti-icing purposes. I know I could just set a low temperature value instead, but that is not an optimal approach from my point of view.

5

New to Homeassistant and just trying to set up geofencing with my Netatmo thermostat (used to use life360 with IFTTT). Also having the same issue, it appears the only preset that actually works is “boost” which sets the thermostat to Max. “away” and “Frost Guard” both error, “Schedule” runs without error but the thermostat does not revert to the programmed schedule.

6

We need to let @cgtobi the time to fix it…
As said, there’s a lot in 2022.10…

1 Like
7

Same error, winter is coming…

For now I have solved using Node-red with node-red-contrib-netatmo

8

Update: with node red it works “regularly”, the netatmo screen updates immediately, while home assistant updates after about 3-5 minutes

9

Use a dev account and webhooks for immediate feedback.

10

I noticed that @cgtobi did get a lovely little PR aproved 4 days ago that (to my limited knowledge) seems to be able to fix the problem people in this thread is experiencing :slight_smile:

It’s in the dev branch currently, so there is high hopes that it’s going to be part of a not-so-distant update.

Here’s the PR I’m talking about:
Fix error when setting Netatmo climate preset by cgtobi · Pull Request #80700 · home-assistant/core (github.com)

2 Likes
11

Hello,

I’m new into the Hass world and noticed this:

I’m able to call climate.set_preset_mode to away. When checking into Netatmo app, it’s taken into account but in hass, it keep saying it’s in scheduled mode, for instance within a climate card.

Anyone noticed this too? Am I doing something wrong ?

Thanks

12

For me it takes quite a while before HA changes to away. Can be several minutes.

13

My setup refreshes status almost instantly. If you don’t open necessary ports for the Netatmo webhooks to work fine, changes can take several minutes to be refreshed across both platforms (Netatmo servers and your Home Assistant instance). Have a look the last section of the following page:

14

Interesting. Thanks for the info. Not sure, though, if I want to use port 443 for that.

I’ll think about it. But good to know.

15

I remember to see somewhere that you can also use 80, 88 and 9443 ports. That’s where your HA instance should run for this to work. Other options are:

  • Redirect such WAN port to a different LAN port (the one where HA is running).
  • Use a reverse proxy (this is actually the option I use).
16

Hey, thanks for your answer, it must indeed be my issue.
I’m trying to fix it but struggling a bit since I don’t have much knowledge in networks.

What I had is :

  • HA with static IP as 192.168.0.x
  • duckdns setup to redirect to my public IP (+ addon on HA)
  • in my modem : WAN and LAN ports 8123 to 192.168.0.x
  • Home Assistant URL in setttings => config/network : https://mydomain.duckdns.org:8123

Now following what you mentioned I have added :

In the logs I see this (I thing it was already the case before)
Error during webhook registration - 400 - Bad request - Allowed ports for webhooks are 80, 88, 443 and 9443. (21) when accessing ‘https://api.netatmo.com/api/addwebhook’

Do you see anything I did wrong or missed with my new settings?
Thanks for the help

17

Do you have a valid ssl certificate and a reverse proxy for the url installed.

If not I guess that using 443 will result in an error because the ssl check fails.

18

I tried now with my setup but with no success. I forwarded 9443 to 9443 or 443. I also tried 443 to 443 and 9443 and 88 to 88. I always get the same error message:

Error during webhook registration - 400 - Bad request - Allowed ports for webhooks are 80, 88, 443 and 9443. (21) when accessing ‘https://api.netatmo.com/api/addwebhook’

My SSL proxy is working over my own URL. For normal access I use the external port 8124 and forward it internally to the HA IP and port 443.

19

EDIT: I fixed this by setting WAN ports 443 to LAN port 8123. Now I can access it without setting ports.

Netatmo still takes times to update data. And netatmo_event seems to not be fired.
Any idea where it could come from?

20

Weird. This config should work. Any logs warning since you changed the config? Are you using an SSL certificate? If not, perhaps you should try with HTTP instead of HTTPS and also ports 80 or 88.