amtm amtm 6.5 - the Asuswrt-Merlin Terminal Menu, March 29, 2026

[jksmurf]

We seem to all naturally expect "u" is only used to check for updates (as I explained previously above).

Many people seem to have missed that step, I'm not trying to single you out in anyway, but without doing it twice, then the amtmUpdateScripts file does not get generated as expected.

You’re correct, while it’s documented by TLC, it does not feel intuitive to do it twice.

I’d almost say just let amtm do the check internally on the first u or have a periodic check every time you enter amtm or use a different check code for scripts that support auto update in amtm e.g. “cfstsauiamtm” (just kidding).

btw… if amtm does the auto updates, what does the in-script (in MerlinAU e.g.) actually do, just run independently anyway on a cron (duplicate amtm au?) i.e. is it redundant, additive or you put so much work into it’s hard for you to say goodbye to it ?

 

[ExtremeFiretop]

btw… if amtm does the auto updates, what does the in-script (in MerlinAU e.g.) actually do, just run independently anyway on a cron (duplicate amtm au?) i.e. is it redundant, additive or you put so much work into it’s hard for you to say goodbye to it ?

I've already brought this up to thelonelycoder.
That some of us devs have already put time into developing our own "auto update" functionality. Including himself with diversion.

For now though, AMTM is not a true auto update. It's simply a method for AMTM to offer to update add-ons from the "u" screen.
Now when updates are available in the future, instead of only advising you, and having to go into each add-on to update, AMTM can instead offer to update the add-ons for you, without you having to load each add-on and run their own update function.

This is a quality of life feature that will greatly improve situations when multiple add-ons have updates.
The user can simply select "u" from AMTM, it will find updates and offer to install them for you.

If it ever gets its own cron job then it will become a true auto-update feature.
And at that point I'll have to reflect and consider what to do with MerlinAU. For now though they don't clash and are 2 separate features.

 

[jksmurf]

I've already brought this up to thelonelycoder. That some of us devs have already put time into developing our own "auto update" functionality. Including himself with diversion.

For now though, AMTM is not a true auto update. It's simply a method for AMTM to offer to update add-ons from the "u" screen.

Now when updates are available in the future, instead of only advising you, and having to go into each add-on to update, AMTM can Instead offer to update the add-ons for you, without you having to load each add-on and run their own update function.

This is a quality of life feature that will greatly improve situations when multiple add-ons have updates. The user can simply select "u" from AMTM, it will find updates and offer to install them for you.

If it ever gets its own cron job then it will become a true auto-update feature. And at that point I'll have to reflect and consider what to do with MerlinAU. For now though they don't clash and are 2 separate features.

Coolio, appreciate the explanation. Just a query, does the in-script au have to be enabled for the amtm au to work or are they independent? Asking as I disabled it on 6 routers…

 

[ExtremeFiretop]

Coolio, appreciate the explanation. Just a query, does the in-script au have to be enabled for the amtm au to work or are they independent? Asking as I disabled it on 6 routers…

If the in-script AU is enabled, AMTM updates will be disabled. If you disable the in-script AU, then AMTM updates becomes available.
Whenever you change the in-script option, you must again run "u" from AMTM so the "au" screen reflects those changes. (For now)

 

[jksmurf]

If the in-script AU is enabled, AMTM updates will be disabled. If you disable the in-script AU, then AMTM updates becomes available.

Whenever you change the in-script option, you must again run "u" from AMTM so the "au" screen reflects that changes. (For now)

Aha ! So they are related… now my convoluted steps all makes sense… I just arrived at it by dumb luck … too much poking around enabling and disabling stuff. What a eureka moment. Cheers., thanks.

 

[ExtremeFiretop]

Aha ! So they are related… now my convoluted steps all makes sense… I just arrived at it by dumb luck … too much poking around enablung and disabling stuff. What a eureka moment. Cheers., thanks.

They are related for sure, but separate features in functionality, I could of been more clear about that.
One is fully auto-updates from within MerlinAU, and the other is "streamlined" manual updates from AMTM.

We disable those streamlined amtm updates only if MerlinAU is handling it's own updates with it's built-in cron job / AU feature.

 

[jksmurf]

Separate Topic: Shell History in amtm

On my RPi4 the shell history seems to be just that, a history of commands I either type or paste into the command shell.

On the router, I cannot for the life of me work out what it’s remembering. I scroll back using the up/down arrow keys on my iPad (iTerminal) and stuff I could have sworn I copy pasted recently just doesn’t come up; yet there are reams of lines of commands that I swore I never typed, that actually do come up.

I looked at amtm, shell history, manage to see if there were any options like “just remember what I typed or pasted” but there isn’t. I looked at the history file too.

Is there something I’m doing wrong here or is it actually doing something I should expect but don’t know about ?

[EDIT] It seems within a SSH session it remembers the history better than if you exit SSH and go back in again ?

 

[Martinski]

btw… if amtm does the auto updates, what does the in-script (in MerlinAU e.g.) actually do, just run independently anyway on a cron (duplicate amtm au?) i.e. is it redundant, additive or you put so much work into it’s hard for you to say goodbye to it ?

Keep in mind that MerlinAU has to handle and manage 2 types of automatic updates:
1) Automatic F/W Updates
2) Automatic Script Updates

This means that the built-in "Automatic Script Updates" in MerlinAU is a bit more nuanced than the usual script update because we also have the "Automatic F/W Updates" to consider, and therefore, we must be very careful not to run both updates too close together to avoid "stepping on each other's toes."

So, to remove any possible scheduling conflicts between the two Automatic Updates, MerlinAU clearly and explicitly prevents users from setting up a separate cron job schedule for the "Automatic Script Updates." Instead, it takes the existing cron job schedule already configured for the "Automatic F/W Updates" and automatically schedules the "Script Updates" to happen 15 minutes *before*. This way, we avoid cron scheduling conflicts and any possible runtime issues between the two Automatic Updates by removing human errors from the equation.

Now, in the event that AMTM includes the option to set up its own cron job schedule to perform fully automated script updates, there is a possible scenario where a user may inadvertently schedule the AMTM script updates to happen either at the same time or very close to when the MerlinAU "Automatic F/W Updates" are scheduled to occur.

If that happens, there is a chance that the Automatic F/W Update and the eventual reboot of the router may leave some script update(s) in a *corrupted* state because the process was interrupted as "the rug was pulled out from under their feet."

The above scenario might be rare and unusual, but the chances are not ZERO, so to prevent it from happening, I've already implemented in MerlinAU a mutually exclusive, non-blocking FLOCK mechanism so that at some point, AMTM can check if the Lock is already taken *before* proceeding to start its automatic script updates. And, in the reverse scenario, MerlinAU also checks the Lock *before* starting the F/W Updates.

In short, the goal is to keep one update process from interrupting the other.

 

[jksmurf]

In short, the goal is to keep one update process from interrupting the other.

Thank you for taking the time to elaborate on the various update checks, there’s certainly a lot going on under the hood.

I did wonder about there being two auto update options within MerlinAU, for the two processes you highlighted, the FW and the script and what happens when amtm au takes over the script one.

You’ve clarified this nicely. I do recall the previous discussion about various crons not stepping on each other’s toes. Thanks once again .

 

[Implement3443]

Hey there!

Available amtm script updates:
- amtm 6.4 ->

Very truly yours,
Your GT-AX6000 router (Model type GT-AX6000)

Got this email about 8 hours ago, never had this error of a "ghost update" notification?

How amtm is looking:

 

[thelonelycoder]

amtm 6.5 is now available

• Rewrote logic and wording in au Automatic scripts update feature due to the confusing nature of how it interacts with third-party scripts. Opening au now also refreshes the supported scripts.
• Adds support for us Unbound Stats for Asuswrt-Merlin by juched78. Finally, this hidden Unbound addon has been made amtm compatible. Thanks to @Martinski for the extra effort!
• Again, this update is only available for the firmware built in version of amtm.

 

[thelonelycoder]

Got this email about 8 hours ago, never had this error of a "ghost update" notification?

How amtm is looking:

View attachment 70898

That‘s odd, I suggest you use the uu force update option in amtm.

 

[Radon]

Welcome, this is amtm 6.5, the Asuswrt-Merlin Terminal Menu

amtm is a front end that manages popular scripts for wireless routers running Asuswrt-Merlin firmware.
Starting with Asuswrt-Merlin firmware 384.15, amtm is included in the firmware.

What's new in amtm

• Rewrote logic and wording in au Automatic scripts update feature due to the confusing nature of how it interacts with third-party scripts. Opening au now also refreshes the supported scripts.
• Adds support for us Unbound Stats for Asuswrt-Merlin by juched78. Finally, this hidden Unbound addon has been made amtm compatible. Thanks to @Martinski for the extra effort!
• Again, this update is only available for the firmware built in version of amtm.

After updating amtm, run the u update function. This will populate the settings file with compatible third-party scripts.
If an update is available, amtm will prompt to update it directly.
Compatible scripts can then be seen with au, which also allows to disable this feature in amtm per script. Third-party scripts can also disable amtmupdate from their own scripts which will be shown in au.

I coordinated and developed this feature with the AMTM-OSR team. All of their scripts are already compatible. Many thanks to @ExtremeFiretop and @Martinski for the input, ideas and swift implementation.
My hope is that all amtm third-party scripts will add this amtmupdate feature. I will post a how to soon, with details for coders how to add it.
There are plans to completely automate amtmupdate with a cron job in a future amtm release.

How to update amtm
In the amtm menu, enter u to update to this latest version.
The firmware built-in and the legacy amtm version receive updates at the same time.

The full version history can be found on diversion.ch

amtm start command

amtm

On firmware older than 384.15, you may have to enter the full path to amtm.
Note that the command below does not work for the firmware built in amtm.

/jffs/scripts/amtm

Install command for Asuswrt-Merlin firmware older than 384.15
Copy and paste the complete command below into your favorite SSH terminal, then press Enter.

curl -Os https://diversion.ch/amtm/amtm && sh amtm

Routers with Asuswrt-Merlin firmware 384.15 and newer require no installation, amtm is included in the firmware.

amtm is hosted on the Diversion website: https://diversion.ch/amtm.html

Thank you for the awesome work! Hopefully I fully got the update sync description. I have noticed that AMTM 6.5 displays updates disabled for MerlinAU no matter how the automatic updates are setup in the advanced tab inside of MerlinAU on or off. I actually did disable it in the advanced options of MerlinAU though as best policy would be to read the release notes . Hence the update actually enlightened me that they had been on autopilot. Thank you!

 

[ExtremeFiretop]

Thank you for the awesome work! Hopefully I fully got the update sync description. I have noticed that AMTM 6.5 displays updates disabled for MerlinAU no matter how the automatic updates are setup in the advanced tab inside of MerlinAU on or off.

That's because you have MerlinAU script updates disabled in AMTM's "au" screen based on your shared screenshots.

If you enable the MerlinAU updates in AMTM's "au" screen, then you'll see it update with the MerlinAU advanced tab. They are not made to "sync up" as they are 2 independent features.

I actually did disable it in the advanced options of MerlinAU though as best policy would be to read the release notes . Hence the update actually enlightened me that they had been on autopilot. Thank you!

We would generally recommend enabling Auto-Updates in MerlinAU, that way the script is always on the latest when flashing a firmware update. But do make an effort to try and read the release notes when we make a release, I don't disagree with that one bit.

 

[Radon]

That's because you have MerlinAU script updates disabled in AMTM's "au" screen based on your shared screenshots.

If you enable the MerlinAU updates in AMTM's "au" screen, then you'll see it update with the MerlinAU advanced tab. They are not made to "sync up" as they are 2 independent features.



We would generally recommend enabling Auto-Updates in MerlinAU, that way the script is always on the latest when flashing a firmware update. But do make an effort to try and read the release notes when we make a release, I don't disagree with that one bit.

Hello sir, actually it will display disabled no matter what the script is it to. Not a big issue but it does this on my AX11000. Thanks for the convo.

 

[ExtremeFiretop]

Hello sir, actually it will display disabled no matter what the script is it to. Not a big issue but it does this on my AX11000. Thanks for the convo.

You need to select the "au" screen in AMTM. Please share that screen in your screenshots.

 

[Radon]

You need to select the "au" screen in AMTM. Please share that screen in your screenshots.

Man, thank you so much for the help. I do have something a bit twisted, I may have to disable in au again, please advise.

 

[ExtremeFiretop]

Man, thank you so much for the help. I do have something a bit twisted, I may have to disable in au again, please advise.

Happy to help. I am the developer of MerlinAU, along with my partner martinski, so I like to think I generally know how it works.

In that screen your on now in AMTM, you can no longer enable AMTM updates for MerlinAU, because auto updates are enabled in MerlinAU itself.

The choice is one or the other. If you disable Auto Updates in MerlinAU, you'll see you can enable or disable the choice in AMTM "au" screen. If you enable auto updates in MerlinAU, we forcefully disable it in the AMTM "au" screen.

If you disable the amtm update feature in AMTM's "au" screen, then it will always remain disabled as you initially saw, regardless of how MerlinAU is setup.

 

[Radon]

Man, thank you so much for the help. I do have something a bit twisted, I may have to disable in au again, please advise.

Thank you Brother!

 

[jksmurf]

Really like the revised single step au process, and @ExtremeFiretop note above, which adds further clarity.

One item that may be confusing for folks that run it for the first time AND have all their supported scripts enabled is this:

When you run au the text that comes up says

Scripts supporting amtmupdate

On mine I saw a list of 3 (Diversion, MerlinAU, YazDHCP), on the monochrome theme that I use on my iPad.
Strictly speaking “supporting” means they support amtmupdate but may not necessarily be enabled to be updated by it.

It’s only when, at this point, not being sure about the terminology, you select the enable/disable menu, that you see it clearly show text that you just disabled it, so now you know the initial list meant supported AND enabled. Had one or more of them been disabled at the first screen showing “Scripts supporting amtmupdate” it would click immediately and you’d know what that first sentence meant.

It’s only when your list has them all enabled (but at this point you don’t know) that it’s a bit if a head scratcher, because the list actually has TWO functions, (a) Show scripts that are supported by amtmupdate AND (b) Show the ones that are currently enabled or disabled.

So, what would I suggest as an alternative? Options for wording in amtm:

A. Scripts supporting amtmupdate (currently enabled unless otherwise shown)
B. Scripts currently enabled / disabled in amtmupdate (enabled unless otherwise shown)
C Something else…

Or

Just suffix each Addon in the list with (enabled), if enabled.
Addons that are disabled are already annotated.