met.no... returned error 'ClientConnectorError'

[busettif]

The problem

Met.no become constantly unavailable since this week.

What version of Home Assistant Core has the issue?

core-2022.5.2

What was the last working version of Home Assistant Core?

Last version from last week

What type of installation are you running?

Home Assistant OS

Integration causing the issue

met.no weatherapi

Link to integration documentation on our website

https://www.home-assistant.io/integrations/met

Diagnostics information

Logger: metno Source: /usr/local/lib/python3.9/site-packages/metno/init.py:107 First occurred: 7 mai 2022, 21:07:26 (15 occurrences) Last logged: 09:49:52

Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error 'ClientConnectorError'

Logger: homeassistant.components.met Source: helpers/update_coordinator.py:223 Integration: Meteorologisk institutt (Met.no) (documentation, issues) First occurred: 7 mai 2022, 22:11:35 (3 occurrences) Last logged: 01:20:13

Error fetching met data: Update failed:

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[probot-home-assistant[bot]]

met documentation met source _{^{(message by IssueLinks)}}

[probot-home-assistant[bot]]

Hey there @danielhiversen, @thimic, mind taking a look at this issue as it has been labeled with an integration (met) you are listed as a code owner for? Thanks! _{^{(message by CodeOwnersMention)}}

[TheRoarman]

Hi, Yes, I have also been having the same problem for the last week. But there may be another problem on my side because this last week my home assistant has been becoming unresponsive after 24 hours. Its since i've done upgrades to Home assistant and the MQTT components.

It starts with the MET error and then eventually works its way to a point where I start getting write errors on the system. So I need to debug why. A reboot of the host solves the problem for a few hours. All my memory / swap / processor temp are all fine on the PI4.

[busettif]

This began on 4th May for me but I don't remember which change occurred this day. When I restart the integration or whole home assistant, it works again for some minutes.

[dejan2101]

Hi, same here. It started on 4th of May, after system/integration reset it works for about an hour and then becomes unavailable.

Logger: metno Source: /usr/local/lib/python3.9/site-packages/metno/init.py:107 First occurred: 10:45:36 (8 occurrences) Last logged: 16:16:51

Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error 'ClientConnectorError'

[busettif]

Hi @Danielhiversen @thimic do you have any idea how to solve that? Thx

[alej908]

I'm having this issue as well with metno as well as NWS, Accuweather, and open weather maps. They will all become unavailable. The logs will show a connection error, but only with the weather components. Everything else works great

[FalconUK]

Similar issues, the integration has recently been unavailable often. Reloading the integration restores operation, but only for a short period of time. I saw the isse on both 2022.4 and also now with 2022.5.

[busettif]

I found a temporary work-around until the issue will be fixed. Created an automation "A" to reload met.no each time it becomes unavailable. But this caused an other problem, firing on each reload an other automation "B" based on a numeric_state of met.no. Because the numeric_state state is reseted on reload. So, I was forced to create a new condition on my automation "B" to abort the automation if it was fired because of the reload of met.no I don't like this way but until it's not solved... Looking for other integrations as well...

[samueljesus-os]

I'm having the exact same issues, since the last update. Also, I believe I'm having the same (or at least very similar) problem on another Weather integration I was testing when this one started to fail.

Considering I have a friend that has a very similar HA config as I have and he is not facing this problem, I was trying to understand the difference between our installations, I noticed that the "only difference" was that I'm using duckdns and he is using a different dns.

What are the odds that you guys are also using duckdns, and somehow that is related to the problem ?!?

[FalconUK]

I'm not using duckdns. I don't have any dDNS in place myself, I use Nabu Casa for remote access.

[alej908]

I'm using ad-guard for adblocking and DNS. I'll turn it off for a while and see if there is a difference, or switch to the ISP DNS and see if there is any difference.

[busettif]

I'm using duckdns

[dpgh947]

I actually set up duckdns this week, but I had this problem before that (and still do). This might be nothing, but I took the url in the error message in the logs, put it in the browser, and I get this:

Has the api perhaps changed?

[alej908]

I switched away from AdGuard, tried and still have same issue.

[jrial]

Getting the same behaviour and same error message. Also using duckdns, but I don't see how that could be related.

DuckDNS and similar services are there to ensure your home installation can be reached from the outside via an easy to remember name, rather than the ever-changing IP address your ISP allocates you. In other words: it facilitates incoming connections from the outside. But it doesn't impact the way outgoing connections happen, e.g. the one to met.no that errors out in this case.

[trizmark]

Just to add some more detail: I'm having the same issue on the system which is running HA OS. My other installation (same version, same network), but HA is running in docker on top of Debian Buster has no issues with this integration.

[alej908]

I'm running HA Supervised on top of Debian Bullseye and have this issue with all weather integrations.

[fawadrashid]

I don't use DuckDNS but I do use AdGuard. The weather integration was working fine till last month but now I am getting the same issue as reported in this issue board. Unless I restart the Met.no weather integration the weather card stops displaying weather and temperature. The logs show Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error 'ClientConnectorError

I am not sure if there is anything at my end that i can do to fix the issue. I am running HassOS 8.0

[trizmark]

This issue impact every internet-facing part of HA. I have gaps in my CO2 signal data on HA OS, while the standalone Docker instance of HA has no issues whatsoever.

[joaldes]

I don't use DuckDNS but I do use AdGuard. The weather integration was working fine till last month but now I am getting the same issue as reported in this issue board. Unless I restart the Met.no weather integration the weather card stops displaying weather and temperature. The logs show Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error 'ClientConnectorError

I am not sure if there is anything at my end that i can do to fix the issue. I am running HassOS 8.0

If you stop using AdGuard, does it then connect? I've been using AdGuard for a while and it only started giving me issues. When I use the IP addresses provided by Adguard in my router DNS settings, I start getting connection errors for all the https services: my august lock, met.no, nabu casa, etc.

Moving away from Adguard restored all the connections. I have not been able to figure out why.

[trizmark]

On my HA OS instance I have my router statically configured as the DNS server. This instance is experiencing network connectivity issues. On my dockerised instance the DNS is set up to point to my Pi-hole DNS. This instance is working fine.

The HA OS instance has clear access to my ISP's DNS, so I don't believe that this issue has anything to do with DNS. Interesting to see that my weather integration becomes unavailable roughly an hour after I reload it (give or take a few minutes). CO2 signal seems to recover, but data is intermittent.

I have a spare RPi3, so might install an older OS to figure out when this thing broke.

[jrial]

Moving away from Adguard restored all the connections. I have not been able to figure out why.

Sounds like you're having a different issue than the rest of us, since most of us don't have any other connectivity issues, most of us aren't running AdGuard, and the one person running AdGuard already stated that disabling it didn't resolve his issue. For you, it seems it does resolve the issue. So presumably, your problem lies with AdGuard, not HomeAssistant.

Best verify your configuration. If you haven't mistyped anything, check with AdGuard's support team.

This might be nothing, but I took the url in the error message in the logs, put it in the browser, and I get this:

Has the api perhaps changed?

No, you're getting that error because you're not passing any parameters. I'm pretty certain the integration slaps the correct parameters on the end, because the met.no API has always required your coordinates to give you a forecast for your location. In other words: the URL in the logs is not the actual URL that's being called. It'll be more something along the lines of https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete/?lat=59.93&lon=10.72&altitude=90

I'm running HA Supervised on top of Debian Bullseye and have this issue with all weather integrations.

This issue impact every internet-facing part of HA. I have gaps in my CO2 signal data on HA OS, while the standalone Docker instance of HA has no issues whatsoever.

For me it's not affecting all Internet-facing parts of HA. My CO2 signal works fine. However, my solar forecast also fails. That seems to be unrelated though, as I've checked the host in question and it's using a self-signed certificate. Most libraries, including Python's "requests" library, refuse to connect to hosts with invalid or self-signed certificates for security reasons, unless explicitly instructed. So yeah, probably unrelated and just a coincidence.

[trizmark]

For me it's not affecting all Internet-facing parts of HA.

OK, I may have jumped into conclusions based on my n=2 observation. Having looked at the logs, the CO2 signal issue is different: Error requesting co2signal data: HTTPSConnectionPool(host='api.co2signal.com', port=443): Max retries exceeded with url: /v1/latest?lon=-0.9985710477828981&lat=51.77159332299496 (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f7d9b4250>: Failed to establish a new connection: [Errno 101] Network unreachable'))

I have added a few internet facing integrations (as I was in the process of migrating from dockerised to HA OS), so let's see how they behave.

[trizmark]

While the Tado integration doesn't mark entities as 'Unavailable', the logs on HA OS reveal connection issues.

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/urllib3/connection.py", line 174, in _new_conn
    conn = connection.create_connection(
  File "/usr/local/lib/python3.9/site-packages/urllib3/util/connection.py", line 72, in create_connection
    for res in socket.getaddrinfo(host, port, family, socket.SOCK_STREAM):
  File "/usr/local/lib/python3.9/socket.py", line 954, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -2] Name does not resolve

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/urllib3/connectionpool.py", line 703, in urlopen
    httplib_response = self._make_request(
  File "/usr/local/lib/python3.9/site-packages/urllib3/connectionpool.py", line 386, in _make_request
    self._validate_conn(conn)
  File "/usr/local/lib/python3.9/site-packages/urllib3/connectionpool.py", line 1040, in _validate_conn
    conn.connect()
  File "/usr/local/lib/python3.9/site-packages/urllib3/connection.py", line 358, in connect
    self.sock = conn = self._new_conn()
  File "/usr/local/lib/python3.9/site-packages/urllib3/connection.py", line 186, in _new_conn
    raise NewConnectionError(
urllib3.exceptions.NewConnectionError: <urllib3.connection.HTTPSConnection object at 0x7f7ddbf4f0>: Failed to establish a new connection: [Errno -2] Name does not resolve

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/site-packages/requests/adapters.py", line 440, in send
    resp = conn.urlopen(
  File "/usr/local/lib/python3.9/site-packages/urllib3/connectionpool.py", line 785, in urlopen
    retries = retries.increment(
  File "/usr/local/lib/python3.9/site-packages/urllib3/util/retry.py", line 592, in increment
    raise MaxRetryError(_pool, url, error or ResponseError(cause))
urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='my.tado.com', port=443): Max retries exceeded with url: /api/v2/homes/850000/devices (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f7ddbf4f0>: Failed to establish a new connection: [Errno -2] Name does not resolve'))

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/usr/local/lib/python3.9/concurrent/futures/thread.py", line 58, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/src/homeassistant/homeassistant/components/tado/__init__.py", line 83, in <lambda>
    lambda now: tadoconnector.update(),
  File "/usr/src/homeassistant/homeassistant/util/__init__.py", line 192, in wrapper
    result = method(*args, **kwargs)
  File "/usr/src/homeassistant/homeassistant/components/tado/__init__.py", line 176, in update
    self.update_devices()
  File "/usr/src/homeassistant/homeassistant/components/tado/__init__.py", line 186, in update_devices
    devices = self.tado.getDevices()
  File "/usr/local/lib/python3.9/site-packages/PyTado/interface.py", line 170, in getDevices
    data = self._apiCall(cmd)
  File "/usr/local/lib/python3.9/site-packages/PyTado/interface.py", line 81, in _apiCall
    response = self._http_session.request(method, url, timeout=self.timeout,
  File "/usr/local/lib/python3.9/site-packages/requests/sessions.py", line 529, in request
    resp = self.send(prep, **send_kwargs)
  File "/usr/local/lib/python3.9/site-packages/requests/sessions.py", line 645, in send
    r = adapter.send(request, **kwargs)
  File "/usr/local/lib/python3.9/site-packages/requests/adapters.py", line 519, in send
    raise ConnectionError(e, request=request)
requests.exceptions.ConnectionError: HTTPSConnectionPool(host='my.tado.com', port=443): Max retries exceeded with url: /api/v2/homes/850000/devices (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x7f7ddbf4f0>: Failed to establish a new connection: [Errno -2] Name does not resolve'))

Again, the dockerised installation of HA does not have any connectivity issues.

[bencou]

Maybe met.no wants to reduce the number of api call ... I think they are aware of the situation... On my side I disabled the "System options - Enable polling for updates" of the integration and in place i wrote an automation ;

####################### alias: Reload met.no every 1 hour. description: '' trigger:

• platform: time_pattern hours: /1 condition: [] action:
• service: homeassistant.reload_config_entry data: {} target: entity_id: weather.home mode: single #######################

It works ! Both entities (wheather.home and wheater.home_hourly) are updated every hours o'clock.

[trizmark]

Maybe met.no wants to reduce the number of api call

That doesn't explain why there are issues with other internet-facing integrations. Or that my non-supervised HA install (on the same network/switch/etc) has not issues whatsoever.

[bencou]

In my case (HA OS on Windows10 - HyperV) I don't have issues with other internet-facing integrations (Viessmann Vicare, Mobile App, Home connect, Radio browser) but

################################################################################

Reading the FAQ on https://api.met.no/doc/FAQ about the api Locationforecast/2.0, the one called by HA.

Now I'm suddenly getting "403 Forbidden"! Why am I blocked? Newer services like Locationforecast/2.0 have stricter rules and will block instead of throttle if the User-Agent is missing or generic. Again, read the Terms of Service before contacting us.

On the other hand it can also mean you have been found to break the TOS in other ways and have been blacklisted, e.g. by pretending to be another website or client, or

slamming us with too much traffic. In some cases this might be reversed when the problem is fixed, but deliberate breaches of the TOS will result in a permanent ban. #################################################################################

I'm not (no more, too old now...) a developper able to investigate further but this seams to be a recent problem (unfortunately no date in the FAQ) Like you, I'm looking for a clue. Does it help ?

[Joopie88]

I am also having the same problem with home assistant supervised. It gives the error "returned error 'ClientConnectorError'" Tried it also with other weather integrations, they create the same problem of not updating.

[embolon]

Having same problem with home assistant docker version Home Assistant Core 2022.5.3

[lalorg]

The issue still exists in Home Assistant OS 2022.5.5, with Home Assistant OS 8.1 and Supervisor-2022.05.03. It affects met.no OpenWeather, etc. I have used the automation that @bencou has suggested as a work around, and it is working okay so far. None of my other internet facing intergrations have been affected, so it just appears to the be the weather intergrations.

[wzmigrod]

Have exactly same issue, when integration is manually refreshed it shows forecast for some time and then integration becomes unavailable with same errors as described above

[trizmark]

No change with 2022.6.0 - still broken

Source: /usr/local/lib/python3.9/site-packages/metno/__init__.py:107
First occurred: 7:02:39 PM (2 occurrences)
Last logged: 8:00:53 PM

Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error 'ClientConnectorError'```

[drkng]

Still broken on Core 2022.6.5. 'ClientConnectorError'

[trizmark]

Still broken on Core 2022.6.6 on OS 8.2.

Could this have something to do with IPv6? I was trying to set up HACS, when I ran into this problem:

➜  ~ ping raw.githubusercontent.com
PING raw.githubusercontent.com (2606:50c0:8000::154): 56 data bytes
ping: sendto: Network unreachable
➜  ~ ping 185.199.108.133          
PING 185.199.108.133 (185.199.108.133): 56 data bytes
64 bytes from 185.199.108.133: seq=0 ttl=58 time=7.258 ms
64 bytes from 185.199.108.133: seq=1 ttl=58 time=7.509 ms

I have tried disabling IPv6 under system settings, but that does not disable IPv6 all around (eth0 is not IPv6, but other intefaces are using IPv6)

➜  ~ ifconfig
docker0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        inet6 fe80::42:43ff:fecf:44ce  prefixlen 64  scopeid 0x20<link>
        ether 02:42:43:cf:44:ce  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.202  netmask 255.255.255.0  broadcast 192.168.0.255
        ether e4:5f:01:49:ee:43  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

hassio: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.30.32.1  netmask 255.255.254.0  broadcast 172.30.33.255
        inet6 fe80::42:28ff:feb4:6ce8  prefixlen 64  scopeid 0x20<link>
        ether 02:42:28:b4:6c:e8  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[trizmark]

Decided to tinker a bit - I've got a hunch that this is DNS related. So I hopped into hassio-dns container and changed the config (/etc/corefile). Rather than forwarding DNS requests to my ADSL router, I send them to my pi-hole server and look at that: Weather data after and hour and a half! Previously it definitely changed to unavailable within 55-65 minutes (i.e. first refresh).

[dpgh947]

I've been rebooting a lot this morning (fixing something else, nothing to do with this), and I just noticed my weather has stayed available for 90 minutes since the last reboot so far, so I have "survived" a refresh too. So maybe something has been fixed somewhere, or maybe we've just both seen a random glitch that made a refresh work... will continue to monitor

[trizmark]

Well, it's been over 2 hours and it has been fine for 2 refreshes. I have reverted my change to check if it's still broken with the ADSL modem as the DNS server.

[trizmark]

So, with the ADSL modem as the DNS server we're back to 'unavailable' at the first refresh. Worked fine for 2h48mins with pihole as the DNS, now back to where we were. Reverting the DNS config to pihole DNS - let's see.

[dpgh947]

Bizarre. Mine is still working, updated 20 mins ago (rebooted over 4hrs ago). This is the first time it has worked beyond startup for ages. - I wasn't doing anything to do with DNS earlier.

[dpgh947]

Well I have no idea why but after weeks/months of this not working, since 11am this morning when I last rebooted, it is still working at 6pm.

[trizmark]

At 3:05 I have changed the DNS config within the hassio-dns container, restarted coredns within the container and reloaded the met.no integration. No issues for the last 5 hours. The interesting thing is that my other HA installations that are simply on top of docker all have my ADSL modem as DNS and they have no issues. So whatever the hassio-dns container is doing does not play well with my modem (or my ISP's DNS servers).

[trizmark]

Well, there you have it. No issues for the last 15 hours...

[majdaf]

Hi All. Still not resolved: Logger: metno Source: /usr/local/lib/python3.9/site-packages/metno/init.py:107 First occurred: 11:40:25 (1 occurrences) Last logged: 11:40:25 Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error 'ClientConnectorError'

Just upgraded to 6.7 core.

[trizmark]

Ever since I fudged the DNS config within the hassio_dns container, I have no issues whatsoever:

Having said that I am facing other issues with Zigbee and MQTT, so I am abandoning HA OS and going back to the tried tested simple install over docker.

[MiguelDomingues]

I can confirm that changing DNS settings fixes this issue. Almost 24h without issues Via the SSH Terminal add on I've done the following:

ha dns options --servers dns://8.8.8.8
ha dns restart

I've used that DNS, it will probably work with others

[alej908]

Changing the DNS using this method fixed my weather integrations. I wonder if adguard was somehow causing an issue. I'm not sure, but after making the change this morning, everything has worked great all day!

I can confirm that changing DNS settings fixes this issue. Almost 24h without issues Via the SSH Terminal add on I've done the following:

ha dns options --servers dns://8.8.8.8
ha dns restart

I've used that DNS, it will probably work with others

[trizmark]

I doubt that it was adguard. In my case I actually moved the DNS from my ISP to my pi-hole server, which after ad-filtering would push it to Google.

[drkng]

Hello alej908 https://github.com/home-assistant/core/issues/71519#issuecomment-1170278110 it works, thanks

[dpgh947]

I have some more info on this weird weather problem... I reported a few weeks ago that after I had been mucking about with something else nothing to do with this, and rebooting a lot, and without fiddling with DNS either, mine had suddenly started working after not working for a long time. It has worked solidly since then, until today.

This morning, I migrated my install (raspberry Pi) from an SD card, which btw has worked fine for 2 years, to a new SSD. I did a fresh HA install (64 bit) on the new drive, fixed the Pi to boot from SD or USB, booted the new drive, and restored a backup I took this morning. Whole thing took me about 20 minutes start to finish, everything came up working as before, no problems at all. BUT, a few hours later I noticed this weather client connect error was back. AAARRGGH! I then went through everything I did today working out what might have caused this. I even tried setting the DNS explicitly to 8.8.8.8 as others have mentioned, it did not cure the problem. I then realised that in my "tidying up" today, I had also changed Node Red, which I installed a good while ago (possibly during my previous "lots of reboots" session mentioned), to not start at boot, as I had never got around to playing with it and it wasn't doing anything. I have now set that to start again, and Hey Presto, the weather is working again.

I installed duckdns and nginx quite some time ago too to get remote access working with https (which it does). I notice in the logs for Node Red, and SQlite too, that they also say "starting nginx" when they start up. How is this related to the explicit install of nginx that I have done in conjunction with duckdns? Could some strange interaction here be causing this weather problem?

Anyway, my gut feeling at the moment is that (some?) people who get this problem might also have duckdns and nginx running (I have seen this mentioned before), and those who DON'T get the problem also have Node Red running on top of these...??? I can't explain why changing the DNS seems to fix the problem for some, it didn't for me, either today or when I got the problem before.