Do Shelly Devices have a fatal weakness (Router Reset)

Yesterday, I had to perform an emergency factory reset of my ASUS XP4 router. To minimize disruption, I set the same SSID and password for both the 2.4GHz and 5GHz networks. The good news is that most of my devices weathered the “router reset storm” without any issues—except for my brand new Shelly 1 Plus relay.

I have over 20 user devices (iPhones, PCs, iPads, desktops, Amazon devices) that all reconnected smoothly, as expected. Additionally, all of my home automation devices—Reolink cameras, Sonos speakers, Rachio sprinklers, and Hue lighting—recovered from the reset without a problem. Even my 25 Aqara Zigbee devices connected to a Conbee hub survived the factory reset without a hitch.

However, the Shelly 1 Plus was the only device that failed to reboot and come back online after the router reset. It went offline and stayed that way. To bring it back, I had to perform a factory reset of the device, which required cycling the 110V power to the relay five times. What a fantastic user experience that was.

Considering that all the other devices recovered without issue, while the Shelly 1 Plus didn’t, I now regard the Shelly as a marginal device at best. I read a post on Reddit suggesting this might be a common issue with Shelly devices.

Am I missing something fundamental, or does a factory reset/router replacement force a factory reset of the Shelly relay? I had planned to buy 8-12 Shelly relays of various types and place them behind wall switches, but having to mess with 110V power just because I upgraded my router is making me reconsider my purchase plans.

No.

There is so much (likely) wrong with your post that there is no answer. You started with a conclusion and imagined every way possible to make the conclusion true.

I have already answered the question in the topic. No. Shelly devices are quite reliable.

I have over 100 devices. So, what?

What is an “emergency factory reset”?

What firmware is on the Shelly? (Shelly App, ESPHome or Tasmota)?

Why not just use smart switches?

2 Likes

Some time ago I changed my access points (also from Asus). I set the same SSID and password on the new ones and the Shelly devices connected to the „new” network without any problems.

There’s your problem right there. Most ESP devices, including the Shelly, absolutely do not like having a shared SSID between 2.4 & 5GHz.

Not sure whether it’s still the case nowadays, but these devices will usually make it pretty clear in their manuals that you have to separate your wifi bands into different SSIDs in order for them to be able to connect.

1 Like

What does shelly say? You probably did make use of their official firmware? :thinking:

Maybe give esphome a try which allows to have a fallback wifi with captive portal in case a fatal router reset kicks in again :face_with_hand_over_mouth:

Explain why this should matter.
If the ESP can only see 2.4 GHz networks, how does it know there is a 5 GHz with the same SSID?
This makes no sense what so ever.
Or are you talking about MLO? Still does not make sense, but I could possibly see that there is some data in the communication saying “oh. there is a 5 GHz network called… also”

1 Like

I don’t see a need to explain myself. This warning is frequently written on ESP device manuals (not just Shelly) and I’m just passing the info along.
What goes on underneath the hood is beyond my area of expertise, but there’s plenty of posts in the Shelly Support Group on FB where people ran into the same issue and could only get them to connect once the networks were segregated.

It is not the Shellies, that are the issue here, but the APs.
The APs will often try to kick a 2.4Ghz device off the AP and bar it from connecting again on the 2.4Ghz band for some time to see if it then try to connect to the 5Ghz instead.
Dual band devices will be fine with this, but 2.4Ghz-only devices might not. Some 2.4Ghz-only devices will continue to try to get on the 2.4Ghz band again and succeed when it becomes available, but others just give up before the AP “re-open” the band again.

4 Likes

Um… See this is an issue.
This is why rumors and missinformation spreads.
Hiding behind “I don’t need to take responsibility” is not a good approach and is the core reason why there is a lot more talk about fake news and you should fact check things.
I’m not saying everything has to be 100% backed up, but saying that an antenna specifically made for 2.4 GHz can see and read the data of a 5 GHz is pretty far out there.

Wallys explanation sounds a lot more reasonable.

2 Likes

Looks like you are :point_down:

Maybe try not spread missinformation and FUD in this case? :thinking:

Little fact check: Over 100 esp(home) devices with a combined 2.4+5GHz SSID with :zero: (that’s zero) problems :bulb:

But (that’s the tiny truth @ShadowFist you probably wanted to share…) is some vendors have shitty apps using shitty techniques to onboard devices. In short you have your phone connected to the 5GHz network and try to onboard a 2.4Ghz which is simply not possible :point_down:

Important thing: This is not a limitation of a device (like esp’s that a perfectly capable “living” in environment with 2.4/5GHz shared SSID’s) but simply the (poor) on-boarding/provising process (often based on smart config) that many commercial products use. :put_litter_in_its_place:

I told you already where to find the info:

In case you couldn’t be bothered to search, here you are. Hopefully this isn’t a “rumour and misinformation”:
https://www.marketcom.eu/sonoff-smartwise-shelly-EU-wholesale-distribution/faq-shelly-devices/

Here too:

Yes, Wally’s explanation does sound more reasonable, mostly due to the fact that he clarifies that both the router and the end devices need to be considered.
Given that the op can’t change the Shelly’s behaviour, I pointed him to something that was within his control.

Maybe read the entire sentence instead of quoting selectively. Nothing worse than cherry picking 2 words out of a 3 row sentence.

Also, both of you - I believe the word you’re looking for is “misinformation”. You’re welcome.

Why would I? I asked you to declare YOUR source.
Are you saying I should search for your source?

And don’t forget that what Wally said, and the source (image) you posted says the exact opposite as you did.
You said it was the end device that was the issue. But in reality it was the router.

Which I explained with:

Since apparently no one can be bothered to read before quoting, I’m out of this thread.

I am not using an MQTT installation. I installed and managed the device via the Shelly app. By the way, Home Assistant worked perfectly and recognized the Shelly devices as expected in all instances. This issue appears to be primarily a “Shelly app issue.”

When I reset the router, I kept the same router password. The 2.4 GHz and 5.0 GHz bands have always had unique and different SSID names. After the reset, I maintained the original SSID names for both bands for consistency, so there was no shared SSID naming issue.

As I mentioned earlier, this is a Shelly app issue. After the router reset, the app showed the relay(s) as disconnected. The app attempted numerous times to negotiate the connection, but it would fail at the very last step, “establishing WIFI connection.” The only way to resolve this was through a factory reset and power cycling, which was suggested by the Shelly app after it failed to connect.

This is not an isolated issue. Several similar incidents with identical hard failures were reported on Reddit.

Just having the same SSID and passphrase for your WiFi is not enough.
You need to have the same encryption algorithm also.
Newer APs might support WPA3 and your old one might only support up to WPA2. This affects the encryption protocols available.

1 Like

Wally R : Agreed, this is exactly what happened to me. When the encryption didn’t match, the connection between the device and router was broken. The key issue is that I was unable to use the Shelly app to rescan and reconnect the device to the router. Instead of providing a way to log back into the device, Shelly’s guidance was to power cycle the relay five times and perform a factory reset.

Given that my use case involves placing the relay inside a somewhat crowded junction box, having to power cycle the relay after a router failure is a nonstarter for me. This is an issue that should be addressed within the Shelly app. As mentioned earlier, all my other devices came back online without issue.

I was reading this post before I asked the question about Shelly’s reliability with WiFi, and I can confirm the original initial poster’s observation. If I restart my APs (UniFi’s), then the Shelly’s either take a long time to reconnect, or I have to do a power reset. I’ve opened tickets with both Shelly and Unifi and followed all their recommendations. All my other IoT and other Wifi endpoints connect with no issues. I have a mix of Shelly, TP-Link, Broadlink, and ESP devices. I feel it’s a Shelly issue, but that’s just my opinion.

The truth may be somewhere in the middle. I did have shelly connectivity issues but once I came up with this all my issues have gone away and the connections have been rock solid for over a year now, with router reboots, etc., etc.,:

Make the IP address static - on both the Shelly and your router for said shelly device.
For every single Shelly Gen 1 device, set up COIOT
For every single Shelly Gen 2/3 device, set up outbound websockets

I have a robust WiFi network with hundreds of devices as well and 3 vlans, the IOT vlan (al the Shelly’s are here) on purpose is only 2.4ghz.

Kruseluds: thanks for the thoughtful reply. I did install COIOT on the shelly Relays. I did not implement a static IP.

Tomorrow I plan to reset the router, prior to the reset, I will setup static IPs. This will match your efforts to make the connection more robust. I will post the results whatever they might be…

Question, Is your primary interface to the Shelly via MQTT or the Shelly APP. My basic issue is the Shelly APP has no builtin recovery process when the connection is lost.