SignalRHub reconnect loop after closing HA's shared aiohttp session — never recovers ("Session is closed")

[Mikealfred-pin]

Since updating to Home Assistant Core 2026.9.0, the Hilo integration gets stuck in a permanent reconnect loop after the first connection error.

Log evidence:

homeassistant.helpers.frame: Detected that custom integration 'hilo' closes the Home Assistant aiohttp session at custom_components/hilo/__init__.py, line 343: await hilo._api.session.close(). Please create a bug report at https://github.com/dvd-dev/hilo/issues

pyhilo: Error parsing response:

custom_components.hilo: SignalRHub[0]: connection error; reconnecting in 80s — Session is closed
custom_components.hilo: SignalRHub[1]: connection error; reconnecting in 160s — Session is closed
... (backs off to 300s and repeats indefinitely, never recovers)

Impact: Both SignalR hubs fail every reconnect attempt because the shared HA aiohttp.ClientSession was closed by the integration itself (line 343) rather than a private session. All Hilo sensors (thermostat temperature/target/power) froze at their last value and stopped updating for 13+ hours until I manually reloaded the config entry, which recreated the session and restored the connection.

Environment: Home Assistant OS 18.2, Core 2026.9.0, Hilo integration v2026.8.3 (HACS), Home Assistant Green.

Suggested fix: hilo._api.session should be a session the integration owns and can close on unload, not the shared HA session obtained via async_get_clientsession(hass).

[ic-dev21]

Check for 429 errors. Known issue at Hilo. The session closing isn’t new and is not likely related.

[Mikealfred-pin]

Thanks for the pointer — I turned on debug logging for custom_components.hilo and pyhilo and watched about an hour of reconnect cycles (9+ SignalRHub reconnect attempts, roughly 5 minutes apart).

No 429 or "Too Many Requests" shows up anywhere in that window. What I do see:

• Both SignalRHub[0] and SignalRHub[1] fail every single reconnect with the identical message — connection error; reconnecting in 300s — Session is closed — and have been stuck in that loop for well over an hour without ever recovering.
• Separately, the SSE/data connection (pyhilo) is healthy: it hits a normal 180s keepalive timeout every few minutes and reconnects successfully within ~5 seconds each time.
• HA's own frame helper flags a deprecation warning that points at a likely root cause: the integration closes Home Assistant's shared aiohttp session directly (custom_components/hilo/__init__.py:343, await hilo._api.session.close()). Once that shared session is closed, anything reusing it — like the SignalRHub reconnect logic — fails with exactly "Session is closed" and never recovers on its own.

So this lines up with your read — doesn't look 429-related on my end, looks more like a session-lifecycle bug in how the SignalRHub connections manage/share that session. Happy to share the full debug log slice if it'd help.

[ic-dev21]

Please still do a double check for me as I’ve been working with Hilo on this.

[ic-dev21]

I am currently running a test host on 2026.9 and not seeing a problem here. The aiohttp session isn't something that has changed recently in the code, it's been written that way for quite a while. Will keep monitoring it.

[Mikealfred-pin]

(Posted with help from Claude AI on my behalf.)

Happy to double check — let me know specifically what you'd like me to look at (a particular log line, timing window, HACS version, config entry setup, etc.) and I'll dig in.

In the meantime, here's what I can add: the reconnect loop is still 100% reproducible on my end — SignalRHub[0] and SignalRHub[1] have not recovered on their own once in any of the sessions I've captured, always with the identical "Session is closed" error. The one consistent signal I keep coming back to is HA's own frame helper warning pointing at custom_components/hilo/__init__.py:343 (await hilo._api.session.close()) — that's the shared HA aiohttp.ClientSession, not a private one, so once it's closed anything reusing it (the SignalRHub reconnect logic) fails permanently until a manual config entry reload recreates the session.

If it'd help narrow this down, I can post the full debug log slice (redacted) covering a session-close event through several failed reconnects, or confirm my exact versions (HA OS 18.2, Core 2026.9.0, Hilo v2026.8.3 via HACS, Home Assistant Green). Just let me know which would be most useful.

[ic-dev21]

(Posted with help from Claude AI on my behalf.)

Happy to double check — let me know specifically what you'd like me to look at (a particular log line, timing window, HACS version, config entry setup, etc.) and I'll dig in.

In the meantime, here's what I can add: the reconnect loop is still 100% reproducible on my end — SignalRHub[0] and SignalRHub[1] have not recovered on their own once in any of the sessions I've captured, always with the identical "Session is closed" error. The one consistent signal I keep coming back to is HA's own frame helper warning pointing at custom_components/hilo/__init__.py:343 (await hilo._api.session.close()) — that's the shared HA aiohttp.ClientSession, not a private one, so once it's closed anything reusing it (the SignalRHub reconnect logic) fails permanently until a manual config entry reload recreates the session.

If it'd help narrow this down, I can post the full debug log slice (redacted) covering a session-close event through several failed reconnects, or confirm my exact versions (HA OS 18.2, Core 2026.9.0, Hilo v2026.8.3 via HACS, Home Assistant Green). Just let me know which would be most useful.

Usually this happens when Hilo closes it on their end.

You could always remove the following lines locally:

hilo/custom_components/hilo/__init__.py

Lines 340 to 347 in 1ca6751

	try:
	if hasattr(hilo, "_api") and hilo._api and hasattr(hilo._api, "session"):
	if hilo._api.session and not hilo._api.session.closed:
	await hilo._api.session.close()
	LOG.debug("Session closed")
	except Exception as err:
	LOG.error("Error closing session: %s", err)

And see where that takes you.

The rest of the closing mechanism stems from pysignalr's canceling, and is out of scope of both hilo and pyhilo.

[Mikealfred-pin]

(Posted with help from Claude AI on my behalf.)

That makes sense, thanks — I'll pull that try/except block (lines 340-347) locally and let it run through a few reconnect cycles to see whether the SignalRHub loop still gets stuck without the explicit session.close() call. Will report back with what I find either way.

One thing before I do: since that block also runs on integration unload/reload (not just on the error path), removing it means the shared HA aiohttp.ClientSession never gets explicitly closed when the config entry unloads — is that safe to leave out long-term, or is that close call needed there for cleanup on a normal unload? Want to make sure I'm not trading the reconnect loop for a session/resource leak on reload.

[ic-dev21]

It should get closed by HA's own lifecycle for it. I think it's cleaner that way.

PysignalR has some quirks with connection closing that may be the root of the issue.

[Mikealfred-pin]

(Posted with help from Claude AI on my behalf.)

Update: I pulled that block (the try:/except: around await hilo._api.session.close(), lines 340-346 in my installed copy) and did a full HA Core restart so the change would actually take effect.

Before the change: SignalRHub[0] and SignalRHub[1] were logging connection error; reconnecting in 300s — Session is closed like clockwork every 5 minutes, for over an hour straight, never recovering.

Since the restart (~1.5 hours so far): zero occurrences of that error. Integration is still showing as loaded with no setup issues.

I know that's not conclusive on its own — a fresh restart starts with a fresh session either way, so the real test is whether it stays clean over a longer stretch, and especially whether it survives a future reload without falling back into the loop (since the removed code only ran on unload). I'll keep an eye on it and report back if the loop resurfaces, but wanted to share the early result in case it's a useful data point on your end too.

[ic-dev21]

@Mikealfred-pin take a look at @njloof'a fix in dvd-dev/python-hilo#450.

I was studying the pysignalR library and came upon this as well. This has likely failed silently forever.

[Mikealfred-pin]

(Posted with help from Claude AI on my behalf.)

Thanks for digging into pysignalr and flagging #450 — makes sense that this ties back to the same library quirks.

Quick status update on my end: it's now been over a day since I pulled the try/except block around session.close() (lines 340-346) and restarted, and the SignalRHub reconnect loop hasn't resurfaced once — zero "Session is closed" errors, multiple normal reconnects that recovered on their own as expected. So that local patch looks solid so far.

I'll keep watching #450 too and can test it against my setup once it's merged, in case it addresses something the session-close fix doesn't catch on shutdown/restart.

[ic-dev21]

@Mikealfred-pin please update and report back. Should be fixed now.

[Mikealfred-pin]

Confirming the fix in v2026.9.1 works for me. Updated via HACS and restarted on 2026-09-08 22:48 UTC; the SignalRHub "connection error; reconnecting in Ns — Session is closed" loop has not recurred since — I went looking specifically for that "Session is closed" signature in the logs and found none from Hilo.

Thanks @ic-dev21 and everyone on #1033/#1034/python-hilo#450 — the reconnect fix looks solid.

[ic-dev21]

@Mikealfred-pin let me know if this can be closed

[Mikealfred-pin]

(Posted with help from Claude AI on my behalf.)

Yes, go ahead and close it — it's been running clean for several days now (updated and restarted 2026-09-08 22:48 UTC) with no recurrence of the SignalRHub "Session is closed" loop at all. Thanks again to you and everyone who worked on #1033/#1034/python-hilo#450 for tracking this down.