Hi,
Following up on this thread. After waiting several weeks without an official fix, I implemented a working workaround by patching the add-on directly inside the Docker container. Sharing it here for anyone else affected.
Root cause (confirmed)
The polling originates in pm_auto/addons/system.py, function task_3s(), which calls get_ips() every 3 seconds. This eventually calls ha_api.get_ips(), which hits /network/info on every invocation — no caching, no backoff on error.
The exact call chain:
task_3s() [every 3s]
→ sf_rpi_status.get_ips()
→ ha_api.get_ips()
→ GET /network/info ← Supervisor API spam
Workaround
Since my IP address is static and my connection type is always wired (LAN), I replaced the two functions in ha_api.py with static return values. This eliminates all /network/info polling entirely.
Step 1 – In the HA terminal, prepare the patched file (adjust end0 and YOUR IP to match your setup):
cat > /tmp/ha_api_new.py << 'EOF'
import os
base_url="http://supervisor/"
token = None
headers = None
def is_homeassistant_addon():
return 'SUPERVISOR_TOKEN' in os.environ
def init():
global headers, token
if token is not None and headers is not None:
return
if is_homeassistant_addon():
token = os.environ['SUPERVISOR_TOKEN']
headers = {
"Authorization": f"Bearer {token}",
"Content-Type": "application/json",
}
def get(endpoint):
init()
import requests
url = f"{base_url}{endpoint}"
r = requests.get(url, headers=headers)
return r.json()
def set(endpoint, data=None):
init()
import requests
url = f"{base_url}{endpoint}"
r = requests.post(url, headers=headers, json=data)
print(r)
def get_ips():
return {"end0": "192.168.1.100"} # adjust to your interface and IP
def get_network_connection_type():
return ["Wired"] # or ["Wireless"] if on WiFi
def shutdown():
'''shutdown homeassistant host'''
set("host/shutdown")
def reboot():
'''reboot homeassistant host'''
set("host/reboot")
def restart_addon(addon_name=None):
if addon_name is None:
addon_name = os.environ['HOSTNAME'].replace('-', '_')
set(f"addons/{addon_name}/restart")
EOF
To find your interface name, run ip link show and look for the interface with state UP (not lo, docker0, or veth*). On Raspberry Pi 5 with HA OS it’s typically end0.
Step 2 – Copy the patched file into the container:
docker cp /tmp/ha_api_new.py addon_6fa7f6d2_pironman5-max:/opt/pironman5/venv/lib/python3.12/site-packages/sf_rpi_status/ha_api.py
Step 3 – Restart the container (preserves the patch):
docker restart addon_6fa7f6d2_pironman5-max
Important: Use docker restart or the Restart button in HA UI.
Do NOT use Stop + Start — that recreates the container and loses the patch.
Step 4 – Verify the patch is in place:
docker exec addon_6fa7f6d2_pironman5-max grep -A2 "def get_ips" /opt/pironman5/venv/lib/python3.12/site-packages/sf_rpi_status/ha_api.py
Step 5 – Verify the spam stopped:
curl -s -H "Authorization: Bearer $SUPERVISOR_TOKEN" http://supervisor/supervisor/logs 2>&1 | tail -30 | grep "network/info"
Results
/network/info polling stopped completely- Add-on CPU usage dropped from ~2% to ~0.6%
- Supervisor API is no longer degraded
- OLED continues to display correct IP and connection type (static values)
The patch survives: add-on restart, HA host reboot, HA OS update.
The patch is lost on: Stop + Start of the add-on, or reinstall. In those cases just reapply it.
When SunFounder releases an official fix, updating the add-on will overwrite the patch — which is exactly what we want.
Hope this helps others while we wait for the official fix. @SunFounder_Moderator — any update on the timeline for the fix?