Shelly TRV not responding (communication fails)

[hweis]

The problem

The shelly TRV stops responding after a while. After a long time without sending commands to the TRV, some commands can be issued, but after a while, communication fails with message "failed to call service climate/set_temperature" in the GUI. Only after waiting a "very long time" (didn't verify exactly, but around an hour, probably a half, works for me) communication succeeds again. In my case, I usually set the device set temp (see yaml), but this does not matter as far as I can tell .... During this time, sensor values from the TRV are received without any problem. The TRV is integrated using the official Shelly integration (which seems to use CoIoT as I needed to activate this in order to get the thing working in the first place).

What version of Home Assistant Core has the issue?

2022.12.3

What was the last working version of Home Assistant Core?

none

What type of installation are you running?

Home Assistant Supervised

Integration causing the issue

shelly

Link to integration documentation on our website

https://www.home-assistant.io/integrations/shelly

Diagnostics information

config_entry-shelly-trv.json.txt

Example YAML snippet

alias: TRV on
description: ""
trigger: []
condition: []
action:
  - service: climate.set_temperature
    data:
      temperature: 21
    target:
      entity_id: climate.shtrv_wohnz
mode: single

Anything in the logs that might be useful for us?

Logger: homeassistant.components.websocket_api.http.connection
Source: components/shelly/climate.py:240
Integration: Home Assistant WebSocket API (documentation, issues)
First occurred: 15:44:34 (9 occurrences)
Last logged: 15:50:08

[547633252816] Error handling message: Unknown error (unknown_error) from 192.168.0.71 (Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:107.0) Gecko/20100101 Firefox/107.0)
[547573577184]
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/decorators.py", line 27, in _handle_async_response
    await func(hass, connection, msg)
  File "/usr/src/homeassistant/homeassistant/components/websocket_api/commands.py", line 646, in handle_execute_script
    await script_obj.async_run(msg.get("variables"), context=context)
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 1524, in async_run
    await asyncio.shield(run.async_run())
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 409, in async_run
    await self._async_step(log_exceptions=False)
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 453, in _async_step
    self._handle_exception(
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 476, in _handle_exception
    raise exception
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 451, in _async_step
    await getattr(self, handler)()
  File "/usr/src/homeassistant/homeassistant/helpers/script.py", line 684, in _async_call_service_step
    await service_task
  File "/usr/src/homeassistant/homeassistant/core.py", line 1744, in async_call
    task.result()
  File "/usr/src/homeassistant/homeassistant/core.py", line 1781, in _execute_service
    await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 208, in handle_service
    await service.entity_service_call(
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 678, in entity_service_call
    future.result()  # pop exception if have
  File "/usr/src/homeassistant/homeassistant/helpers/entity.py", line 943, in async_request_call
    await coro
  File "/usr/src/homeassistant/homeassistant/helpers/service.py", line 715, in _handle_entity_call
    await result
  File "/usr/src/homeassistant/homeassistant/components/climate/__init__.py", line 613, in async_service_temperature_set
    await entity.async_set_temperature(**kwargs)
  File "/usr/src/homeassistant/homeassistant/components/shelly/climate.py", line 255, in async_set_temperature
    await self.set_state_full_path(target_t_enabled=1, target_t=f"{current_temp}")
  File "/usr/src/homeassistant/homeassistant/components/shelly/climate.py", line 240, in set_state_full_path
    return await self.coordinator.device.http_request(
  File "/usr/local/lib/python3.10/site-packages/aioshelly/block_device.py", line 254, in http_request
    if self.options.auth is None and self.requires_auth:
  File "/usr/local/lib/python3.10/site-packages/aioshelly/block_device.py", line 328, in requires_auth
    assert self.shelly
AssertionError

Additional information

[home-assistant[bot]]

Hey there @balloob, @bieniu, @thecode, @chemelli74, @bdraco, mind taking a look at this issue as it has been labeled with an integration (shelly) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of `shelly` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Change the title of the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign shelly` Removes the current integration label and assignees on the issue, add the integration domain after the command.

_{^{(message by CodeOwnersMention)}}

---

shelly documentation shelly source _{^{(message by IssueLinks)}}

[krasnoukhov]

Having the exact same issue. Seems like it's related to a fact that device is battery powered so it sleeps a lot. However official app somehow works around this limitation

[thecode]

The specific error @hweis is having is related to a problem with our code:

  File "/usr/local/lib/python3.10/site-packages/aioshelly/block_device.py", line 254, in http_request
    if self.options.auth is None and self.requires_auth:
  File "/usr/local/lib/python3.10/site-packages/aioshelly/block_device.py", line 328, in requires_auth
    assert self.shelly
AssertionError

Is caused since we try to access the device after HA restart while we didn't get data from the device. Since device only sends data once an hour when it is off this can easily happen. I will try to think of a solution, however I don't have a Shelly TRV so it will probably need to wait for the other codeowners to look at it.

@krasnoukhov by "exact same issue" do you have the exact error I showed above? If not please create a new issue, if you do, please add your log & diagnostics as it might help. Thanks

[chemelli74]

Does this happen only with the code shown in the initial post ? I'm not able to reproduce with my normal usage.

Simone

[krasnoukhov]

Actually @thecode after looking closely at the error it's different in my case...

Logger: homeassistant.core
Source: components/shelly/climate.py:267
First occurred: 2:46:33 PM (1 occurrences)
Last logged: 2:46:33 PM

Error executing service: <ServiceCall climate.set_temperature (c:01GPB92KVRZGKX8Z186J3QD5DK): temperature=20.0, entity_id=['climate.living_room_radiator']>
Traceback (most recent call last):
  File "/usr/local/lib/python3.10/site-packages/aioshelly/block_device/device.py", line 259, in http_request
    resp: ClientResponse = await self.aiohttp_session.request(
  File "/usr/local/lib/python3.10/site-packages/aiohttp/client.py", line 466, in _request
    with timer:
  File "/usr/local/lib/python3.10/site-packages/aiohttp/helpers.py", line 721, in __exit__
    raise asyncio.TimeoutError from None
asyncio.exceptions.TimeoutError

It seems like in my case it's just a regular HTTP timeout

[hweis]

Hello and best wishes for 2023! I want to say a big "Thank you" to all developers that are looking into the issue. I was hoping that after the holiday season people would get active agein ... ;-) . I updated HA core on my box (an Rpi4, supervised install) last night to 2023.1.2 and nothing changed ... on the contrary: I have the feeling that it got worse in the sense that the probability of cases when the commands are properly executed decreased. I add a fresh batch of error messages, but in my case, all of them are the same: shtrv-errors-2023-01-10.txt

[jtricerolph]

I have a reoccurring issue where I presume the device is asleep it doesn't accept temp charges from HA. I get error like this. Setting state for entity room_11_bedroom_shellytrv_2 failed, state: {'target_t_enabled': 1, 'target_t': '12.0'}, error: DeviceConnectionError() My logs are riddled with it for many valves on the setup for hotel to turn heating down when rooms are not booked. I can still get to the webui of device and sending rest request to change works as expected. I'm guessing it's from using the coiot coms. While the error logs and pops up is using climate card and changing manually. The new temp does stay on card and eventually presumeably when device wakes up it then gets pushed over as dispite lots of these errors in logs valves are generally at expected temps Automation wise it's not the end kf the world if takes a few minutes to get through when wakes up however the popup on ui is annoying and will prevent the use of tablets for guest ui in rooms as will show an error when they change temp and device resting Given the rest endpoint responds ASAP is it posible to change target temp requests to use rest rather than coiot to have instant oush rather than delayed responce and error message?

[selmaohneh]

I have a reoccurring issue where I presume the device is asleep it doesn't accept temp charges from HA. I get error like this. Setting state for entity room_11_bedroom_shellytrv_2 failed, state: {'target_t_enabled': 1, 'target_t': '12.0'}, error: DeviceConnectionError() My logs are riddled with it for many valves on the setup for hotel to turn heating down when rooms are not booked. I can still get to the webui of device and sending rest request to change works as expected. I'm guessing it's from using the coiot coms. While the error logs and pops up is using climate card and changing manually. The new temp does stay on card and eventually presumeably when device wakes up it then gets pushed over as dispite lots of these errors in logs valves are generally at expected temps Automation wise it's not the end kf the world if takes a few minutes to get through when wakes up however the popup on ui is annoying and will prevent the use of tablets for guest ui in rooms as will show an error when they change temp and device resting Given the rest endpoint responds ASAP is it posible to change target temp requests to use rest rather than coiot to have instant oush rather than delayed responce and error message?

Exact same behaviour here. Trying to set target temperatures for 5 TRVs from an automation and already the first TRV fails with:

Setting state for entity livingroom_thermostat failed, state: {'target_t_enabled': 1, 'target_t': '21.0'}, error: DeviceConnectionError()

Any ideas or workarounds? This happens every morning for the last couple days...

[jtricerolph]

Exact same behaviour here. Trying to set target temperatures for 5 TRVs from an automation and already the first TRV fails with:

Setting state for entity livingroom_thermostat failed, state: {'target_t_enabled': 1, 'target_t': '21.0'}, error: DeviceConnectionError()

Any ideas or workarounds? This happens every morning for the last couple days...

I have been tinkering with the shellydiscovery script and MQTT recently however it seems that the integration does have some sort of 'wait' function that perhaps doesnt happen in GUI with page refresh etc as automations do seem to generally work, although I do have follow up automations that retrigger changes a 2nd time after x amount of time.

I have also found that a bit of node red automation to directly post the change via http to the device api seemed to have helped allot. I havn't tried just using http in node red yet as system is now live but made node red listen to climate requests and it then gets status from device and check target temp and sends target that was attempted if not correct. Since its working in tandem with the oem intergration and the issue isn;t reliably recreatable for me its hard to test. I have noticed that generally the webgui of device seems to always respond even when intergration returns that error which is what made me think to try node red http request. without sitting in a room all day its hard to test as visiting webgui wakes device and following changes then go through, testing is limited to when happen to catch a device not responding via oem int and with hotel begining to get busy its harder to find a time to go round hunting for a device thats 'sleeping' at that perticular time. Node red definatly seems to help with automation side. GUI wise still get the error as thats in responce to the oem int timing out but generally if come back to it after a minute it seems to have pushed through.

[jtricerolph]

would be nice to get some sort of response from shelly or int creator, unresponsive to update requests is big pain and surprised not more people reporting similar issue. tbh, getting them all to stay connected to wifi in the big old building has taken more of my time, have 22 APs dotted arround the hotel with good enough signal for guests to use ok but the chip/ant on these devices does seem to be pretty poor. have a trv i manage to snap off i am hoping to have some experimentation with soldering a pigtail ant in pleace of the smd chip type on the board to see if can elviate poor signal on some of the more remote valves.

[issue-triage-workflows[bot]]

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates. Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.