[BUG]LAGS on v.0.2.1

[bozzettaccio]

I've just updated to the 0.2.1 version and now my shelly entities lag each time I turn them on or off. The previous version was perfect, instead

I've just updated to the 0.2.1 version and now my shelly entities lag each time I turn them on or off. The previous version was perfect, instead ## Environment - ShellyForHASS release with the issue: - Last working ShellyForHASS release (if known): - Home Assistant Core release with the issue: - Operating environment (Home Assistant/Supervised/Docker/venv): ## Describe the bug

Steps to Reproduce

Expected behavior

Screenshots

Traceback/Error logs

Additional context

[r0b3rt74]

Same problem here :-(

Please fix it. Thank you!

[robinostlund]

same problem here :/

[robinostlund]

Think this could be related to firmware 1.9 of shelly. Other people in the shelly support group on facebook that also have delays.

[hakana]

How long is the delay? Any errors in log?

[robinostlund]

No errors for me, what i have seen though is that it take around for the coap protocol to return to the server after like turning on a light. I have tested this by tcpdump. But the lights turns on immediately but the it is the state that takes long time to update.

[robinostlund]

Also see this: protocols: mDns, poll

Wondering why coap is not there anymore

[galex80]

I have also strange behaviours for some sensors. E.g. my 2.5 reports Wifi status and temperature permanently, but the cover entity itself is unavailable. Last version, where everything worked perfectly was the 0.2.1 beta 1. Unfortunately i cannot jump back to this beta version. Latest available version is beta 2. The only available log information is: Logger: homeassistant.helpers.service Source: helpers/service.py:464 First occurred: 1:41:29 PM (5 occurrences) Last logged: 1:41:36 PM

Unable to find referenced entities cover.shelly_shsw_25_xxxxxx (ID replaced with x) Edit: All my shellys running the latest firmware 1.9.2

[hakana]

Also see this: protocols: mDns, poll

Wondering why coap is not there anymore

That sounds like something else that causes the CoAP not working. Have you changed something else in your network?

[hakana]

I think this is because of a fault in the 1.9.x firmware, Shelly team saying it will be fixed in the 1.9.3 release.

[hakana]

Also think this will be fixed in firmware 1.9.3, saw a post that the CoAP for Shelly 2.5 was broken in earlier 1.9.x releases.

Why can't you downgrade? Should be possible in HACS by selecting reinstall of the component.

[galex80]

Also think this will be fixed in firmware 1.9.3, saw a post that the CoAP for Shelly 2.5 was broken in earlier 1.9.x releases.

Why can't you downgrade? Should be possible in HACS by selecting reinstall of the component.

I'm sorry, the downgrade was my fault, i've tried it through my mobile device, there i only so 2.1 beta 2, but not the beta 1. But on my laptop i see it. Anyway, when these issues are firmware related, i will wait for this fix. Unfortunately i've updated both (firmware and Shelly4Hass) at the same time, thats why it was not clear, where the issues come from. Thanks for clarification :-)

[hakana]

Anyway, when these issues are firmware related, i will wait for this fix. Unfortunately, I've updated both (firmware and Shelly4Hass) at the same time, that's why it was not clear, where the issues come from.

If you want to test you can downgrade your Shelly firmware using this link: http://archive.shelly-faq.de/

[necromn]

Yeah i'm running the 193 beta firmware on dimmers, 1s, and rgb2 and it hasn't changed anything (specifically 20201202-135844/v1.9.3-rc3@50c6ab57). Since i upgraded to the beta here (0.2.2 beta1) I have also had two Shelly1s become totally unresponsive and require power off restarts. I haven't established cause and effect yet but it happened overnight after I upgraded and had never happened before.

[dace93]

Same issue here. Running the stable 1.9.3 firmware (released today) but issue remains the same. 20201228-092119/v1.9.3@ad2bb4e3

[luuuis]

I've just tested these versions and toggling a single switch:

• 0.2.2.beta.1: lags a few seconds
• 0.2.1: lags a few seconds
• 0.2.0: instant, <0.5 second

My switch is a Plug S running firmware 20201124-092310/v1.9.0@57ac4ad8.

[hakana]

I've just tested these versions and toggling a single switch:

• 0.2.2.beta.1: lags a few seconds
• 0.2.1: lags a few seconds
• 0.2.0: instant, <0.5 second

My switch is a Plug S running firmware 20201124-092310/v1.9.0@57ac4ad8.

What is your protocol attribute saying for different versions?

[necromn]

Ok so turns out I had COAP issues in my network and was running off mDNS and polling. Not sure why it was ever working but anyway.... I have fixed my COAP issues by implementing PIM-SM on my Sophos Firewall which forwards the COAP multicast across the subnets properly. My settings/firmwares are now: Shelly1: 1.9.3 (the final not the beta) Dimmer2: 1.9.3 (the final not the beta) ShellyforHass: 0.2.2 beta1 HASS: 2020.12.2

All of my devices are found and all are instant with no lag. Protocol attributes are all: CoAP-msg, poll

[dace93]

I looked a bit further into this. I'm running a UniFi installation with an USG-3P and a few VLAN's. VLAN1: My data network. My HA server is located here. Subnet = 192.168.101.254/24 VLAN101: My IoT network. All my Shelly and IoT devices are in this VLAN. Subnet = 10.10.101.254/24 IGMP was not configured on my installation. I've enabled it with following commands via SSH:

configure
set protocols igmp-proxy interface eth1.101 role upstream
set protocols igmp-proxy interface eth1 role downstream
set protocols igmp-proxy interface eth1.101 threshold 1
set protocols igmp-proxy interface eth1 threshold 1
set protocols igmp-proxy interface eth1.101 alt-subnet 0.0.0.0/24
set protocols igmp-proxy interface eth1 alt-subnet 0.0.0.0/24
commit ; save
exit
show ip multicast mfc

Updated ShellyForHASS to 0.22 beta1 (was running 0.2.0 where everything worked ok) and everything looks ok now. Will test it the next days.

[luuuis]

What is your protocol attribute saying for different versions?

@hakana I upgraded from 0.2.0 back to 0.2.1 to test this. In both versions the protocols are CoAP-msg, poll throughout the entire test and there are no other changes apart from ShellyForHASS upgrade and HA restart.

I was surprised after the upgrade to 0.2.1 that the response was immediate. However, after a couple of minutes of uptime it regressed to the previous behaviour with the lag. In the logs it is clear that in ShellyForHASS 0.2.1 pyShelly "loses" CoAP connectivity after some minutes.

In 0.2.0 (I removed the CoAP payloads as I don't know if there's anything sensitive in there, let me know if needed):

2021-01-02 22:10:34 DEBUG (Update loop) [pyShelly] Polling block, XXXYYY SHPLG-S
2021-01-02 22:10:34 DEBUG (Poll status) [pyShelly] Get status from XXXYYY ...
2021-01-02 22:10:34 DEBUG (Poll status) [pyShelly] http://10.10.40.8/status
2021-01-02 22:10:34 DEBUG (SyncWorker_6) [pyShelly] http://10.10.40.8/relay/0?turn=off
2021-01-02 22:10:34 DEBUG (Poll status) [pyShelly] http://10.10.40.8/status - Ok
2021-01-02 22:10:34 DEBUG (SyncWorker_6) [pyShelly] http://10.10.40.8/relay/0?turn=off - Ok
2021-01-02 22:10:34 DEBUG (CoAP) [pyShelly] CoAP msg: 10.10.40.8 b'...'
2021-01-02 22:10:34 DEBUG (CoAP) [pyShelly] CoAP msg: 30 10.10.40.8 bytearray(b'...')
2021-01-02 22:10:34 DEBUG (CoAP) [pyShelly] CoAP Code: 30, Type SHPLG-S, Id XXXYYY, Payload *{"G":[...]}*

But in 0.2.1

2021-01-02 22:00:30 DEBUG (SyncWorker_1) [pyShelly] http://10.10.40.8/relay/0?turn=on
2021-01-02 22:00:30 DEBUG (SyncWorker_1) [pyShelly] http://10.10.40.8/relay/0?turn=on - Ok
2021-01-02 22:00:30 DEBUG (CoAP) [pyShelly] CoAP msg: 10.10.40.8 b'...'
2021-01-02 22:00:30 DEBUG (CoAP) [pyShelly] CoAP msg: 30 10.10.40.8 bytearray(b'...')

# after HA has been up for a few minutes...
2021-01-02 22:06:33 DEBUG (Update loop) [pyShelly] Polling block, XXXYYY SHPLG-S
2021-01-02 22:06:33 DEBUG (Poll status) [pyShelly] Get status from XXXYYY Basement - Basement light
2021-01-02 22:06:33 DEBUG (Poll status) [pyShelly] http://10.10.40.8/status
2021-01-02 22:06:34 DEBUG (Poll status) [pyShelly] http://10.10.40.8/status - Ok

And no more CoAP logs. Also the "CoAP Code" message is never logged but I suppose that is down to different logging in pyShelly.

Hope this helps.

[dace93]

I looked a bit further into this. I'm running a UniFi installation with an USG-3P and a few VLAN's. VLAN1: My data network. My HA server is located here. Subnet = 192.168.101.254/24 VLAN101: My IoT network. All my Shelly and IoT devices are in this VLAN. Subnet = 10.10.101.254/24 IGMP was not configured on my installation. I've enabled it with following commands via SSH:

configure
set protocols igmp-proxy interface eth1.101 role upstream
set protocols igmp-proxy interface eth1 role downstream
set protocols igmp-proxy interface eth1.101 threshold 1
set protocols igmp-proxy interface eth1 threshold 1
set protocols igmp-proxy interface eth1.101 alt-subnet 0.0.0.0/24
set protocols igmp-proxy interface eth1 alt-subnet 0.0.0.0/24
commit ; save
exit
show ip multicast mfc

Updated ShellyForHASS to 0.22 beta1 (was running 0.2.0 where everything worked ok) and everything looks ok now. Will test it the next days.

Test after a few days: same issue again. Downgraded to 0.2.0 again.

[Yernike]

I have this problem with shell lags

[poofyteddy]

HI ;) I've updated from the 0.1.9 to 0.2.1 (didn't need to before) and i'm seeing lag to On both the shelly EM and shelly RGBW2, i can have lag up to a 30S It feel like it only update when a pull for status change is done instead of having something instantaneous. I have downgraded to 0.2.0, i can't use my EM on this version but i don't have any delay, and 0.1.9 don't have the 'off' effect causing some issue with rgbw2

[pystha]

Hi, Same problem here with 0.2.1 ( lag 20s+ ) but after downgrading to 0.2 , there is no lag at all. Action and feedback happens instantly.

[Antibrumm]

Hi all

Got the problem too. Just tried it with the version 0.2.2.beta.3 and a Shelly 1.

Turn ON / OFF is instant on the relay itself but the UI switches back to the state before until the next poll fetches the updated status. So the lag can take up to 1 minute (poll-interval).

Here's a debug log. Hope it helps:

2021-03-05 16:15:17 DEBUG (SyncWorker_2) [pyShelly] http://192.168.1.136/relay/0?turn=off 2021-03-05 16:15:17 DEBUG (SyncWorker_2) [pyShelly] http://192.168.1.136/relay/0?turn=off - Ok -> Here HASS switches back to show OFF

2021-03-05 16:15:54 DEBUG (Update loop) [pyShelly] Sending CoAP discover UDP 2021-03-05 16:15:54 DEBUG (CoAP) [pyShelly] CoAP msg: 192.168.1.3 2021-03-05 16:15:54 DEBUG (CoAP) [pyShelly] CoAP msg: 1 192.168.1.3 2021-03-05 16:15:54 DEBUG (Update loop) [pyShelly] Polling block, 483FDA944096 SHSW-1 2021-03-05 16:15:54 DEBUG (Poll status) [pyShelly] Get status from 483FDA944096 Shelly 1 - 483FDA944096 2021-03-05 16:15:54 DEBUG (Poll status) [pyShelly] http://192.168.1.136/status 2021-03-05 16:15:54 DEBUG (Poll status) [pyShelly] http://192.168.1.136/status - Ok -> Here HASS switches to show ON

[H0nzik1]

Any progress to fix this bug? I have it too! Thanks!