Get online support
I've recently added some 2.4GHz IoT devices (Cygnett Wi-Fi Smart Plugs) to my network, and whilst they work fine during the day, something is happening overnight causing them to be disconnected then next morning (happens every day). I have tried various different static wifi channels (after doing a site survey) and this makes no difference.
I've reached out to TP-Link and they said "Sorry that Archer VR1600v v2 is a customized model and we are not responsible for the troubleshooting or RMA and we are also not familiar with this model. Please contact TPG for help."
Looking at the VR1600v logs, the last reference for one of the device MAC addresses I can see overnight is:
2020-10-02 04:26:46 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:26:46 [5] DHCPD: Send ACK to 192.168.1.109
2020-10-02 04:32:23 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:32:23 [5] DHCPD: Send ACK to 192.168.1.109
2020-10-02 04:35:12 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:35:12 [5] DHCPD: Send ACK to 192.168.1.109
2020-10-02 04:36:36 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:36:36 [5] DHCPD: Send ACK to 192.168.1.109
2020-10-02 04:37:18 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:37:18 [5] DHCPD: Send ACK to 192.168.1.109
2020-10-02 04:37:39 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:37:39 [5] DHCPD: Send ACK to 192.168.1.109
2020-10-02 04:37:50 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:37:50 [5] DHCPD: Send ACK to 192.168.1.109
2020-10-02 04:37:55 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:37:55 [5] DHCPD: Send ACK to 192.168.1.109
2020-10-02 04:37:58 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:37:58 [5] DHCPD: Send ACK to 192.168.1.109
2020-10-02 04:38:01 [5] DHCPD: Recv DISCOVER from 24:6F:28:68:58:84
2020-10-02 04:38:01 [5] DHCPD: Send OFFER with ip 192.168.1.109
2020-10-02 04:38:01 [5] DHCPD: Recv DISCOVER from 24:6F:28:68:58:84
2020-10-02 04:38:01 [5] DHCPD: Send OFFER with ip 192.168.1.109
2020-10-02 04:38:02 [5] DHCPD: Recv DISCOVER from 24:6F:28:68:58:84
2020-10-02 04:38:02 [5] DHCPD: Send OFFER with ip 192.168.1.109
2020-10-02 04:38:04 [5] DHCPD: Recv DISCOVER from 24:6F:28:68:58:84
2020-10-02 04:38:04 [5] DHCPD: Send OFFER with ip 192.168.1.109
2020-10-02 04:38:08 [5] DHCPD: Recv DISCOVER from 24:6F:28:68:58:84
2020-10-02 04:38:08 [5] DHCPD: Send OFFER with ip 192.168.1.109
2020-10-02 04:38:13 [5] DHCPD: Recv DISCOVER from 24:6F:28:68:58:84
2020-10-02 04:38:13 [5] DHCPD: Send OFFER with ip 192.168.1.109
2020-10-02 04:38:13 [5] DHCPD: Recv REQUEST from 24:6F:28:68:58:84
2020-10-02 04:38:14 [5] DHCPD: Send ACK to 192.168.1.109
And nothing else after that.
Any ideas?
Hi chicaneau.
Regarding the site survey, did you measure the signal strength at each plug on different channels? Channel 1 or 6 or 11 is best. Did you notice any outside networks that could interfere with yours?
Do any other devices (mobile phone, tablet) have any problems staying connected on 2.4G?
What is the distance between router and smart plugs? Have you tested these plugs up close to the router to see if they stay connected?
Do you reserve an ip address for each plug or do they get an address from the pool of addresses?
In the Archer config, can you change the DHCP lease time to 2880 (48 hours) and see if that makes a difference. (Advanced>Network>LAN Settings)
Do all the plugs go through that sequence in the log at the same time each morning or are they scattered across the day?
The proper DHCP sequence is: Discover, Offer, Request, Ack. The plug that got dot 109 should have been connected at the end of the log.
Hi David64,
The 2.4GHz spectrum is quite congested where I live (apartment block). I did the site survey at multiple locations (where the plugs were). The timing seems somewhat random, I've just re-connected them this morning and will monitor them today and see how long they stay on for.
Other devices work OK on 2.4GHz (albeit slower than 5GHz). Distance from router can be 1M or the other end of the apartment, same difference. I have set DHCP reservations in place (so it gets the same IP) and extended the lease time this morning (1 day now 2 days - can't see this making a difference).
Others have complained of the same issue and have resolved it by disabling a feature called "Airtime Fairness" (ATF), however this does not appear as an option in the customised TPG device (Archer VR1600v) - https://community.tp-link.com/us/home/stories/detail/203
Cheers