Hi ,
I’ve been experiencing a recurring issue with my Pironman5 Max add-on
where Home Assistant completely freezes after approximately 2 days of uptime,
requiring a hard power cycle to recover.
Setup
- Raspberry Pi 5
- Pironman5 Max case with official add-on v1.3.6.1
- Home Assistant OS 17.3 / Core 2026.5.2
- NVMe SSD (booting directly from NVMe)
Symptoms
- HA web UI becomes completely unresponsive after ~2 days
- Pi remains visible on the network (router shows active connection)
but with zero data transfer
- Only hard power cycle helps
- Fans stop spinning before the freeze (sign that the add-on process
has degraded)
Root cause found
After analyzing Supervisor logs, I discovered that the Pironman5 Max
add-on polls the HA Supervisor API endpoint /network/info every 3 seconds
continuously and without interruption:
/network/info access from 6fa7f6d2_pironman5-max (every 3 seconds, 24/7)
This is clearly unintended behavior. Over time it degrades the Supervisor
event loop to the point where HA stops responding entirely.
Workaround
I set up a nightly scheduled host restart in HA automation to recover
before the freeze occurs. This is obviously not a permanent solution.
Request
Could the development team look into why the add-on polls /network/info
continuously instead of fetching it once at startup and then only on
actual network change events?
Has anyone else experienced this? Would be great to know if this is
reproducible on other setups.
Thanks
Thanks for the detailed report and for digging into the Supervisor logs — that’s really helpful.
You’re right that there’s no subscription or event-based API for network state changes in Home Assistant. We’ve looked into both the Supervisor REST API and the Core WebSocket API, and neither provides a push mechanism for network change notifications. The only way to detect network state changes is to poll GET /network/info. We set the interval to 3 seconds to pick up network changes relatively quickly for display on the dashboard.
That said, you’ve clearly shown that 3-second continuous polling is too aggressive and degrades the Supervisor over time. Unfortunately, since there’s no push-based API available, there isn’t a clean way to completely avoid polling at the moment.
For a future update, we may consider adding a manual refresh button to the add-on UI, so users can trigger a refresh on demand rather than relying on constant background polling. But honestly, without a proper network change event from HA, the underlying limitation remains.
We’ll look into this further and try to get an update out as soon as possible. Thanks again for the thorough analysis — this kind of feedback is exactly what helps us improve.
Thank you for the detailed explanation — it’s good to understand the architectural limitation with HA Supervisor’s lack of push-based network events.
One suggestion that might help bridge the gap until a proper solution is available: would it be possible to make the polling interval configurable in the add-on settings? A default of 3 seconds could be kept for users who want fast dashboard updates, but allowing users to set a longer interval (e.g. 30 or 60 seconds) would reduce the Supervisor API load by 10–20x and likely eliminate the degradation issue entirely for those who don’t need near-realtime network status on the OLED.
In my case, the network info on the dashboard is purely informational — I don’t need it updated every 3 seconds. A 30-second interval would be perfectly acceptable and would make the add-on much more stable for long-running installations.
Thanks again for looking into this.
Thank you very much for your detailed suggestion and for your understanding of the current architectural limitation.
You are absolutely correct that we currently have multiple polling intervals:
IP address: every 3 seconds
CPU, network speed, RAM, etc.: every 1 second
We realize that this makes it difficult for users to understand what each interval controls, and therefore hard to adjust them properly. We will look into how we can improve this.
Thank you again for your constructive feedback – it is very helpful. We will continue to work on a solution.
Hi,
Following up on my previous report about the /network/info polling issue.
I now have concrete evidence from the Pironman5 Max add-on logs that
identifies the exact root cause.
Exact error from add-on log (repeating every 3 seconds):
File “/opt/pironman5/venv/lib/python3.12/site-packages/sf_rpi_status/ha_api.py”,
line 39, in get_ips
interfaces = data[“data”][“interfaces”]
KeyError: ‘data’
What is happening:
The function get_ips() in ha_api.py calls /network/info every 3 seconds.
The API response does not contain the expected “data” key, causing a KeyError.
Instead of handling this exception and backing off, the code retries
immediately in a loop - resulting in continuous polling every 3 seconds, 24/7.
Additional issues found in the log:
-
InfluxDB connection error on every start:
Failed to connect to InfluxDB: HTTPConnectionPool(host=‘localhost’, port=8086):
Connection refused
I don’t have InfluxDB installed. The add-on should handle this gracefully.
-
Thread leak on shutdown:
WARNING: Thread Thread-1 is still alive
WARNING: Thread Thread-4 (watch_loop) is still alive
Threads are not properly terminated when the add-on stops.
Suggested fix for ha_api.py line 39:
Add proper exception handling and exponential backoff when the API
response doesn’t contain expected data, instead of retrying immediately.
Impact:
After approximately few hours max days of continuous polling, the Supervisor API
degrades to the point where Home Assistant freezes completely and requires
a hard power cycle.
Hope this helps narrow down the fix.
Thank you for your update.
Please note that our office is closed for the weekend. We will get back to you with a detailed response next week.
Thank you for your patience and understanding.
Thank you for your detailed report.
We’re aware of this issue now and have already started investigating and optimizing the add-on. Your findings regarding the network information polling are very helpful and give us a good direction to focus on.
We’ll continue testing and will get back to you as soon as we have an update or a fix available.
Thank you for your patience and for helping us improve the software.