Any way to force an optimisation at a time after automated reboot

[Jong]

So, this shouldn't really be a problem but it is and I'm looking for a workaround!

I have 2 AX88s with wired backhaul and one Zen Mini with 5Ghz backhaul (no wired internet available) pushing WiFi into one room the other 2 only marginally reach.

The Zen is significantly closer to the secondary AX88 node than it is to the AX 88 router and optimization will always choose to daisy chain the Zen off this secondary node. To try and ensure this happens I have set this secondary node as the Zen's preferred WiFi uplink.

However, sometimes the Zen will end up connected and sticking to the router instead after a reboot, even though it has a "weak" signal around -87dB. If I manually optimise it connects to the secondary node with signal strength of -62dB.

Of course I feel this should happen automatically. No way it should stick with such a suboptimal configuration even if I hadn't already told it to prefer the other node! But, is there a way of scripting a scheduled reboot and subsequent optimisation? I should say, although technically literate, I have never set up scripts on these boxes.

 

[L&LD]

How much time have you allowed after a reboot to see if it doesn't already go there itself?

 

[Jong]

Scheduled reboot is at 4am. I noticed at 9am the Zen node was still connected to the main router with a "weak" connection. One press of the optimisation button and it was fixed.

Evidence suggests the router was the first box to come back after the reboot, the Zen connected to it as the only node available and then never reappraised .

 

[L&LD]

Disable the scheduled reboot. Fix the core issue if that reboot is actually 'needed'.

 

[Jong]

Just not helpful. But thanks for reading!

 

[L&LD]

Yes, that is very helpful. If you follow through.

Can't hurt.

 

[Jong]

OK, so let's try your approach for the moment.

Core problem is mDNS packets stop propagating around the mesh after a period of time meaning devices eventually cannot find each other. It is reported widely here and elsewhere. Reboot will fix for a while, sometimes days. Scheduled reboots do not guarantee things do not fall over between reboots but they mostly do. So far not found any other answers to this. The general opinion seems to be "yeah mesh systems, just about all of them, handle this badly."

Or the next level of core problem, the "mantle" problem if you will, is Aimesh does not do it's job on restart. If Aimesh nodes either optimised themselves when they have a weak signal or at least reliably followed the "preferred WiFi uplink setting" then at least a workaround script would not be needed.

So, do you have a solution to either of those problems or does "fixing the core problem" involve travelling to Taiwan, somehow getting a job with Asus and fixing one or both those problems at source, because that sounds quite a long term strategy with low chance of success.!

 

[L&LD]

Your assumptions are not what would be 'my approach'.

Good luck.

 

[Jong]

Insightful. Thanks.

 

[L&LD]

What is insightful is that this thread has over 260 views, I'm the only one who tried to help, yet you are still ungrateful.

 

[miniterror]

Maybe its conencting to the main node as the secondairy node isnt fully booted into the AI-Mesh yet, hence the Zen falls back to the main unit.
You could try to use a timed power outlet and let the Zen reboot another time after the entire system is back up and running, so a short powercut on the Zen at 04:15.
Nothing else i can think off in getting what you want.
Assuming you already force connected the Zen to the secondairy unit with the bind button.

 

[toaruScar]

"Poor man's optimization": ssh into the mesh node, and use wl deauthenticate to diconnect the main router.