Troubleshooting delay for Shelly device - Caused by Hubitat pinging the device

I've been having issues with a couple of my Shelly devices (using built-in Hubitat drivers) recently. It was originally picked up by my wife who mentioned it one day so I'm unable to fully pinpoint when it started, and at first I thought it was hub resource related, but I graph hub resources in Grafana and couldn't correlate anything here. As time has gone on, this delay is starting to drive everyone in the family insane.

It seems to have started occurring since updating to either 2.3.4.x or 2.3.5.x, as I was running 2.3.3.x for a very long time without issue, but I needed to upgrade to fix a few other things.

The setup I have is a C5 in vlan X and my Shelly devices are in vlan Y. The specific shelly devices I am having issues with are the ones that are in "detached" mode which means that any action taken upon a switch press is essentially handled by Hubitat (specifically button controllers), rather than the switch directly controlling the relay.

What we are seeing is that after a unknown period of time of not using the physical switch, the first use of the physical switch has a delay of approx. 3-5 seconds. Once that first use of the switch has finally gone through after the initial delay, then all subsequent uses of the physical switch work with almost instantly.

After lots of trying to debug many different configs (and firmware updates) in Hubitat and the Shelly itself, all with no improvement, I decided to switch my focus to seeing where the actual delay was being introduced by doing a wireshark capture and this has revealed where the problem may be.

It appears that when activating the physical switch (after an unknown period of time), the Shelly is sending the GET request as it is configured to do so, but Hubitat doesn't respond straight away with HTTP 200. Instead the Hubitat sends a couple of ICMP requests to the Shelly device, and only after the pings have completed does Hubitat respond to the HTTP request with a 200 response code.

Here is the wireshark capture showing the behaviour

So it appears that Hubitat is doing some sort of health/liveness detection before it will process the request. Next is a capture of the same process (using the same physical switch) just 8 mins later and there was no delay seen when I was pressing the switch to when the light turned on. You can see that Hubitat in this instance does not try to ping the shelly and returns a HTTP 200 in milliseconds.

I assume that Hubitat is pinging the device before processing the request to validate the endpoint actually exists and isn't being spoofed (i.e. a security measure). How long is the "validity" of this check before it times it out and Hubitat will want to ping the device again when it receives the next request?

Can this behaviour be fixed/changed as its currently driving us insane.

1 Like

@bobbyD Is this something you can look into please? Or how can I log an official support ticket to get this fixed.

I wonder, do you have the issue when you put the Shelly and the hub it in the same Vlan?

I'm seeing the same described behaviour from my Shelly 2.5, with the hub on Ethernet.

As a test, I moved one of my problematic Shelly devices back to the same vlan as the hubitat and it now doesn't exhibit the same delay as it had before.

Based on a previous post by @mike.maxwell in Custom Device Network Id (DNI) for Shelly device gets overwritten after clicking save preferences there is some logic in the built in drivers to reach out to the shelly device itself. I wonder if this is part of the issue.

I'm not too keen to move the Shelly devices onto the same vlan as the hubitat as I had them completely isolated and without internet access.

Actually, scratch that, I just came down this morning and hit the switch to the problematic Shelly (which is now in the same vlan as the hubitat) thinking it was fixed, and I was hit with the dreaded delay again.

Obviously I didn't leave it long enough when I did my testing before, so will now go through the process again of capturing the packets first thing in the morning so I know the switch hasn't been used in over 12 hours.