Rebooting each night could dramatically improve the network channel adaptive selection and thus the mesh performance.

No disrespect to the user who suggested this feature, I am sure the intention is good, but I don't think it's the right solution to the problem at hand.

 

How can an arguably low value feature (will explain bellow) with only 15 votes (over 4 threads, including this one and  https://community.tp-link.com/en/home/forum/topic/591766, https://community.tp-link.com/en/home/forum/topic/590078, https://community.tp-link.com/en/home/forum/topic/212200) get picked up for consideration before CRITICAL functionalities with tons more votes be set as "Future Consideration" with no movement for over a year?

 

Example of such features:

WAN/LAN auto-sensing (63 votes): https://community.tp-link.com/en/home/forum/topic/273992

Web UI Configuration (43 votes): https://community.tp-link.com/en/home/forum/topic/531350

Possibility to change WiFi channels (55 votes): https://community.tp-link.com/en/home/forum/topic/156515

Feature Request - Guest Network separate DHCP/DNS settings (53 votes): https://community.tp-link.com/en/home/forum/topic/259432

 

How is the product owner choosing what to work on? What's the point of voting for any of that?

 

Anyhow, here is why I consider scheduled reboot to be low value:

Typically scheduled reboot are used to work around an issue. The one mentioned here is improving the network channel adaptive selection. If this is the issue to address, then the suggestion should be "Improve channel adaptive selection", not gimme scheduled reboot. I could imagine a process scanning every so often (or on schedule) the state of the network to make adjustments, but scheduled reboot is not the right solution.

 

Other common use of scheduled reboot include unit stability or performance, but again, this is a way to work around issues that should get fixed at the source.

 

Short of a quick workaround, there are no valid usecase that comes to mind with scheduled reboots.