Repository navigation
Shelly Mini Gen3: Old IP address persists in Zeroconf and causes integration failure after firmware update #189003
Description
The problem
My Shelly 1 Mini Gen3 repeatedly becomes unavailable in Home Assistant after Shelly firmware updates.
The device originally used IP address 192.168.0.72, but has been configured with a static IP of 192.168.0.189 directly in its Wi-Fi settings for a long time.
After firmware updates, Home Assistant attempts to connect to the old address (.72). Manually reconfiguring the integration to .189 immediately restores functionality, often for days or weeks.
Investigation revealed that Home Assistant's Zeroconf browser simultaneously lists BOTH IPv4 addresses for the same Shelly service:
{
"name": "shelly1minig3-cc8da2469e1c._http._tcp.local.",
"type": "_http._tcp.local.",
"port": 80,
"properties": {"gen": "3"},
"ip_addresses": [
"192.168.0.72",
"192.168.0.189"
]
}Inspection of /config/.storage/core.config_entries revealed:
Name: Ankleide/Fitness
Host: 192.168.0.72
Source: user
The Shelly's /rpc/Sys.GetConfig endpoint confirms that the local device name is null and discoverable is true.
Both Home Assistant and the Shelly have been restarted, but Zeroconf continues to list both IPv4 addresses. The FRITZ!Box 7690 does not show duplicate device entries.
Shelly firmware: 2.0.3 (20261026-122213)
Installation: Home Assistant OS in a Synology VM.
Expected behavior:
Home Assistant should not replace a working connection address with an obsolete, unreachable IPv4 address.
The origin of the stale mDNS address has not yet been established.
Related issue: #173494. Unlike the workaround described there, resetting the device name is not applicable because it is already null.
Additional observation regarding Zeroconf discovery:
When searching for the Shelly service in Home Assistant's Zeroconf browser, initially only the correct IPv4 address (192.168.0.189) is displayed.
Approximately 3 seconds later, the obsolete address (192.168.0.72) appears in the same service entry, resulting in both IPv4 addresses being listed.
This behavior is repeatable and may help identify whether an additional mDNS response or a delayed discovery/cache update is responsible.
Update: The issue occurred again while preparing this bug report, without another firmware update or device restart.
Home Assistant displayed:
"Setup error, will retry: A device communication error occurred for Ankleide/Fitness."
At the same time, inspection of /config/.storage/core.config_entries confirmed that the integration still had 192.168.0.72 stored as its host, although the Shelly is reachable at its configured static IP 192.168.0.189.
The Zeroconf browser continues to list both IPv4 addresses.
Interestingly, when searching for the Shelly in the Zeroconf browser, initially only 192.168.0.189 appears. Approximately 3 seconds later, 192.168.0.72 is added to the same service entry.
This suggests that the integration may be selecting the obsolete address from Zeroconf discovery, resulting in a communication failure.
Additional finding:
I changed the Shelly's static IPv4 address directly in its web interface from 192.168.0.189 to 192.168.0.190.
Home Assistant automatically detected the new address, and the integration started working again without any manual reconfiguration.
However, /config/.storage/core.config_entries still contains the original, obsolete address 192.168.0.72 as the host.
This suggests that the integration can discover and communicate with the device using its current IP address while retaining an outdated host value in the stored configuration.
I also have several other Shelly 1 Mini Gen3 devices running without any issues. Only this particular device is affected.
What version of Home Assistant Core has the issue?
core-2026.10.4
What was the last working version of Home Assistant Core?
No response
What type of installation are you running?
Home Assistant OS
Integration causing the issue
No response
Link to integration documentation on our website
No response
Diagnostics information
No response
Example YAML snippet
Anything in the logs that might be useful for us?
Additional information
No response
Metadata
Metadata
Assignees
Labels
Type
Fields
Priority
Activity