Shelly timeout error

[raptr55]

The problem

after upgrading from a raspberry pi3b to a raspberry pi 5 some shelly devices cant connect to home assistant The problem is the same mentioned here https://github.com/home-assistant/core/issues/115313

What version of Home Assistant Core has the issue?

core-2024.8.1

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

Shelly

Link to integration documentation on our website

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

Diagnostics information

home-assistant_shelly_2024-08-19T11-12-32.896Z.log

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

[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 Renames 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.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

_{^{(message by CodeOwnersMention)}}

---

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

[bieniu]

Please add a description of the problem and attach the diagnostic file and debug log for Shelly integration.

[raptr55]

Please add a description of the problem and attach the diagnostic file and debug log for Shelly integration.

It’s the same of the linked bug. I’ve opened this one because the other was closed with no fix.

You still need the debug log?

[bieniu]

The linked issue is from April for a different HA version and probably for a different Shelly firmware version so yes, we need a proper problem description, diagnostics file and debug log.

[jgeorge1983]

I just had this issue. I went into the Shelly app and noticed my devices were offline. So I re added them, the app found them and configured them automatically as they were previously. Upgraded the firmware and they're back in HA now.

[raptr55]

The linked issue is from April for a different HA version and probably for a different Shelly firmware version so yes, we need a proper problem description, diagnostics file and debug log.

the requested information has been added to the first comment. Is further information needed?

[raptr55]

I just had this issue. I went into the Shelly app and noticed my devices were offline. So I re added them, the app found them and configured them automatically as they were previously. Upgraded the firmware and they're back in HA now.

this is not the case. in fact, after a long time the requests no longer time out and the devices become available again

[raptr55]

home-assistant_shelly_2024-08-26T10-52-14.856Z.log same problem with home assistant 2024.8.3

[thecode]

home-assistant_shelly_2024-08-26T10-52-14.856Z.log same problem with home assistant 2024.8.3

Can you leave a ping running from another device in the network towards one of the Shelly devices? I looked at your log and some devices are not responding, I don't see anything wrong from the integration side besides responses missing from the devices.

[raptr55]

all shellys are reachable either by ping or from the web interface

[smacbride]

I upgraded to HA OS 13.1 on a RPI and now I'm getting the timeout error on one of my Shelly devices.

I have a test box running HA on a docker instance and It works fine on that instance.

Both are running core 2024.7.4

[smacbride]

Here is the log for my system with same issue: home-assistant_shelly_2024-08-28T16-36-25.609Z.log

[smacbride]

More information on this problem. I upgraded both my live system running HA OS to 2024.8.3 and my linux docker test box to 2024.8.3 and the issue persists on the HA OS instance. It works just fine on the linux docker instance.

So this would leave me to believe its an underlying issue with the HA OS?

[raptr55]

Same issue with new home assistant 2024.09 version

[smacbride]

Same for my instance as well.

From: raptr55 @.> Sent: Friday, September 6, 2024 3:50 AM To: home-assistant/core @.> Cc: E. Scott MacBride @.>; Comment @.> Subject: Re: [home-assistant/core] Shelly timeout error (Issue #123585)

Same issue with new home assistant 2024.09 version

— Reply to this email directly, view it on GitHubhttps://github.com/home-assistant/core/issues/123585#issuecomment-2333690556, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AULTKOF6GAYFB42TK362SU3ZVF3DTAVCNFSM6AAAAABMKVSSQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZTGY4TANJVGY. You are receiving this because you commented.Message ID: @.@.>>

[smacbride]

Updraging to 2024.9.2 has solved the problem for me.

[raptr55]

Not for me… the issue is still present on 2024.9.2

[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.

[raptr55]

Same problem with the 2024.10.0 version

[DomenicoCasillo]

Hello, I do have the same exact problem and I would like to help devs figure it out.

Issue appeared first time around May and fixed itself at some point without any actions. I have an EM and several 2.5 that fails to come up in home assistant but are perfectly reachable both from the network and from home assistant itself (all the other 20 shellies are working just fine) From the home asisstant terminal:

• The IP of shellies can be successfully pinged
• Home assistant is also able to retrieve shellies main page through curl
• Shellies are configured in unicast. Home assistant and Shellies are on a different VLAN.
• No changes were made to home infrastructure in the last 2 years
• Everything was working fine in the last 3 years

Reboots of firewall, home assistant or shellies didn't help.

Here's the debug log for the non-working shelly em:

2024-10-05 20:01:26.345 DEBUG (MainThread) [homeassistant.components.shelly] Network adapters: [{'name': 'lo', 'index': 1, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [{'address': '127.0.0.1', 'network_prefix': 8}], 'ipv6': [{'address': '::1', 'flowinfo': 0, 'scope_id': 0, 'network_prefix': 128}]}, {'name': 'enp0s18', 'index': 2, 'enabled': True, 'auto': True, 'default': True, 'ipv4': [{'address': '192.168.10.6', 'network_prefix': 24}], 'ipv6': [{'address': 'fe80::96ff:2a50:59ff:da0f', 'flowinfo': 0, 'scope_id': 2, 'network_prefix': 64}]}, {'name': 'hassio', 'index': 3, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [{'address': '172.30.32.1', 'network_prefix': 23}], 'ipv6': [{'address': 'fe80::42:7bff:fed6:ecea', 'flowinfo': 0, 'scope_id': 3, 'network_prefix': 64}]}, {'name': 'docker0', 'index': 4, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [{'address': '172.30.232.1', 'network_prefix': 23}], 'ipv6': [{'address': 'fe80::42:ff:fe7c:cebf', 'flowinfo': 0, 'scope_id': 4, 'network_prefix': 64}]}, {'name': 'veth48e7ef8', 'index': 6, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::dc3d:53ff:fe71:21e3', 'flowinfo': 0, 'scope_id': 6, 'network_prefix': 64}]}, {'name': 'vethb4116c7', 'index': 8, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::5006:edff:fe1d:c8a8', 'flowinfo': 0, 'scope_id': 8, 'network_prefix': 64}]}, {'name': 'vethc33b626', 'index': 10, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::68fc:90ff:fef0:57da', 'flowinfo': 0, 'scope_id': 10, 'network_prefix': 64}]}, {'name': 'veth45cc2ff', 'index': 12, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::c83a:3dff:fe7f:37cf', 'flowinfo': 0, 'scope_id': 12, 'network_prefix': 64}]}, {'name': 'veth2c7c741', 'index': 14, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::f88c:f7ff:fe20:456e', 'flowinfo': 0, 'scope_id': 14, 'network_prefix': 64}]}, {'name': 'veth3484644', 'index': 16, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::403e:24ff:fe25:c27e', 'flowinfo': 0, 'scope_id': 16, 'network_prefix': 64}]}, {'name': 'veth5e8fc3a', 'index': 20, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::5c14:51ff:fef8:ca74', 'flowinfo': 0, 'scope_id': 20, 'network_prefix': 64}]}, {'name': 'vethc401ebd', 'index': 22, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::f4e9:f6ff:fe2c:5ca4', 'flowinfo': 0, 'scope_id': 22, 'network_prefix': 64}]}, {'name': 'veth14afebf', 'index': 26, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::80d3:41ff:fed2:b9dc', 'flowinfo': 0, 'scope_id': 26, 'network_prefix': 64}]}] 2024-10-05 20:01:26.346 DEBUG (MainThread) [homeassistant.components.shelly] Network IPv4 addresses: [] 2024-10-05 20:01:26.346 INFO (MainThread) [homeassistant.components.shelly] Starting CoAP context with UDP port 5683 2024-10-05 20:01:26.350 DEBUG (MainThread) [aioshelly.block_device.coap] Socket initialized on port 5683 (default interface) 2024-10-05 20:01:26.431 DEBUG (MainThread) [aioshelly.block_device.coap] Sending request 'cit/s' to device 192.168.20.19 2024-10-05 20:01:26.431 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: block device create, MAC: 244CAB4326F3 2024-10-05 20:01:26.431 DEBUG (MainThread) [aioshelly.block_device.coap] Adding device 4326F3 to CoAP message subscriptions 2024-10-05 20:01:26.431 DEBUG (MainThread) [homeassistant.components.shelly] Setting up online block device ShellyEM Main 2024-10-05 20:01:26.431 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: block device initialize 2024-10-05 20:01:26.569 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: http request: /settings (params=None) 2024-10-05 20:01:26.826 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: http request: /status (params=None) 2024-10-05 20:01:26.925 DEBUG (MainThread) [aioshelly.block_device.device] aiohttp response: {'wifi_sta': {'connected': True, 'ssid': 'DomaNet iOT', 'ip': '192.168.20.19', 'rssi': -72}, 'cloud': {'enabled': True, 'connected': True}, 'mqtt': {'connected': False}, 'time': '20:01', 'unixtime': 1728151286, 'serial': 2681, 'has_update': False, 'mac': '244CAB4326F3', 'cfg_changed_cnt': 6, 'actions_stats': {'skipped': 0}, 'relays': [{'ison': False, 'has_timer': False, 'timer_started': 0, 'timer_duration': 0, 'timer_remaining': 0, 'overpower': False, 'is_valid': True, 'source': 'input'}], 'emeters': [{'power': 328.43, 'reactive': -614.79, 'pf': -0.47, 'voltage': 233.8, 'is_valid': True, 'total': 10953818.9, 'total_returned': 38.9}, {'power': 8.59, 'reactive': 17.65, 'pf': 0.44, 'voltage': 233.8, 'is_valid': True, 'total': 128420.2, 'total_returned': 0.0}], 'update': {'status': 'idle', 'has_update': False, 'new_version': '20230913-114150/v1.14.0-gcb84623', 'old_version': '20230913-114150/v1.14.0-gcb84623', 'beta_version': '20231107-164916/v1.14.1-rc1-g0617c15'}, 'ram_total': 51064, 'ram_free': 36260, 'fs_size': 233681, 'fs_free': 157126, 'uptime': 18444} 2024-10-05 20:01:26.926 DEBUG (MainThread) [aioshelly.block_device.coap] Sending request 'cit/d' to device 192.168.20.19 2024-10-05 20:01:36.570 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: timeout error: DeviceConnectionTimeoutError(TimeoutError()) 2024-10-05 20:01:36.570 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: block device shutdown

What is wrong for me is that for working shellies i have in the logs some COAP message that i don't have for the ones non-working like:

2024-10-05 20:01:26.530 DEBUG (MainThread) [aioshelly.block_device.coap] CoapMessage: ip=192.168.20.55, type=CoapType.REPLY(69), options={11: b's', 3332: b'SHSW-1#E8DB84AC15F6#2', 3412: b'\x96\x00', 3420: b'\x01\x00'}, payload={'G': [[0, 9103, 0], [0, 1101, 0], [0, 2101, 0], [0, 2102, ''], [0, 2103, 0]]} 2024-10-05 20:01:26.531 DEBUG (MainThread) [aioshelly.block_device.coap] Calling CoAP message update for device id AC15F6

Thanks.

[raptr55]

Hello, I do have the same exact problem and I would like to help devs figure it out.

Issue appeared first time around May and fixed itself at some point without any actions. I have an EM and several 2.5 that fails to come up in home assistant but are perfectly reachable both from the network and from home assistant itself. From the home asisstant terminal:

• The IP of shellies can be successfully pinged
• Home assistant is also able to retrieve shellies main page through curl
• Shellies are configured in unicast
• No changes were made to home infrastructure in the last 2 years
• Everything was working fine in the last 3 years

Reboots of firewall, home assistant or shellies didn't help. What would be helpful for you? How can we debug this?

Thanks.

I think they gonna ask you to share the Diagnostics information log

[edudele]

+1

[raptr55]

Same problem with 2024.10.3

[mvdheenux]

Same for me, just started on 2024.10.3. I have about 30 shelly devices, all gen1. Weirdly enough, one does work, while running on identical fw and using the same configuration as all others...

[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.

[raptr55]

Same with 2024.11.0

[xan-it]

had the same problem (and log entries) with Shelly 2.5 devices. After enabling CoIoT (shelly-webui > Internet & Security > Advanced - Devoloper Settings) with peer set to mcast and rebooting the device, I can add this shelly devices in HA 2024.11.1

[DomenicoCasillo]

Hello, I do have the same exact problem and I would like to help devs figure it out.

Issue appeared first time around May and fixed itself at some point without any actions. I have an EM and several 2.5 that fails to come up in home assistant but are perfectly reachable both from the network and from home assistant itself (all the other 20 shellies are working just fine) From the home asisstant terminal:

• The IP of shellies can be successfully pinged
• Home assistant is also able to retrieve shellies main page through curl
• Shellies are configured in unicast. Home assistant and Shellies are on a different VLAN.
• No changes were made to home infrastructure in the last 2 years
• Everything was working fine in the last 3 years

Reboots of firewall, home assistant or shellies didn't help.

Here's the debug log for the non-working shelly em:

2024-10-05 20:01:26.345 DEBUG (MainThread) [homeassistant.components.shelly] Network adapters: [{'name': 'lo', 'index': 1, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [{'address': '127.0.0.1', 'network_prefix': 8}], 'ipv6': [{'address': '::1', 'flowinfo': 0, 'scope_id': 0, 'network_prefix': 128}]}, {'name': 'enp0s18', 'index': 2, 'enabled': True, 'auto': True, 'default': True, 'ipv4': [{'address': '192.168.10.6', 'network_prefix': 24}], 'ipv6': [{'address': 'fe80::96ff:2a50:59ff:da0f', 'flowinfo': 0, 'scope_id': 2, 'network_prefix': 64}]}, {'name': 'hassio', 'index': 3, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [{'address': '172.30.32.1', 'network_prefix': 23}], 'ipv6': [{'address': 'fe80::42:7bff:fed6:ecea', 'flowinfo': 0, 'scope_id': 3, 'network_prefix': 64}]}, {'name': 'docker0', 'index': 4, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [{'address': '172.30.232.1', 'network_prefix': 23}], 'ipv6': [{'address': 'fe80::42:ff:fe7c:cebf', 'flowinfo': 0, 'scope_id': 4, 'network_prefix': 64}]}, {'name': 'veth48e7ef8', 'index': 6, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::dc3d:53ff:fe71:21e3', 'flowinfo': 0, 'scope_id': 6, 'network_prefix': 64}]}, {'name': 'vethb4116c7', 'index': 8, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::5006:edff:fe1d:c8a8', 'flowinfo': 0, 'scope_id': 8, 'network_prefix': 64}]}, {'name': 'vethc33b626', 'index': 10, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::68fc:90ff:fef0:57da', 'flowinfo': 0, 'scope_id': 10, 'network_prefix': 64}]}, {'name': 'veth45cc2ff', 'index': 12, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::c83a:3dff:fe7f:37cf', 'flowinfo': 0, 'scope_id': 12, 'network_prefix': 64}]}, {'name': 'veth2c7c741', 'index': 14, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::f88c:f7ff:fe20:456e', 'flowinfo': 0, 'scope_id': 14, 'network_prefix': 64}]}, {'name': 'veth3484644', 'index': 16, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::403e:24ff:fe25:c27e', 'flowinfo': 0, 'scope_id': 16, 'network_prefix': 64}]}, {'name': 'veth5e8fc3a', 'index': 20, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::5c14:51ff:fef8:ca74', 'flowinfo': 0, 'scope_id': 20, 'network_prefix': 64}]}, {'name': 'vethc401ebd', 'index': 22, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::f4e9:f6ff:fe2c:5ca4', 'flowinfo': 0, 'scope_id': 22, 'network_prefix': 64}]}, {'name': 'veth14afebf', 'index': 26, 'enabled': False, 'auto': False, 'default': False, 'ipv4': [], 'ipv6': [{'address': 'fe80::80d3:41ff:fed2:b9dc', 'flowinfo': 0, 'scope_id': 26, 'network_prefix': 64}]}] 2024-10-05 20:01:26.346 DEBUG (MainThread) [homeassistant.components.shelly] Network IPv4 addresses: [] 2024-10-05 20:01:26.346 INFO (MainThread) [homeassistant.components.shelly] Starting CoAP context with UDP port 5683 2024-10-05 20:01:26.350 DEBUG (MainThread) [aioshelly.block_device.coap] Socket initialized on port 5683 (default interface) 2024-10-05 20:01:26.431 DEBUG (MainThread) [aioshelly.block_device.coap] Sending request 'cit/s' to device 192.168.20.19 2024-10-05 20:01:26.431 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: block device create, MAC: 244CAB4326F3 2024-10-05 20:01:26.431 DEBUG (MainThread) [aioshelly.block_device.coap] Adding device 4326F3 to CoAP message subscriptions 2024-10-05 20:01:26.431 DEBUG (MainThread) [homeassistant.components.shelly] Setting up online block device ShellyEM Main 2024-10-05 20:01:26.431 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: block device initialize 2024-10-05 20:01:26.569 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: http request: /settings (params=None) 2024-10-05 20:01:26.826 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: http request: /status (params=None) 2024-10-05 20:01:26.925 DEBUG (MainThread) [aioshelly.block_device.device] aiohttp response: {'wifi_sta': {'connected': True, 'ssid': 'DomaNet iOT', 'ip': '192.168.20.19', 'rssi': -72}, 'cloud': {'enabled': True, 'connected': True}, 'mqtt': {'connected': False}, 'time': '20:01', 'unixtime': 1728151286, 'serial': 2681, 'has_update': False, 'mac': '244CAB4326F3', 'cfg_changed_cnt': 6, 'actions_stats': {'skipped': 0}, 'relays': [{'ison': False, 'has_timer': False, 'timer_started': 0, 'timer_duration': 0, 'timer_remaining': 0, 'overpower': False, 'is_valid': True, 'source': 'input'}], 'emeters': [{'power': 328.43, 'reactive': -614.79, 'pf': -0.47, 'voltage': 233.8, 'is_valid': True, 'total': 10953818.9, 'total_returned': 38.9}, {'power': 8.59, 'reactive': 17.65, 'pf': 0.44, 'voltage': 233.8, 'is_valid': True, 'total': 128420.2, 'total_returned': 0.0}], 'update': {'status': 'idle', 'has_update': False, 'new_version': '20230913-114150/v1.14.0-gcb84623', 'old_version': '20230913-114150/v1.14.0-gcb84623', 'beta_version': '20231107-164916/v1.14.1-rc1-g0617c15'}, 'ram_total': 51064, 'ram_free': 36260, 'fs_size': 233681, 'fs_free': 157126, 'uptime': 18444} 2024-10-05 20:01:26.926 DEBUG (MainThread) [aioshelly.block_device.coap] Sending request 'cit/d' to device 192.168.20.19 2024-10-05 20:01:36.570 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: timeout error: DeviceConnectionTimeoutError(TimeoutError()) 2024-10-05 20:01:36.570 DEBUG (MainThread) [aioshelly.block_device.device] host 192.168.20.19: block device shutdown

What is wrong for me is that for working shellies i have in the logs some COAP message that i don't have for the ones non-working like:

2024-10-05 20:01:26.530 DEBUG (MainThread) [aioshelly.block_device.coap] CoapMessage: ip=192.168.20.55, type=CoapType.REPLY(69), options={11: b's', 3332: b'SHSW-1#E8DB84AC15F6#2', 3412: b'\x96\x00', 3420: b'\x01\x00'}, payload={'G': [[0, 9103, 0], [0, 1101, 0], [0, 2101, 0], [0, 2102, ''], [0, 2103, 0]]} 2024-10-05 20:01:26.531 DEBUG (MainThread) [aioshelly.block_device.coap] Calling CoAP message update for device id AC15F6

Thanks.

After over a month, I've had some time to investigate the issue a bit deeper. Looking at logs it's crystal clear that COAP messages are sent from HA to the shellies but no answer is received. Therefore I started investigating my network and in particular my firewall rules in OPNSense. I have a pretty standard setup with main LAN where the HomeAssistant instance is and a VLAN for iOT devices (where shellies are). After some debugging with WireShark and OPNsense diagnostic console I figured out that the firewall traffic rules were misbehaving and the response traffic of only some shellies got blocked and that generated the timeout connection error. I managed to fix the rules and now everything is working rock solid as usual from over a week.

[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.

[MassiPi]

damn i thought i broke something but i see i'm not the only one with random Shelly devices not seen in HA i have twelve of them and every reboot is at risk of loosing some device.. so i can confirm the issue also with last HA version