Shelly Unavailable in Home Assistant: Safe Fix

Direct answer: When a Shelly device is unavailable in Home Assistant, first confirm that the device still has the expected local IP address and that its own web interface opens from the same network. Then identify the hardware generation. Generation 1 devices depend on CoIoT push traffic, normally sent by unicast to the Home Assistant host on UDP port 5683. Generation 2 and newer devices use RPC and usually require no extra push configuration, although some battery-powered devices may need a correct outbound WebSocket address. Do not factory-reset the device until you have separated an IP or Wi-Fi problem from a CoIoT, WebSocket, VLAN, HTTPS, or authentication problem.

Scope and versions: This guide applies to the official Shelly integration in current Home Assistant releases and to supported Shelly generations. It focuses on local communication between Home Assistant and the device. Shelly BLU devices are a special case: most use the BTHome integration rather than the Shelly integration, while the Shelly BLU TRV is handled differently through a supported gateway. Menu names vary by Shelly generation and firmware, so use the device-generation branch that matches the hardware rather than copying a setting from another model.

Symptoms this guide covers

The Shelly integration shows a device or entities as unavailable.
Switching a relay from Home Assistant fails, but the physical input still works.
The device responds slowly or entity states update only after a delay.
Home Assistant reports that push updates are not reaching it.
A device became unavailable after moving Home Assistant, changing its IP address, adding a VLAN, replacing a router, or enabling Enhanced Security.
A battery-powered Shelly appears only briefly or stopped reporting after a Home Assistant migration.
The Shelly web interface works, but Home Assistant does not receive current state changes.

This guide does not assume that every unavailable state has the same cause. A dead device, unstable Wi-Fi, a changed DHCP lease, blocked local traffic, stale integration configuration, and missing push updates can look similar in the dashboard but require different fixes.

Safety and privacy before troubleshooting

Electrical safety: Many Shelly products are installed behind switches, inside electrical boxes, or near mains voltage. Do not open an enclosure, remove a wall switch, touch terminals, or work on energized wiring to perform network troubleshooting. Use only the device web interface, router, and Home Assistant controls described here. If power cycling requires access to fixed wiring, use the appropriate circuit breaker only if you can identify it safely, or use a qualified electrician.

Before changing configuration, record the device model, generation, firmware version, current IP address, Home Assistant entity IDs, automation references, and any existing CoIoT or WebSocket value. Take screenshots that do not expose passwords, tokens, public IP addresses, precise location data, or wireless credentials. Never post a full Home Assistant diagnostic download publicly without reviewing and redacting it.

Ranked causes

The device is offline or has a different IP address. DHCP changes, weak Wi-Fi, access-point roaming, client isolation, or a router replacement can break the route Home Assistant previously used.
Generation 1 CoIoT push traffic is not reaching Home Assistant. CoIoT may be disabled, the unicast peer may contain an old Home Assistant address, UDP 5683 may be blocked, or the device may not have been restarted after changing the peer.
A VLAN or firewall permits web access but blocks device-to-server traffic. Opening the Shelly page from a laptop proves that one path works; it does not prove that the Shelly can send push traffic to Home Assistant.
A Generation 2+ battery device has a stale outbound WebSocket address. This can occur after moving Home Assistant or changing its internal address.
Enhanced Security or HTTPS configuration changed. On supported Gen2+ firmware, secure local communication can require the expected port and certificate-verification choice.
The integration entry contains stale host information or credentials. This is less common than basic reachability problems and should be addressed after the device and route are verified.
The device is the wrong product type for the Shelly integration. Most Shelly BLU sensors use BTHome, not the Shelly integration.

Step 1: identify the device generation and connection path

Do not begin with a reset. Open the device information in Home Assistant or the local Shelly interface and identify the exact model and generation. The official integration documentation distinguishes four generations and explains that their update paths differ. Generation 1 uses CoIoT. Generation 2 and newer use RPC. That distinction determines which network setting matters.

If the product is a Shelly BLU sensor, check whether it belongs in the BTHome integration. A device appearing in Bluetooth discovery but not in the Shelly integration may be behaving normally. Correct classification prevents unnecessary firmware changes and resets.

Step 2: verify power, IP address, and local reachability

Confirm the device has power using its normal, safe indicator or physical behavior.
Check the router or DHCP server for the device’s current lease.
Compare that address with the host shown in Home Assistant.
From a device on the same trusted LAN, open the Shelly’s local web interface.
Record the firmware version and Wi-Fi signal information if shown.

Interpretation: If the local page does not open and the router has no current lease, troubleshoot power and Wi-Fi before changing Home Assistant. If the router shows a new address and the local page opens there, reserve that address in DHCP and allow Home Assistant to rediscover or reconfigure the device. Do not assign a static address inside the device and a conflicting reservation in the router.

If the device page opens but Home Assistant still reports unavailable, the problem has narrowed to the route between the two endpoints, integration configuration, authentication, or the generation-specific push channel.

Step 3: distinguish complete unavailability from missing push updates

Try one low-risk control from Home Assistant and then change the device through its local web interface or safe physical input. Observe whether Home Assistant eventually catches up.

No control and no state: investigate IP reachability, routing, HTTPS, credentials, and integration host information.
Control works but state updates are delayed or absent: investigate CoIoT on Gen1 or outbound WebSocket behavior on the affected Gen2+ battery devices.
Only one entity is unavailable: review whether the entity is supported, disabled, diagnostic, or dependent on a sensor channel. A whole-device network repair may not be appropriate.
All local devices on one VLAN fail together: suspect routing, firewall, multicast, or client-isolation policy before editing each device.

Step 4: repair Generation 1 CoIoT safely

For a Generation 1 device, open its local interface and verify that CoIoT is enabled. The official Home Assistant Shelly documentation recommends unicast and specifies the Home Assistant server’s local IP address with port 5683 as the CoIoT peer. Use the address Home Assistant actually has on the local network, not its public domain, a Cloudflare address, or a remote-access URL.

Record the existing CoIoT peer.
Confirm Home Assistant’s stable internal IP address.
Set the peer to HOME_ASSISTANT_IP:5683.
Save the setting.
Restart the Shelly device as instructed by the official documentation.
Wait for it to reconnect before testing state changes.

Battery-operated Generation 1 devices require this unicast configuration even when connected by USB. If the Shelly and Home Assistant are on different subnets, allow the necessary UDP 5683 traffic from the device network to the Home Assistant host. Create the narrowest rule that fits the path; do not expose UDP 5683 to the internet and do not disable an entire firewall as a test.

If the CoIoT setting is missing, check whether the device firmware is extremely old. Review the manufacturer’s release information and update through the official device interface only after preserving settings and confirming stable power. Do not interrupt a firmware update.

Step 5: check Generation 2+ RPC and outbound WebSocket

Generation 2 and newer devices use RPC and normally need no additional configuration. Therefore, do not add a WebSocket merely because a mains-powered Gen2 device is unavailable. Start with IP reachability, routing, authentication, and security settings.

The documented exception is certain battery-operated devices, including devices temporarily connected by USB, when Home Assistant cannot determine the correct internal URL or when the device still points to a different Home Assistant instance. In that case, check Settings → Connectivity → Outbound WebSocket in the device interface. The documented path uses:

ws://HOME_ASSISTANT_LOCAL_IP:8123/api/shelly/ws

If the local Home Assistant endpoint itself uses HTTPS with a suitable certificate, use the corresponding wss:// form. Do not use wss:// simply because the public website or remote-access domain uses HTTPS; the device must be able to validate and reach the exact local endpoint configured.

After correcting a stale address, save the change and let the device reconnect. Avoid running two active Home Assistant instances that both try to control the same device during a migration.

Step 6: test VLAN, firewall, and Wi-Fi behavior

A useful diagnostic is to draw the actual path: Shelly IP, wireless access point, IoT VLAN, router or firewall, and Home Assistant IP. Test each boundary. Common policy mistakes include wireless client isolation, a rule that permits established connections in only one direction, a guest network that blocks local destinations, and a firewall that allows TCP web access but not the UDP traffic needed by Gen1 CoIoT.

Do not permanently move every device to the main LAN as a shortcut. If a temporary same-network test makes the problem disappear, that result identifies a routing or policy issue. Recreate the required narrow local flow, then return the device to the intended network.

For unstable Wi-Fi, compare behavior close to the access point and review signal strength. The official documentation notes that access-point roaming can help on networks with several access points. Avoid changing channel width, roaming, band steering, multicast, and firewall rules simultaneously; one change at a time preserves the ability to identify the cause.

Step 7: review Enhanced Security and HTTPS

Supported Gen2+ devices can use Enhanced Security. The Home Assistant integration detects this and communicates over HTTPS on port 443. Devices shipped with supported newer firmware may have factory-provisioned certificates, while devices upgraded later may require a separately installed certificate before Enhanced Security can be used as intended.

If Enhanced Security was enabled immediately before the failure, confirm that Home Assistant can reach port 443 on the device and review the integration’s certificate-verification setting. Enable certificate verification only when the presented certificate chains to a certificate authority trusted by Home Assistant. Leaving verification disabled for a self-signed or internally provisioned device certificate is different from turning off encryption entirely. Do not upload unknown certificates or bypass warnings on a public interface.

Step 8: reload only after the network path is correct

Once reachability and the generation-specific channel are correct, reload the Shelly integration entry. If the device has a new IP address, allow discovery or use the supported reconfiguration flow. Avoid deleting the integration first: deletion can disrupt entity IDs, device associations, dashboards, histories, and automations without fixing the network cause.

If reauthentication is requested, use the device’s current local credentials. Do not paste passwords into logs or community posts. If a credential change is necessary, record which automations or external systems also rely on that account.

Verification checklist

The device’s local page opens at the expected reserved IP address.
Home Assistant shows the device and main entities as available.
A safe command from Home Assistant reaches the device.
A physical or local-interface change appears promptly in Home Assistant.
No new Shelly repair issue appears after a restart.
The device remains available after restarting Home Assistant.
The device remains available after restarting the router or access point.
Automations referencing the established entity IDs still run.

Verification after both endpoint and network restarts matters. A fix that works only until the next DHCP renewal or reboot is not complete.

Rollback and recovery

If a configuration change makes the device less reachable, restore the recorded CoIoT peer, WebSocket URL, security option, or DHCP reservation one change at a time. Keep Home Assistant’s integration entry intact while rolling back. If a firmware update introduced the behavior, do not install unofficial firmware or attempt an unsupported downgrade; consult the manufacturer’s documented recovery path.

A factory reset is the last resort. Before resetting, export or record device schedules, calibration, input mode, power-on behavior, Wi-Fi configuration, authentication, and automation references. For a mains-wired relay, follow the model’s official manual and use a qualified electrician when physical access is required.

When to escalate

Escalate when the device repeatedly reboots, disappears from DHCP despite good power and Wi-Fi, rejects its own local interface, shows certificate errors you cannot explain, or remains unavailable after the documented local path is verified. Provide the exact model, generation, firmware, Home Assistant version, installation type, network topology, redacted error text, and whether local control works. State whether the failure affects command traffic, push updates, or both.

Do not publish device credentials, backup archives, serial numbers that function as secrets, precise public addressing, or unredacted diagnostics. Community reports can help identify patterns, but the official integration and manufacturer documentation should control safety-sensitive changes.

Prevention

Reserve stable DHCP addresses for Home Assistant and fixed smart-home infrastructure.
Document Gen1 CoIoT peers and Gen2+ WebSocket settings before migrations.
Use narrow, documented firewall rules between IoT networks and Home Assistant.
Change one network or security setting at a time and verify afterward.
Maintain a current Home Assistant backup before integration or network migrations.
Review repair notifications instead of disabling them without understanding the tradeoff.
Keep firmware current through official channels, with stable power during updates.
Preserve entity IDs when reconfiguring to avoid breaking automations.

Diagnostic matrix

Observed result	Most likely layer	Next safe check
No DHCP lease or local page	Power or Wi-Fi	Confirm safe power state, access point association, and signal
Local page works; no Home Assistant control	Routing, host, HTTPS, or credentials	Compare IP, ports, VLAN route, and integration entry
Control works; state is stale on Gen1	CoIoT push path	Enable CoIoT, verify unicast peer and UDP 5683
Battery Gen2+ stopped after migration	Outbound WebSocket	Remove the old Home Assistant address and set the current local endpoint
Failure began after Enhanced Security	HTTPS or certificate handling	Verify port 443, certificate source, and Verify SSL choice
Every device on one IoT VLAN fails	Network policy	Inspect routing, isolation, and narrowly scoped firewall rules

Sources and testing disclosure

Testing disclosure: This guide is based on current official documentation and protocol-specific diagnostic reasoning. Troubliq did not claim hands-on testing with every Shelly generation, firmware revision, network topology, or security configuration.

Last reviewed: September 18, 2026.

Shelly unavailable in Home Assistant: CoIoT, RPC, VLAN, and security diagnostics