Shelly Integration issues since upgrade to 2025.5

tsquared · May 22, 2025, 4:21pm

Struggling with my Shelly’s since upgrading to 2025.5, and looking for help to troubleshoot further.

Current Shelly Info:
2x of these gen1 Shelly’s

System Info:

Prior to this upgrade, I have not had a single issue with these, or the shelly integration. Since this upgrade, when I try to control the lights that are attached to one of the Shelly’s it throws an error and tells me that it cannot control it because it cannot Communicate with it.

I previously configured the Shelly to use the CoIoT peer setting (using this guide) as this is a Gen 1 device, and again it was all working quite well.

I set up a Ping Sensor within HA to see if it was losing communication, but that seems to always show connected, so that probably isn’t it. However - the error message in the log leads me to believe it is a communication issue.

When I reboot either the HA Server, or the Shelly Device - I can control it for a short time period, maybe an hour, then it reverts back to the same issue shown in the log below.

The log shows like this:

Logger: homeassistant.components.websocket_api.http.connection
Source: components/websocket_api/commands.py:250
integration: Home Assistant WebSocket API (documentation, issues)
First occurred: May 20, 2025 at 10:10:07 PM (7 occurrences)
Last logged: 11:21:24 AM

[139746919599936] Unexpected exception
[139746731838976] Unexpected exception
[139746466656352] Unexpected exception
[139747830345344] Unexpected exception
[139746421897664] Unexpected exception
Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1115, in _wrap_create_connection
    sock = await aiohappyeyeballs.start_connection(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<5 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/aiohappyeyeballs/impl.py", line 122, in start_connection
    raise first_exception
  File "/usr/local/lib/python3.13/site-packages/aiohappyeyeballs/impl.py", line 73, in start_connection
    sock = await _connect_sock(
           ^^^^^^^^^^^^^^^^^^^^
    ...<6 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/aiohappyeyeballs/impl.py", line 208, in _connect_sock
    await loop.sock_connect(sock, address)
  File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 641, in sock_connect
    return await fut
           ^^^^^^^^^
  File "/usr/local/lib/python3.13/asyncio/selector_events.py", line 681, in _sock_connect_cb
    raise OSError(err, f'Connect call failed {address}')
OSError: [Errno 113] Connect call failed ('X.X.X.X', 80)

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/local/lib/python3.13/site-packages/aioshelly/block_device/device.py", line 319, in http_request
    resp: ClientResponse = await self.aiohttp_session.request(
                           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<6 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/client.py", line 703, in _request
    conn = await self._connector.connect(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        req, traces=traces, timeout=real_timeout
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 548, in connect
    proto = await self._create_connection(req, traces, timeout)
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1056, in _create_connection
    _, proto = await self._create_direct_connection(req, traces, timeout)
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1406, in _create_direct_connection
    raise last_exc
  File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1375, in _create_direct_connection
    transp, proto = await self._wrap_create_connection(
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<7 lines>...
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/aiohttp/connector.py", line 1130, in _wrap_create_connection
    raise client_error(req.connection_key, exc) from exc
aiohttp.client_exceptions.ClientConnectorError: Cannot connect to host X.X.X.X:80 ssl:default [Connect call failed ('X.X.X.X', 80)]

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/shelly/entity.py", line 380, in set_state
    return await self.block.set_state(**kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aioshelly/block_device/device.py", line 551, in set_state
    return await self.device.http_request(
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        "get", f"{self.type}/{self.channel}", kwargs
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/local/lib/python3.13/site-packages/aioshelly/block_device/device.py", line 350, in http_request
    return await self.http_request(method, path, params, retry=False)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.13/site-packages/aioshelly/block_device/device.py", line 355, in http_request
    raise self._last_error from err
aioshelly.exceptions.DeviceConnectionError: Cannot connect to host 192.168.0.140:80 ssl:default [Connect call failed ('X.X.X.X', 80)]

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 250, in handle_call_service
    response = await hass.services.async_call(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    ...<7 lines>...
    )
    ^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2802, in async_call
    response_data = await coro
                    ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/core.py", line 2845, in _execute_service
    return await target(service_call)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/adaptive_lighting/hass_utils.py", line 62, in service_func_proxy
    await existing_service.job.target(call)
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1007, in entity_service_call
    single_response = await _handle_entity_call(
                      ^^^^^^^^^^^^^^^^^^^^^^^^^^
        hass, entity, func, data, call.context
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    )
    ^
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 1079, in _handle_entity_call
    result = await task
             ^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/light/__init__.py", line 651, in async_handle_light_on_service
    await light.async_turn_on(**filter_turn_on_params(light, params))
  File "/usr/src/homeassistant/homeassistant/components/shelly/light.py", line 291, in async_turn_on
    self.control_result = await self.set_state(turn="on")
                          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/shelly/entity.py", line 383, in set_state
    raise HomeAssistantError(
    ...<6 lines>...
    ) from err
homeassistant.exceptions.HomeAssistantError: Device communication error occurred while calling action for light.basement_lights of shelly1-500291ED5

Any help here on where to turn next is greatly appreciated!

Cheers!

RxnfxMD · June 3, 2025, 10:50pm

Yes same issue. I have been noticing this with my Shelly Gen 1 devices as well. Anybody open a bug on this yet?

RxnfxMD · June 5, 2025, 5:10am

I will confirm that this had to do with my WiFi and not HA. Change UniFi AP from 40 to 20hz and unit has been solid. Hope this helps someone in a similar situation

tsquared · June 5, 2025, 12:33pm

@RxnfxMD Thank you for your help here, and yes, I too have UniFi. I looked at my AP’s to see if they have the setting you reference. They have been running at 20Mhz since the beginning, and have not been changed.

However, further troubleshooting on my end produced 2 additional items that may be notable here and not really an HA problem, but as you point out more networking related.

Initial setup of the Shelly’s - I created a static IP within the shelly directly, and did NOT create the same rule in the router I have corrected this, and now let the router assign the same IP address to these devices, but the Shelly is now setup for DHCP.
The UniFi controller seemed to have some “ghost” IP addresses i.e. they show up greyed out in the UniFi controller. These were different than those initially assigned to the Shelly’s. I have removed those from the UniFi controller.

After Fixing those two items and upgrading to the next version of HA (Currently @ 2025.5.3) - the issue seems to have been fixed. So I am marking this as the solution to the initial problem.

Hope this helps someone else in the future.

Cheers!

santaklon · June 11, 2025, 6:18pm

Having the same problem with a brand new Shelly Pro 2pm that is hardwired by Ethernet.

Only seems to happen if the shelly has to execute two commands at the same time (e.g. switch both channels at once) or if I toggle the same channel withing a few seconds. Apart form that it seems to works as inteded - but It’s unreliable enough for me not to trust it.

In my case I’m not on Unifi but Omada. I too do have so weird “ghost” IP problem it seems - culprit being a “easy” managed switch that was released with half-finished firmware and that does not show the client IP in the Controller frontend. I did assign a static IP to the Shelly as well, but that did not help.

TP-Link is promising an update, but who knows when.

Anyone else having this problem / any potential solutions?