This is getting a bit out of scope, as we are trying to troubleshoot the Shelly and not OpenWrt.
You are not wrong. You should be looking at the dhcp server leases though and not in wireless associated stations.
2 Likes
I looked at the active leases, the 2 Shellys and the son off aren't listed on there, even though they are connected, I'm just not sure if it is a problem with the devices themselves, could that be? That the MAC address is somehow messed up?
There are 2 explanations for the dhcp leases not to appear.
Either the router was rebooted and the lease file was lost, because it resides in /tmp, or the devices never requested a dhcp lease. Other than that I cannot help as I have no experience with Shellys or Sonoff.
4 Likes
So what I did now, is that I connected another router to my Wrt3200acm and configured it as an AP, the WRT still does the DHCP, I managed to connect both Shelly switches and the Sonoff switch, I work without a problem even with a static IP, is is very strange... I think the best solution would be to just get a raspberry and set it up as an AP for all the smart home devices, or can anyone think of a better solution?
I had the same kind of problems with a Shelly H&T sensor, Linksys WRT3200ACM and OpenWrt 19.07.03. Then I connected a Netgear EX3700 (range extender) as a secondary access point and everything worked fine.
The EX3700 uses the same OpenWrt version 19.07.03 as the WRT3200ACM. DHCP is served by the WRT3200ACM, So I assume it's some incompatibility between the WLAN of the WRT3200ACM and the Shelly.sensor.
Hi,
I do have the same problem with a "Shelly Plug S", also with a Linksys WRT3200acm (running OpenWrt 19.07.7 r11306-c4a6851c72):
The Shelly Plug connects to the Wifi, authenticates successfully, but never seems to request a dhcp lease - it then keeps reconnecting every 30 seconds:
Thu Jan 13 14:22:55 2022 daemon.info hostapd: wlan1: STA e8:68:e7:c5:07:ce IEEE 802.11: associated (aid 1)
Thu Jan 13 14:22:55 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED e8:68:e7:c5:07:ce
Thu Jan 13 14:22:55 2022 daemon.info hostapd: wlan1: STA e8:68:e7:c5:07:ce WPA: pairwise key handshake completed (RSN)
Thu Jan 13 14:23:24 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED e8:68:e7:c5:07:ce
Thu Jan 13 14:23:24 2022 kern.debug kernel: [2009008.041936] ieee80211 phy1: staid 1 deleted
Thu Jan 13 14:23:24 2022 daemon.info hostapd: wlan1: STA e8:68:e7:c5:07:ce IEEE 802.11: associated (aid 1)
Thu Jan 13 14:23:24 2022 daemon.notice hostapd: wlan1: AP-STA-CONNECTED e8:68:e7:c5:07:ce
Thu Jan 13 14:23:24 2022 daemon.info hostapd: wlan1: STA e8:68:e7:c5:07:ce WPA: pairwise key handshake completed (RSN)
Thu Jan 13 14:23:54 2022 daemon.notice hostapd: wlan1: AP-STA-DISCONNECTED e8:68:e7:c5:07:ce
Thu Jan 13 14:23:54 2022 kern.debug kernel: [2009038.065315] ieee80211 phy1: staid 1 deleted
When I assign a static IP it isn't reachable. I first thought that the Shelly Plug is broken, but I was able to connect it to a different Wifi access point without any issues. I then tried to change several wifi settings, like channel, channel-width, security settings (WPA, WPA2, passphrase, etc...) - no luck.
Eventually, I got it working by creating another wifi network on radio2 (Marvell 88W8887 802.11bgnac): Same settings, except for SSID and channel width (setting not available). I have no idea why the Shelly Plug doesn't want to properly connect to radio1 (haven't had any issues with other clients so far), but at least I found a workaround for me.
In Interface Configuration->General Setup, ensure "WMM Mode" is disabled.
1 Like
Which comes at a cost. WMM is a hard requirement of 802.11n, so without it, you're limited to 54 MBit/s max (802.11g).
Deactivating WMM is, apparently, a hard requirement for having Shelly devices recognized on the network.
Just dedicate one of the Linksys router's 3 radios to handle the Shelly sensor traffic. 54 Mbps should be ample.
No, it's not. WMM works fine on any other wireless chipset with those devices (Espressif esp8266/ esp32), it's only mwlwifi being broken - news at 11.
If 2.4 GHz coverage (and its performance!) doesn't matter for you for anything other than those IoT devices, that might be a price you're willing to pay, but for many others having decent 2.4 GHz speed does matter as well (wifi based video surveillance cameras, having wifi coverage in the garden, older devices, etc.). There is a difference between having and aggregate throughput of ~11-12 MBit/s or 1.8-3.0 MBit/s over wifi, the former can still works reasonably well, the later not so much.
Edit: The traffic class priorization WMM brings you shouldn't be underestimated either, which can make the difference between succesful VoIP calls, interactive video conferencing and similar. Even today you can find lower end tablets, VoIP handsets and surveillance cameras (both of which need it for the range), handheld gaming consoles and TV streaming receivers that are 2.4 GHz only (or predominantly, for the range/ wall penetration capabilities), which do need more than the 54 MBit/s of 802.11g.
While that might be a tradeoff you might be willing to pay for your setup, it still remains an unfixed bug in mwlwifi - not a problem with WMM itself (again, it works everywhere else).