I think there is a problem that needs to be investigated. Wyze Plug V1 in multi-access point environment, The scenario is consumer grade wifi, primary router with built in wifi access point and DHCP enabled on this device. Then there is a secondary router, with DHCP disabled and using just as an access point. Both routers have the same SSID. When the primary router reboots, the problems begin. It appears that the plugs cannot roam (standard wi-fi client feature), The Wyze plug instead experiences a disconnect and then it attempts to reconnect without DHCP being reachable from the secondary AP. Normal clients would roam to the next AP, but in this case, the Wyze Plugs will go into pairing mode.
I think Wyze need to look into this and examine the logic
My speculative evaluation of this (also posted on the redit Linked):
I think it’s a timeout issue and they go into pairing mode (flashing blue light). I think that a plug that is configured, should never go into pairing mode unless manually put into that mode. They should indefinitely attempt to connect to the configured wi-fi network.
I think it’s most evident in a multi-AP environment where DHCP address cannot be assigned to the client. Typically, a client should roam to the other AP without need to check-in with DHCP. I think in this case, the device doesn’t roam. Instead it likely experiences a ‘disconnect’ and then upon reconnect, the need to communicate with DHCP creates an issue and then it decides (timeout) it is on a network with no DHCP and goes into pairing mode.
In the absence of DHCP, client should use previously assigned IP address and continue to use DHCP half-life timer logic.
Workaround 1: Tweak (play with) the reboot schedules on each router.
Workaround 2: Add secondary DHCP that is up when the primary router (with DHCP) is down. This way, when re-connect occurs (should be a roam without need for DHCP), the plug can pull an IP address. Caution: When adding secondary DHCP, need to ensure gateway IP is the correct gateway IP, not IP of the secondary AP. Also, secondary DHCP likely needs to be a separate range of IP addresses, as these low tech DHCP servers on routers, there would be IP address conflicts likely. You need a more advanced DHCP environment to avoid this kind of issue. You’ll see clients split between both DHCP servers during the normal course of day to day usage. Added benefit of some amount of redundancy.
Workaround 3: Make DHCP separate to the router/AP, i.e. DHCP always up when APs reboot. Need to ensure that you don’t use the main router switch ports else secondary AP has no connectivity to DHCP server when primary router reboots.
Mostly kidding. I was able to ‘follow’ your nicely wrought post and that scares me a little. What have we (or at least I) got ourselves into with this internets of thing thing?
I long ago moved off the DHCP on my wifi router as being too limited. Right now I have two subnets managed by my Ubiquiti wired router (guest and IOT). I have a dedicated Raspberry Pi running DHCP for my main network. Could move that to the Ubiquiti as well but would need to manually recreate the scope which is somewhat extensive with many reserved IPs.
I don’t need to reboot my wifi regularly, but I do have one router/AP that goes offline regularly due to some power interference. That doesn’t affect DHCP since I run it on the main router.
As a quick update, on the network where I have these problem Wyze Plug v1 devices, I have implemented workaround 2. To recap, and with some more specifics, that’s two wifi routers running dd-wrt with same SSID. router 1 has all typical services enabled. router2 now has dhcp enabled (was previously disabled), unique IP pool to avoid conflicts, and has additional DHCP option (non-default and requires reboot) to update default gateway for DHCP clients to the IP address of router1. I disabled DHCP server on router 1 to verify the configuration on router2 was working correctly.
With DHCP server enabled on both routers and various reboots of each router to test, both plugs currently have an IP from DHCP server 1. The advantage of this configuration is that during a reboot of either router/AP, newly connecting clients will be able to pull an IP address, so there is overall improved resiliency.
I’ll monitor next and see if the plugs behave during the weekly scheduled reboots.
It’s not the first time I’ve seen WiFi clients that are far from perfect and I’m sure it won’t be the last.
The speculative lesson here, is that for a multi-AP, home grade WiFi environment, DHCP is potentially an area where robustness is missing and needs to be added.
I had my scheduled, weekly reboots and both plugs didn’t survive. Both with flashing blue light (pairing). The access point reboot were 15 minutes apart. So the speculative workaround 2, that I implemented, seems not to have worked. This is a head scratcher as the manual access point reboots don’t appear to reproduce this problem.
There is the possibility this is related to DHCP Authorititive. I have disabled on both DHCP servers. I have also created a static DHCP lease for each plug (on both DHCP servers). After a reboot DHCP lease are otherwise erased on consumer routers (and dd-wrt), so there may also be benefit from ensuring a static address, via DHCP reservation. I have some more testing to do.
