What does shelly say? You probably did make use of their official firmware? 
Maybe give esphome a try which allows to have a fallback wifi with captive portal in case a fatal router reset kicks in again 
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”
2 Likes
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 
Maybe try not spread missinformation and FUD in this case?
Little fact check: Over 100 esp(home) devices with a combined 2.4+5GHz SSID with 
(that’s zero) problems 
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
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. 
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.
It is the other way around, coiot for gen 1, websocket for gen 2/3.
Same here.
I cannot imagine a scenario where having the same WiFi credentials for both 2.4 and 5GHz can cause any device from connecting.
Then you haven’t been around much.
1 Like
Sounds very much like it. Did you yet try to install esphome on your shelly to see if this fixes thing? 
Luckily esphome features everything you need