Integrations can't reach internet since 2025.3.3

[fysmd (Ian Rhodes)]

since I upgraded to 2025.3.3 network (internet) comms for integrations fail after some runtime.

2025-03-16 23:22:47.405 ERROR (MainThread) [homeassistant.components.flux_led.coordinator] Error fetching 192.168.0.214 data: [Errno 113] Connect call failed ('192.168.0.214', 5577)
2025-03-17 00:29:33.525 ERROR (MainThread) [homeassistant.components.flux_led.coordinator] Error fetching 192.168.0.109 data: 192.168.0.109: device stopped responding after 4 requests to send state
2025-03-17 01:05:54.417 ERROR (MainThread) [async_upnp_client.ssdp] Received error: [Errno 99] Address not available, transport: <_SelectorDatagramTransport fd=270 read=polling write=<idle, bufsize=0>>, socket: <asyncio.TransportSocket fd=270, family=10, type=2, proto=0, laddr=('::', 46102, 0, 0)>
2025-03-17 01:08:22.201 ERROR (MainThread) [homeassistant.components.hassio.handler] Timeout on /host/info request
2025-03-17 01:09:52.102 ERROR (influxdb) [homeassistant.components.influxdb] Cannot connect to InfluxDB due to '{"error":"timeout"}'. Please check that the provided connection details (host, port, etc.) are correct and that your InfluxDB server is running and accessible.
2025-03-17 01:10:25.365 ERROR (MainThread) [homeassistant.components.fully_kiosk] Timeout fetching 192.168.0.119 data
2025-03-17 01:10:25.448 ERROR (MainThread) [custom_components.tesla_custom] Timeout fetching tesla_custom data
2025-03-17 01:10:25.493 ERROR (influxdb) [homeassistant.components.influxdb] Resumed, lost 24 events.
2025-03-17 01:10:25.783 ERROR (MainThread) [custom_components.ohme.coordinator] Error fetching Ohme Account Info data: Error communicating with API
2025-03-17 01:10:25.967 ERROR (MainThread) [custom_components.ohme.coordinator] Error fetching Ohme Advanced Settings data: Error communicating with API
2025-03-17 01:10:25.973 ERROR (MainThread) [custom_components.ohme.coordinator] Error fetching Ohme Charge Sessions data: Error communicating with API
2025-03-17 01:10:26.087 ERROR (MainThread) [custom_components.tesla_custom] Timeout fetching tesla_custom data
2025-03-17 01:10:28.800 ERROR (MainThread) [homeassistant] Error doing job: Task exception was never retrieved (None)
Traceback (most recent call last):

After this my log is full of many aiohhtp failures from a number of Internet based integrations.

I can still reach the front end on the network, locally (LAN) and via both Nabucassa and a Cloudflare tunnel but many integrations fail.

One example of data from an affected integration (EVOHome)

You can see this also happened yesterday and a full reboot did resolve it for many hours.

it does look like it’s related to updating to 2025.3.3 :

[belastingvormulier (William)]

Are you running in docker ? or are you running HA differently ?

Did you do any investigation as to why outbound connections are not running?
(ping… dig, that kind of debugging?)

Please supply more info!

[WallyR (Wally)]

Also restart your router.
From HAs point of view there is no real difference between a local and an internet site.
It is most likely your router that is the issue.
The fact that a restart if HA had an effect is that it made it possible for the router to clear some of its stored states for connections.

[fysmd (Ian Rhodes)]

Thanks all

I run the OVA image on Unraid so yes it’s docker inside but not my own build.
The host machine (Unraid) hosts other services such as Teslamate and those services remain connected and fully operational.

Soft restarting HA does not address the issue, a complete VM Reboot does fix it.

I do not have a “router” as such, at least not in the way I think you’re refering.
I run a pfsense FW and have my cable box in “modem” mode.

ISP link and DNS servers are monitored and neither have outages reported.

When HA is in this state I can still reach it via both Nabucassa and Cloudflare tunnels so surely only a part of it is struggling with connectvitiy.

If I run the “terminal” plug in, that container can alway resolve and can reach the internet.
I’m not familiar with the internal docker architecture but if this fault recurs which container should I grab a shell on to test?

[sjefen]

Nice to see someone else reporting this. I thought maybe i had something wrong in my setup all of a sudden. I’m also seeing this since 2025.3.0…

I’m running HA docker container, on a ubuntu OS server. I have done so for several years, but as of 2025.3.x i get timeout issues for cloud services. This includes loosing nabu casa cloud access also for me. I’ve tried all common network tools to throubleshoot this, but I can’t see anything obvious wrong from those diagnoses. Pinging nabu casa is no use, seems like they don’t allow pinging their server. But " nc -vz eu-central-1-3.ui.nabu.casa 443" returned “eu-central-1-3.ui.nabu.casa (3.125.89.246:443) open” when issues were present. Also all services listed under “settings - system - repairs - system information” were all listed as timeout errors. That’s: HACS, AccuWeather, Hass Cloud, Easee charger, spotify…

Reverting to images pre- 2025.3.x are working fine.

[WallyR (Wally)]

@fysmd

I do not have a “router” as such, at least not in the way I think you’re refering.

A router is a device setting on two or more networks and move datat between them.
Unless you have public IP addresses on all your internal devices, then you have a router in the traditional sense.

[fysmd (Ian Rhodes)]

I did describe part of my solution: my L3 device is a PFSense Firewall connecting to my ISP through their device which is no longer a “router”.
I am trying to explain that I am not using poor firewall software provided by my ISP which needs restarting frequently to be reliable - and that which I am using is working properly, is robust and was online throughout the issue I described.

We’re not here to deliver an amusing (to some) display of network pedantry so I’ll leave it.

[fysmd (Ian Rhodes)]

both my tunnels worked properly throughout the issue so it’s not that the guest (or host) machine lost reachability in any total way. I suspect the docker networking within HA is misbehaving but I dont have sufficient understanding of that architecture to look more deeply into it without some assistance.
For example, I do not know why the cloudflare container continues to be reliable when others are not?

I just updated the OS so now running:

• Core 2025.3.3
• Supervisor. 2025.03.3
• Operating System 15.0
• Frontend. 20250306.0

Let’s see how this combo fares

[WallyR (Wally)]

@fysmd

I am trying to explain that I am not using poor firewall software provided by my ISP which needs restarting frequently to be reliable - and that which I am using is working properly, is robust and was online throughout the issue I described.

What specs do you have on that pfsense firewall?
A common mistake is going to low on ram and then actually hit OOM, which means no new connections can be made. This will typically only last a few minutes until some other connection states are cleared, but it might then occur again soon there after.

[belastingvormulier (William)]

Right, So I am on 2025.3.3 in docker on debian and have 0 issues with the 1 cloud connected service that I have.

But on your opening post it also seems to have trouble connecting to local ip adresses ?
(might be startup problems that cleared after a while?)

I am curious though.

Soft restarting HA does not address the issue, a complete VM Reboot does fix it.

1: how did you upgrade
2: did you restart the vm after upgrading?
3: did the problems start immediately ?

I probably wont be giving you the fix for this. But it does seem somewhat host os related.
Perhaps the upgrade changed some firewalld rules or something but as you rebooted most of the usefull logs are probably gone. (dmesg, syslog, route table that kind of thing)

[WallyR (Wally)]

@belastingvormulier

but as you rebooted most of the usefull logs are probably gone. (dmesg, syslog, route table that kind of thing)

The logs from the previous run in HA is copied to homeassistant.log.1 in the config folder.

[fysmd (Ian Rhodes)]

@belastingvormulier

1: how did you upgrade
2: did you restart the vm after upgrading?
3: did the problems start immediately ?

I press the upgrade buttons in HA when they’re offered. I dont do anything special.

I don’t then go any specifically restart the VM, that tends to only happen then the OS gets a release too, again I accept those updates when offered (did one yesterday!)

Well, not immediately, the first issue began at approx 1am while the update was done interactively while I was awake!.

I did also spot the local services not responding but I dont have any other logs to show what / why etc. Some of them are LED drivers which are powered down often so I tend to ignore those.

Interestingly though logs do show that HA was unable to communicate with my plex server which is also hosted on the same machine (Unraid hosted docker in that case, while HA is running HAOS in a VM). Those packets never left the (physcial) nic.

[fysmd (Ian Rhodes)]

taken while all services are active and hauling a gig through him:

[WallyR (Wally)]

@fysmd

the OS gets a release too, again I accept those updates when offered (did one yesterday!)

I just noticed you wrote that you run HAOS in about a day back, but I think you got us a bit confused when you wrote that you run docker earlier.
HAOS v15 seems to have issues. With RPis it seems to hit the USB drivers and with other installations it seems to have the effect of a higher CPU and/or RAM usage.
I do not know how it affects unraid though, but maybe the netcard is wired in a way so it is affected too.

[fysmd (Ian Rhodes)]

OK happened again, sorry for all the images I don’t have proper shell access from here.

Looking at the the VM in HAOS:

All while the integrations continue to fail to connect.
Maybe i dont get the network stack inside HA but I think I’ve shown that the homeassistant container can in fact still communicate while some parts of it still can’t?

I have captured the log files and now rebooting

[GSzabados (Gábor Szabados)]

@fysmd, do you have Landroid Cloud? If yes, then disable it.

[TheManoeuvre]

I’m having a similar issue, running HAOS bare metal on a dell Optiplex.
Many previously fine integrations are now failing to load, connection to the machine seem sluggish as does any navigation.

Error from the logs for solar forecast

Logger: metno
Source: components/met/coordinator.py:81
First occurred: 9:52:29 PM (40 occurrences)
Last logged: 10:50:04 PM

Access to https://aa015h6buqvih86i1.api.met.no/weatherapi/locationforecast/2.0/complete returned error ‘ClientConnectorDNSError’

[GSzabados (Gábor Szabados)]

@TheManoeuvre

sluggish as does any navigation.

Any chance that you have Landroid Cloud?

Otherwise try to start HA in fail safe mode, which disables all the custom components. Then go and disable them manually, and start HA again. Once up and running, hopefully without any sluggish behaviour both in fail safe and normal without the integration, start to enable the integrations one by one to see which one is holding it back.

You can enter the homeassistant container with

docker exec -it homeassistant /bin/bash

and use top to see how the processor memory usage changes once you enable the integrations.

I assume you have something which have been updated recently.

[fysmd (Ian Rhodes)]

I do not run Landroid Cloud.

[GSzabados (Gábor Szabados)]

@fysmd

not run Landroid

Then try my suggestions above to figure out what causes the issue.

I had during the past months two custom integrations playing this with me, last Landroid, before Stateful Scenes.

A good start to rule out the custom integrations is to start HA in fail safe mode.