Shelly won't work when switching to new AP

Configuration
1

At home i have a fritz wlan mesh and an additional (no mesh-) wlan repeater. 6 shellies are connected to the wlan. They are configured with the shelly integration.
If one AP is deactivated, for example when i disconnect it from power, and the shellies reconnect automatically to another AP, HA is no longer being able to connect to them. Despite the webinterface is reachable. I have to restart the host (pi3, HA-OS 9.3) in order to get it work again.

Is this a known limitation of HA or the shelly integration or is it a bug?
Thanks in advance

2 Likes
2

I have mesh wifi based on xiaomi routers and one wifi extender. I don’t know how did you set up your fritzbox integration but in my case I added both routers to my integration. If mesh node is down or rebooted all devices connected to it will connect to another router and will be accessible to home assistant. I just have one shelly wifi device.

3

I haven’t configured the fritzbox integration within HA. Why should it be necessary?
As mentioned, the shellies do reconnect to another node but then they are no longer being accessible through HA.

4

It was a while I integrated my shelly uni in home assistant. I can’t remember all the details but I saw that I have two automation’s for shelly.

alias: Shellies Announce
trigger:
  - platform: homeassistant
    event: start
  - platform: time_pattern
    hours: /1
action:
  - service: mqtt.publish
    data:
      topic: shellies/command
      payload: announce
      qos: 0
      retain: false

and another

alias: Shellies Discovery
mode: queued
max: 999
trigger:
  - platform: mqtt
    topic: shellies/announce
action:
  - service: python_script.shellies_discovery
    data:
      id: "{{ trigger.payload_json.id }}"
      mac: "{{ trigger.payload_json.mac }}"
      fw_ver: "{{ trigger.payload_json.fw_ver }}"
      model: "{{ trigger.payload_json.model | default }}"
      mode: "{{ trigger.payload_json.mode | default }}"
      host: "{{ trigger.payload_json.ip }}"

I probably picked this up somewhere online, but I can’t remember much details.

5

Ok, but if i understand your configuration correctly, you have configured them via mqtt, right?
I use the shelly integration from HA via the ui. The automations in which the shellies are used are configured via ui too.

Would it be possible that the problem lies within the CoIoT protocol?

6

I have shelly integration that integrated shelly uni in ha and mqtt integration. But I just have one shelly device. Was playing around with alarm 6 months ago or so.
Sorry I forgot details about it. I set it up like I wanted and forgot about it.

7

So what, do you mean i should change from using the HA shelly integration to mqtt?
I think i need a nerd who has deeper knowledge of the HA shelly integration. I don’t understand the behavior of the HA or the integration, not connecting the shellies after they have moved to another wlan ap within the same network. Btw, all shellies have static ip addresses and are reachable via webinterface all the time.

8 
So what, do you mean i should change from using the HA shelly integration to mqtt?

No, I didnt say that nor I suggest you to do that. I just use both. I think that you can enable mqtt on shelly device using webui, if I remember correctly.
I enable it, set it up and that was basically it. It works as expected from day one and this is why i totally forgot about it.
I use it to turn on lights in living room when alarm pir sensors are detecting motion.

9

Ah, ok, thank you for your suggestions. I might give that a try. Although it seems like a workaround to me. I would expect that i do have the shellies more than once within HA. Don’t i have duplicates then? Once through the integration and another through mqtt?

10

Just cheeking… I don’t see duplicate entities. Shelly web ui have options for mqtt so you can easily set it up if you have mqtt broker and integration configured.
I don’t know will this solve your problem, this is what I have. I done it probably because I saw that it supports mqtt so I told myself why not.

11

I had also connected the shellies via mqtt before. But that was years ago. Then the smartcard of my pi died and i changed to HA-OS and the shelly integration. Since a month or so i have the mesh set up and observe the mentioned behavior. The problem then come to my attention when an automation didn’t work as expected (shutters not going down at evening).

I think it has something to do with how HA or the shelly integration connects/communicates with the shellies. Possibly not re-newing some connection-parameters (websockets, CoIoT)? I mean maybe something like the hosts file. I don’t know…

12

Hi @somebody and others

I think I got also the same issue. I can’t figure out what is the problem.
Coiot?
Something else?

It can happens one day later the restart of HA.
Sometimes one week later.
That’s weird because my device are available. I can trigger them on the switch. I can connect to them by ip ect
Only in HA its seems broken after X days.
It’s random, I noticed it when an automation doesn’t work properly.
Sometimes the automation works with 5 or 10s of delay but in 99% of case I got " fetching device error disconnection" . Something like that.

Of course after a restart of HA, it’s working again

It seems to impact all my shellies in the same time. All works or all have issues in the same time.

Happy to see that I’m not the only one to have this problem.
It could be embarrassing soon because I just bought two weeks ago 20 shelly 1L… If I have this issue, I will be disappointed.

13

Hi there,

you can fix your problem by restarting HA? This does not solve it for me as i have to restart the host system (HA-OS on pi3). Seems that your problem is a little bit different to mine but within the same direction.

14

Hello, unfortunately I also have the problem. I have several shellys in the network. When only one Fritzbox is on everything works very well. As soon as I turn on the second Fritzbox as a meshrepeater, some shellys are no longer accessible for the HA. Is there any idea here in the meantime what the reason for this is?

I do not want to operate the shellys with MQTT.

Setup:
Fritzbox 6850 as modem
Fritzbox 7340 as meshrepeater via LAN
2x Shelly 1PM
1x Shelly +1PM
Pi400 with HA (current version)

15

I have read the documentation Shelly - Home Assistant again and changed the settings within the shelly from mcast to unicast as recommended:

We recommend using unicast for communication. To enable this, enter the local IP address of the Home Assistant server and port 5683 into the CoIoT peer field and push SAVE button. This is mandatory for battery operated devices . After changing the CoIoT peer , the Shelly device needs to be manually restarted.

I will see if this fixes the problems for me.

16

Switching to unicast doesn’t solve the problem. In order to get the shelly integration working again, i need to restart the pi almost daily. This is very annoying.

The log fires “not available anymore” messages every few minutes.

The following errors are logged within the homeassistant.log file:

2023-04-10 13:56:26.416 ERROR (MainThread) [homeassistant.core] Error executing service: <ServiceCall cover.open_cover (c:XXXXXXXXX): entity_id=['cover.rollade_west_tt']>
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/cover.py", line 123, in async_open_cover
    self.control_result = await self.set_state(go="open")
  File "/usr/src/homeassistant/homeassistant/components/shelly/entity.py", line 349, in set_state
    raise HomeAssistantError(
homeassistant.exceptions.HomeAssistantError: Setting state for entity Rollade_West_TT failed, state: {'go': 'open'}, error: DeviceConnectionError()