[SOLVED] Homey Pro becomes network-unreachable ~6h after boot on firmware 13.4.1 (ENETUNREACH from HomeyScript, memory is nowhere near the limit)

Questions & Help
,
1

Since upgrading to firmware 13.4.1, my Homey Pro reliably becomes unreachable (app/web UI) roughly 6 hours after every boot, then stays broken until I reboot it. It happened again this morning after a reboot: fine until ~13:00, broken by ~14:00.

What I’ve ruled out:

  • Not a memory-pressure issue. I log Homey.system.getMemoryInfo() every 10 min. Total usage stayed around 780-866 MB the whole time (device has 2 GB), climbing only slowly and smoothly - no spike, no OOM pattern.
  • Not a total network outage: my “Easy Logger” app kept successfully writing rows to a remote Google Sheet the entire time the problem was happening (13:00 through at least 14:30), so Homey’s core / at least one app’s outbound connectivity was still working.

What actually fails:
Starting almost exactly ~13:00 (about 6h after boot), scripts running in the HomeyScript app start getting connection errors on NEW outbound connections:

13:00:57 ERROR update_devices  Error on script: Error: connect EHOSTUNREACH 217.182.125.204:443
13:15:31 ERROR update_devices  Error on script: Error: connect ENETUNREACH 217.182.125.204:443 - Local (0.0.0.0:0)
13:15:52 ERROR weather_computer  Global error on current weather: FetchError: request to https://api.open-meteo.com/... failed, reason: connect ENETUNREACH 94.130.142.35:443 - Local (0.0.0.0:0)
14:01:30 ERROR devices_manager  Error while processing Volet Chambre Parental (connect ENETUNREACH 217.182.125.204:443 - Local (0.0.0.0:0))

(repeats every ~15 min from then on, for both 217.182.125.204 and 94.130.142.35 - two unrelated destinations)

Notably, update_devices and devices_manager don’t call fetch() at all - they only use Homey.devices.getDevices() / device.setCapabilityValue(). So even plain SDK calls from HomeyScript start failing with ENETUNREACH/EHOSTUNREACH (“Local (0.0.0.0:0)” - i.e. it can’t even get a local socket/route), while another app (Easy Logger) keeps making outbound HTTPS calls successfully during the same window.

That pattern - one app’s outbound connections start failing to open while another app’s keep working, “Local (0.0.0.0:0)” suggesting no local socket/port available - looks like some per-app resource (sockets/fds/ports) tied to the HomeyScript app’s container is being exhausted after a few hours of normal script activity, not a general Wi-Fi/network outage.

I tried the obvious app-side fix first: some of my scripts were calling fetch() on error paths without consuming the response body (a documented Node/undici leak pattern that keeps the socket open). I fixed that in the scripts that do their own fetch() (weather API, two other cloud APIs) and re-deployed. Same failure happened again the next morning at almost the same ~6h mark - so whatever is leaking isn’t (only) in my own fetch() error paths; it looks like it’s happening on routine Homey SDK traffic itself (getDevices, setCapabilityValue, flow.runFlowCardAction), which runs very frequently across my scripts (every 5-15 min via several scripts).

Questions:

  • Is this a known issue with the HomeyScript app / firmware 13.x - some kind of connection/socket leak in how HomeyScript’s sandbox relays SDK calls (to 217.182.125.204, I’m guessing that’s an Athom-internal relay address) over several hours of uptime?
  • Is there a recommended workaround (e.g. periodically restarting the HomeyScript app) short of a full Homey reboot every few hours?
  • Happy to share the full raw memory_debug JSON dump (getMemoryInfo()/getInfo() responses) and more log excerpts if that helps diagnose it.

Homey Pro model: Homey Pro (Early 2023)
Firmware: 13.4.1 (issue started with firmware 13.x; did not happen before)

2

I don’t think so:

organisation:   ORG-OS3-RIPE
org-name:       OVH SAS
country:        FR
reg-nr:         424 761 419  R.C.S. LILLE METROPOLE
org-type:       LIR
address:        2 rue Kellermann
address:        59100
address:        Roubaix
address:        FRANCE

Although it could be that Athom has started using cloud service providers other than Amazon, you being from France gives me the impression that that IP-address might also be the external IP-address of your Internet connection (or the IP-address of the CGNAT server through which your Internet connection is served).

3

No, they haven’t. Everything is still AWS. It’s a Somfy server, according to Google.

image
image1242×289 20.5 KB

Just checked my pfSense pfTop menu, and I see that my Connectivity Kit is also connected there:

pfTop: Up State 1-2/2 (678), View: default, Order: bytes
PR        DIR SRC                           DEST                                   STATE                AGE       EXP     PKTS    BYTES
tcp       In  192.168.107.110:64933         217.182.125.205:803           ESTABLISHED:ESTABLISHED  12:27:20  23:59:53     8955   518212
tcp       Out 192.168.2.55:62350            217.182.125.205:803           ESTABLISHED:ESTABLISHED  12:27:20  23:59:53     8955   518212
4

Ah I guess that eventually the SDK calls trigger a fetch call in the Somfy driver, which then fails.

EHOSTUNREACH/ENETUNREACH suggests issues with Homey’s routing. It could happen if Homey loses its IPv4 address on its outgoing interface, but then I would also expect the connection to the web interface to break, which it doesn’t (and I don’t think the web interface supports IPv6 to connect to a local Homey).

5

Thanks both for the correction on the IP — good catch, that’s genuinely useful, I had that wrong.

To answer your question, robertklep: I check both ways, and during the incident both fail — the local web UI (same LAN) and the cloud app are unreachable at the same time. So it’s not just the outbound WAN route: something on Homey itself stops accepting/establishing any new connection, local or remote.

What still works during the outage: my Easy Logger app keeps successfully writing rows to a Google Sheet the whole time (I have timestamped log rows proving it), so at least one already-established outbound connection keeps functioning. Combined with the Local (0.0.0.0:0) in the Somfy/Open-Meteo errors (“can’t get a local socket/port” rather than “no route to host”), this looks less like a routing problem and more like some connection-tracking or ephemeral-port/file-descriptor table on the device filling up after a few hours of uptime — new connections (inbound to the local web server, or outbound from any app/driver) fail to allocate, while sockets that were opened before the exhaustion keep running fine.

Does anyone know if Homey Pro’s underlying Linux network stack exposes anything like conntrack stats, or if Athom has acknowledged a connection-table/socket-limit bug in 13.x? That would explain both symptoms (local + remote unreachable, but pre-existing connections surviving) better than a lost default route would.

6

Even though Homey is sold as “Everything local”, it still depends on a lot of communication with its cloud servers, even for LAN-connections. So the Web UI failing could still be a routing issue.

Most, if not all, of Google’s services are reachable over IPv6 :man_shrugging:t3:

You don’t get EHOSTUNREACH/ENETUNREACH if a new socket couldn’t be allocated. Also, 0.0.0.0:0 very likely means the local address to use for the outgoing connection, in this case “no specific port on no specific interface” (in other words, it’ll let the kernel decide which interface to use and let it pick a random(-ish) port).

7

Afaik it isn’t sold as that everything works local, it’s sold as that everything runs locally, which is true.

Somfy, Athom and Open Meteo don’t have any AAAA records, so those services don’t support IPv6

8

The Homey homepage says “Everything local”, just like I said.

And those are failing. Google, which does support IPv6, doesn’t.

9

Ah indeed. But it probably still means that everything is stored/runs locally. I mean: obviously cloud-based apps like Open Meteo and Somfy don’t work without internet :wink:

10

Found it - and it wasn’t Homey’s fault after all (well, not entirely). Posting the full story in case it helps anyone else with a similar setup.

Setup: Freebox (ISP router, does DHCP) → TP-Link TL-WR840N (used purely as a wired access point / bridge, DHCP disabled on it, Wi-Fi off for the Homey itself) → Homey Pro (Early 2023).

Root cause: the WR840N’s own boot sequence runs its own local DHCP server for about 19 seconds on every reboot, before it detects the Freebox’s DHCP server on the network and disables its own. I found this in the WR840N’s own system log - it shows a full DISCOVER/OFFER/REQUEST/ACK exchange with a 192.168.0.x address, followed by “Disable AP’s DHCP server because remote DHCP server is online” a few seconds later.

If the Homey’s DHCP client happens to send its request during that ~19s window (e.g. on a lease renewal, or after any brief link interruption), it gets handed a bogus 192.168.0.x lease from the WR840N itself instead of a real routable one from the Freebox (192.168.1.x). That leaves Homey with an IPv4 address that looks valid but has no route anywhere - which is exactly what ENETUNREACH means. IPv6 kept working the entire time because it’s SLAAC, driven directly by the Freebox’s Router Advertisements, completely independent of this DHCP race - which is why every outage I logged showed IPv4 dead and IPv6 perfectly healthy.

I confirmed this concretely two ways:

  1. The WR840N’s log literally shows my Homey’s MAC address going through a DISCOVER/REQUEST exchange with the WR840N’s transient DHCP server during a boot.
  2. I found the WR840N had rebooted at a time that lined up almost exactly (~10 min, my probe’s polling interval) with the start of an outage.

Why only a Homey reboot fixed it: Homey never seems to retry/recover from a bad lease/dead route on its own - not on a DHCP renewal, not even on a full physical link down/up (I tested unplugging/replugging the Ethernet cable directly - no reconnection without a full reboot). A reboot forces a fresh DHCP request, which normally lands safely after the WR840N has already stabilized.

Fix: explicitly disabled the DHCP server setting on the WR840N (instead of relying on its own runtime auto-detect-and-disable behavior, which still leaves that ~19s window open on every reboot). No more outages since.

Still an open question for Athom, IMO: even with my specific trigger fixed, Homey not recovering from a broken DHCP lease/route without a full reboot seems like a real robustness gap - any brief DHCP hiccup on the network (not just my case) could plausibly land it in the same stuck state. Might be worth someone looking at whether the DHCP client re-triggers a fresh DISCOVER on link-state changes or lease failures instead of only at boot.

Thanks again to @robertklep and @smarthomesven for the early pointers - the FD-leak red herring and the IPv4/IPv6 dual-stack angle both helped narrow this down, even though the actual mechanism turned out to be this DHCP race on my own LAN rather than anything IPv4-only-destination related.

11

Time to replace the WR840N then, that’s just incredibly stupid behaviour, especially if it’s set up as a bridge and DHCP is disabled on it.

AFAIK, not performing a new DHCP request on a link state change is default Linux behaviour. Also, this wasn’t a lease failure, Homey just received a DHCP response from what is basically a rogue DHCP server on your network, and it has no real way of knowing that the IP-address it received was functionally invalid.

And having to reboot the device to fix the issue is fairly typical for any headless unit, not just Linux.

12

Maybe try to update it first? But if that doesn’t fix it, I would also recommend replacing it. It’s EOL anyway