Logger: homeassistant.core
Source: components/shelly/entity.py:349
First occurred: 1:31:35 AM (46 occurrences)
Last logged: 2:20:19 AM
Error executing service: <ServiceCall switch.turn_on (c:01GRB1Z1TEQE6S2P6J48Z0GE7Q): entity_id=['switch.pellet_stove']>
Error executing service: <ServiceCall switch.turn_on (c:01GRB21QNAGBSH55HFKWCDEKCD): entity_id=['switch.pellet_stove']>
Error executing service: <ServiceCall switch.turn_on (c:01GRB247W21YYGKCVQ7X22HM1K): entity_id=['switch.pellet_stove']>
Error executing service: <ServiceCall switch.turn_on (c:01GRB29R94G51HP9EGK2ZTVAHP): entity_id=['switch.pellet_stove']>
Error executing service: <ServiceCall homeassistant.turn_on (c:01GRB2BE1AX1WQTG3N4ZM7PXFV): entity_id=['switch.pellet_stove']>
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
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 346, in set_state
return await self.block.set_state(**kwargs)
File "/usr/local/lib/python3.10/site-packages/aioshelly/block_device/device.py", line 481, in set_state
return await self.device.http_request(
File "/usr/local/lib/python3.10/site-packages/aioshelly/block_device/device.py", line 276, in http_request
raise DeviceConnectionError from err
aioshelly.exceptions.DeviceConnectionError
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/core.py", line 1773, in catch_exceptions
await coro_or_task
File "/usr/src/homeassistant/homeassistant/core.py", line 1792, in _execute_service
await cast(Callable[[ServiceCall], Awaitable[None]], handler.job.target)(
File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 213, 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 958, 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/shelly/switch.py", line 115, in async_turn_on
self.control_result = await self.set_state(turn="on")
File "/usr/src/homeassistant/homeassistant/components/shelly/entity.py", line 349, in set_state
raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: Setting state for entity shelly1-E8DB84ACD51B failed, state: {'turn': 'on'}, error: DeviceConnectionError()
Am I reading it right that it’s probably just a wifi fluke? Power cycling the shelly device and turning off and on the generic thermostat worked.
Yeah, I bet this was a problem on your wifi… Is this the first time this happened or is it a frequent thing?
Is this Shelly device far from your router or any chance your network is overloaded?
First time happening that I know of. It’s certainly plausible that the Shelly could have dropped out without me knowing. I just know that because this call didn’t happen my pellet stove didn’t turn on and I woke up to a cold home. What’s also interesting is that the generic thermostat doesn’t even look like it was commanding the Shelly on. You can see in the graph where it died fairly early in the morning. And you can see when I rebooted the Shelly and turned off and on generic thermostat at 7:30 this morning. After that it turned the Shelly relay on.
I’m not trying to remove the focus from what have made the communication with your Shelly fails, but it can happens for a million reasons and looks like the Generic Thermostat don’t retry if a turn_on call fails, which is sad.
Hi guys, I got this issue for the second time in two weeks. I don’t know what changed in HA or the Shelly plugin but my shelly (x5) via HA doesn’t answer 9 times on 10
If I go on the ip directly and try to set the state its ok. If I click IRL on the button it’s OK but if I try to change state from HA its broken until I restart HA completely
Am I the only one to get this issue recently ?
I use shellies since one or two years without any trouble until now
I have more than 40 Shellies (1PM, 2.5PM, 1+PM, 2+PM, Dimmer 2 and Uni), and I haven’t seen any problem lately. I’m running Home Assistant 2023.2.3 and all the Shelly with the latest firmware.
Anything else changed in your environment? A new wifi network? A new router? Moved the access point to a new location?
Hi
No nothing changed and I don’t know when I will get again this issue because for example since the reboot of HA yesterday it’s OK.
But maybe in 2 or 3 days I will have this and all shelly will be unavailable in HA.
When it’s not fully unavailable, sometimes after to spam 50 clics just to see, 1 will be applied I don’t know why. But as you can understand it’s unresponsive at 99% of time until I reboot HA.
Nb: it’s not one or two shellies which got this issue. It’s all in the same time or 0. It’s really weird
My shellies ( 2x 1pm plus, 1x 1pm, 2x 2.5) continue to work well, it’s really linked to HA.
Mqtt process maybe because tell me if I wrong but that use mqtt communication between shelly and HA
I didn’t touch anything since one or two month. HA is still the version in 12.2022. Shelly still running with begin 2022 firmware. My router and Internet brand is still the same.
I didn’t change anything that’s why I don’t understand
You can integrate Shelly using MQTT or the Shelly integrationm, each one with its pros and cons… I’m using the Shelly integration, so no MQTT involved in my case.
But a bunch of people uses the MQTT option and I don’t see they complaining…
What if you just restart your MQTT add-on (Mosquito?) when you get on that state, so you start narrowing down the problem?
By the way, I also use fix IP address on my devices… Maybe you can try to increase the DHCP lease time in your router settings and see if that improves the stability of your Shelly’s.
just to be sure when you see that,
You can confirm that I use integration and no mqtt like I thought ?
I’m asking this because I enabled on each Shelly (since one year ^^) the mqtt service connected to my mosquitto server but finally it’s useless ?
Mosquitto works well because I have 20 lights connected into zigbee using mqtt messages with Mossquitto and I never got a single freeeze or latence. So I don’t think so mosquitto is reponsible of anything in this case.
Finally I’m not sure that my shellies are using mqtt. I’m using integration so I thought it was mqtt used in this case but I’m wrong maybe ?
Regards
NB: My IPs are already fixed in the router since the begin
DHCP range is huge ( 150 devices possible, 10 connected in total )
Looks like you are using the Shelly integration, so.ni need to setup MQTT on the devices.
The 2nd gen devices (2x 1pm plus) are good to go without any settings, but the old ones (1x 1pm, 2x 2.5) will require CoIoT, as you probably have set already, right?
Hi
That’s weird if I set a wrong port or ip, it still working
If I set mcast it’s still working
If I disable coiot, it doesn’t work anymore from Home Assistant
I set as you said the coIot, even if I’m not sure to use the right ip and port because wrong and right value doesn’t change anything
I disabled mqtt feature on each shellies
I updated all my shellies for lights on the latest firmware
I updated HA on the latest version.
Now I will give you news in two or three weeks to see if its fixed.
I had similar issues with my shellys, Using unicast not mqtt. Was able to connect and operate them using their web gui but HA would not connect. It was infrequent but annoying. Changing the IP address of each device would make HA connect again. However changing static IPs on each device was a hassle so now I just reboot the router (usg3 pro) and they work again.
Hiya.
I too have started experiencing this recently.
Unfortunately, of course, it started happening when I did half a dozen or so things including, updating firmware on my Conbee II, migrating from Conbee II to Skyconnect, repairing all my Zigbee devices, updating my Skyconnect’s firmware, updating my HA Docker image, updating Docker itself on my Raspberry Pi 4B…
Key thing here is that I too am using:
HA in Docker
with CoIoT unicast
with port 5683 exposed via docker-compose.yaml
But it hasn’t solved the issue. It’s just DeviceConnectionError() from the Shelly integration in HA, even though the web GUI for each Shelly is accessible without issue.
Of note: I have static IPs for each Shelly, but I actually add them to HA through their hostnames, which has never presented an issue before. EG: relay-kitchen-light.lan. The Shelly integration has never given me issues with that before, I wonder if anyone else is also using DNS resolution instead of IPs and seeing this problem now?
… the problem for me was that I hadn’t exposed port 5683 for UDP traffic via docker-compose. All of my issues have been instantly solved since doing so.
