Wireless Report Wireless Report AiMesh v1.5.4 [2026-Apr-23] - WebGUI Table of all AiMesh connected devices (available in AMTM!)

[JB_1366]

Hmm.. OK, thx for letting us know; bit of a heads up for those with the refresh interval, if they just want a one-off kick.
btw great jop on select from a MAC exclusion list based on what is already reported, that works super well!

whats funny is, ive only ever used auto-refresh for testing. do people use auto-refresh alot?

 

[scootertramp]

whats funny is, ive only ever used auto-refresh for testing. do people use auto-refresh alot?

Same here. I use auto-refresh for testing some of your new features.
Normally I just leave it manual.

 

[jksmurf]

Same here. I use auto-refresh for testing some of your new features.
Normally I just leave it manual.

Me too.

 

[Untried3868]

do people use auto-refresh alot?

Only when I'm observing the network. Reset to manual before logging out of the router GUI (is that even necessary?).

 

[JB_1366]

Only when I'm observing the network. Reset to manual before logging out of the router GUI (is that even necessary?).

no, not necessary

 

[scootertramp]

no, not necessary

Just be aware that if you have WirelessReport on auto refresh when you leave.
It will be on auto-refresh when you return to the page. I like that it maintains last state.
Just need to check if it's set to what you prefer upon return.

 

[scootertramp]

Auto-refresh: A cautionary tale.
Not sure what the issue is yet, but most likely it was my mesh node.
Possibly could use some defensive coding to prevent crushing the main router.

When I went to re-test kick with the same device I used with the previous test, but this time with it not
being bound to the mesh node. The mesh node appears to have not responded to the kick commands.
Luckily metrics reported on the wirelessreport page made me aware of the issue. CPU temp went into warning 70C and
Load was at 9.0. All four cores were spinning at 100%.

I found multiple connections to the mesh node still running and refresh process taking longer than normal.

NORMAL REFRESH:

2026-04-23T07:43:44.000000-04:00 rt-be88u rc_service: httpds 30588:notify_rc restart_wireless_report
2026-04-23T07:43:44.000000-04:00 rt-be88u custom_script: Running /jffs/scripts/service-event (args: restart wireless_report)
2026-04-23T07:43:46.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-23T07:43:50.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...

Had to kill the connection attempts to get back to normal CPU levels.

agagne@rt-be88u:/tmp/mnt/rt-be88u/entware/var/log# ps -w | grep dropbear
 2997 agagne    6024 S    grep dropbear
 4351 agagne    3856 S    dropbear -p xxxx -j -k
15997 agagne    3984 R    ssh -p xxxx -i /tmp/home/root/.ssh/id_dropbear [email protected]        if command -v wl >/dev/null 2>
18641 agagne    3984 R    ssh -p xxxx -i /tmp/home/root/.ssh/id_dropbear [email protected]        if command -v wl >/dev/null 2>
23782 agagne    3984 R    ssh -p xxxx -i /tmp/home/root/.ssh/id_dropbear [email protected]        if command -v wl >/dev/null 2>
23834 agagne    3984 R    ssh -p xxxx -i /tmp/home/root/.ssh/id_dropbear [email protected]        if command -v wl >/dev/null 2>
25745 agagne    3984 R    ssh -p xxxx -i /tmp/home/root/.ssh/id_dropbear [email protected]        if command -v wl >/dev/null 2>
26735 agagne    3984 S    dropbear -p xxxx -j -k
27524 agagne    3984 R    ssh -p xxxx -i /tmp/home/root/.ssh/id_dropbear [email protected]        if command -v wl >/dev/null 2>
29057 agagne    3984 R    ssh -p xxxx -i /tmp/home/root/.ssh/id_dropbear [email protected]        if command -v wl >/dev/null 2>
agagne@rt-be88u:/tmp/mnt/rt-be88u/entware/var/log# kill -9 15997 18641 23782 23834 25745 27524 29057

Not surprisingly refresh times were extended.

2026-04-22T20:28:22.000000-04:00 rt-be88u rc_service: httpds 30588:notify_rc restart_wireless_report
2026-04-22T20:28:22.000000-04:00 rt-be88u custom_script: Running /jffs/scripts/service-event (args: restart wireless_report)
2026-04-22T20:28:23.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:28:26.000000-04:00 rt-be88u Wireless Report: [XT8DOWN] Kicking 16:67:22:16:E9:71 on wl1.1 (-73 dBm)
2026-04-22T20:28:27.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:28:31.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:28:35.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:28:39.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:28:43.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:28:47.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:28:51.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:28:55.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:28:59.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:03.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:07.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:11.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:15.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:19.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:23.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:27.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:31.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:35.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:39.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:43.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:47.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:51.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...
2026-04-22T20:29:55.000000-04:00 rt-be88u rc_service: waitting "restart_wireless_report"(last_rc:restart_wireless_report) via httpds ...

 

[Wheemer1]

My nodes don't show anything, they are both RT-AX1800S

 

[jksmurf]

Not sure what the issue is yet, but most likely it was my mesh node.

Check your devices being kicked and devices being ignored; if you have a ghost wireless connection (and I have had a few due to laggy sequences of Main vs Node startups, despite the Wired being shown as a Great connection) I had some issues with WR for the node not showing the clients (even though ASUS network map did). Something to check.

 

[JB_1366]

Just a reminder for people using RSSI kick threshold, *** USE AT YOUR OWN RISK ***, if to unstable with auto refresh on, i would disable. I think kicking is meant to be a one off, who knows how asus software responds to multiple kicks in a row. It works great for me, but i dont use auto refresh.

 

[scootertramp]

Just a reminder for people using RSSI kick threshold, *** USE AT YOUR OWN RISK ***, if to unstable with auto refresh on, i would disable. I think kicking is meant to be a one off, who knows how asus software responds to multiple kicks in a row. It works great for me, but i dont use auto refresh.

Hence why I started with (Auto-refresh: A cautionary tale).
If the functionally is available somebody will try it.
My personal feeling is that any addon you add to your router is "*** USE AT YOUR OWN RISK ***", including firmware choice.
Thankfully there is amazing group of developers both past and present that produce some truly great products for us to enjoy.

 

[jksmurf]

if to unstable with auto refresh on, i would disable.

Just to confirm though, when you click the wireless report tab, it does a refresh each time you click it (after you navigate away), is that correct?

So essentially if you visit WR on multiple occasions and have RSSI kick enabled, it will do a kick each time, even if you have auto refresh off?

 

[JB_1366]

Just to confirm though, when you click the wireless report tab, it does a refresh each time you click it (after you navigate away), is that correct?

So essentially if you visit WR on multiple occasions and have RSSI kick enabled, it will do a kick each time, even if you have auto refresh off?

yes, everytime you go & comeback(granted its longer than 30 seconds), script auto-updates. then waits for next refresh.

 

[jksmurf]

yes, everytime you go & comeback(granted its longer than 30 seconds), script auto-updates. then waits for next refresh.

Thanks for clarifying. Just wanted folks to be aware of this, so that whilst the devices may be kicked by the first visit, subject to being below (it’s a -ve scale) the threshold, if the device still has a low RSSI, it will be kicked on every subsequent WR Tab visit, even with auto refresh off and even without touching the manual refresh. Just a heads up, in case devices get deauth’d again.

 

[JB_1366]

v1.5.4-fix wireless backhaul (BH) reporting; optimize RSSI thresholds.

New Feature: Implemented a network-wide 10-minute cooldown on RSSI kicks. The script now parses the global log; if a kick was recorded within the last 10 minutes, further deauthentications are paused. This prevents "kick-loops" and improves stability for auto-refreshing clients.

 

[jksmurf]

v1.5.4-fix wireless backhaul (BH) reporting; optimize RSSI thresholds.

New Feature: Implemented a network-wide 10-minute cooldown on RSSI kicks. The script now parses the global log; if a kick was recorded within the last 10 minutes, further deauthentications are paused. This prevents "kick-loops" and improves stability for auto-refreshing clients.

OK, soliciting other views on this, as while I think targeted and limited kicking is great, I think I’ve mentioned before that:

(a) my own experience is that it’s primarily IoT devices (primarily 2.4) that need kicking (as smartphones and iPads and Notebooks are much ‘cleverer’ at deciding what’s best for them, especially with 5Ghz connections); and

(b) in my view, the cause of the devices being on the incorrect node, when a better one exists, is often due to an isolated event (a system start, a node reboot etc). It thus actually needs, IMHO, a one-off kick, not an automated repeated kick tied to a refresh period, however long or short that may be.

The solution then, again in my opinion, is to either:

(i) divorce the RSSI kick from WR entirely and make it a button-click utility that you can run from the WR WebGUI so you can check the result almost immediately after a manual refresh OR

(ii) Take a pseudo (recent) ESPHome Builder approach for ESP32 devices, i.e. kick it once on first joining only (or on a system or node reboot), IF it meets the RSSI threshold. Noting that ESPHome programs devices themselves to make 3 retries, but most of our devices are not programmable.

You could even have both. My 2c, but I think this needs thoughts and experiences from others. Per SSID kicking i.e. enable only for your IoT SSID is another enhancement I think might suit some folks.

ESPHome 2026.1.0 - January 2026​

Post-connect roaming is designed for stationary devices and is intentionally conservative. If you already configured 802.11k or 802.11v roaming, post-connect roaming disables itself automatically. Devices scan up to 3 times after connecting (every 5 minutes), skip scanning when signal is already excellent, and only roam when finding a meaningfully better signal. Users shouldn’t need to understand RSSI thresholds to get reliable WiFi behavior.