[Feature] REMOTELY (!) activating or deactivating AMS HT / AMS 2 Pro drying

[Skydev0h]

Describe the feature

By analyzing MQTT messages and experimenting I discovered that IT IS POSSIBLE to activate and / or deactivate AMS 2 Pro / AMS HT drying remotely!

I think this is a BIG feature because it is NOT possible to do this right now even using official apps!
But it IS possible on the MQTT level!

The only drawback is that it is "print"-class command - therefore pre-authorization firmware or developer mode or signing module or proxy is required. But given no limitations on duration, and, maybe, temperature, that is not much of a drawback...

What device is this for?

AMS HT and AMS 2 Pro

Other Information

To activate the drying you can send a command:

{
  "print": {
    "sequence_id": "0",
    "ams_id": 131,
    "command": "ams_filament_drying",
    "cooling_temp": 45,
    "duration": 12,
    "humidity": 0,
    "mode": 1,
    "rotate_tray": false,
    "temp": 45
  }
}

ams_id should be replaced with ID of AMS in question

cooling_temp / temp must be at least 45 or it does not work
As for the maximum value, idk, I was even able to set it to 100, and it actually started ramping up the temperature, but I really did not want to see what happens next, so I cancelled the heating process almost immediately

humidity is likely target humidity, I always observed 0, non-zero values seem to have no effect
mode is always 0 (off) or 1 (on), other values seem to cause the command to be ignored

rotate_tray is self-explanatory, I guess

Interesting feature is that you can change parameters on the fly - that is, it overwrites old ones.
I noted that by sending new values and observing changes on my AMS HT immediately (notably, duration).

duration can be only integer number. I was able to set it even to 100 hours and more o_O

Interestingly enough, if you send duration: 0, then it sets time to "30:27:52" O_O
However, the UI goes completely wacky, and reported dry_time is ... 715827 minutes... basically, infinite.
(But this only happens if I call it when drying is running, if not, then it does not start)

To deactivate the drying UI sends the following command:

{
  "print": {
    "sequence_id": "0",
    "ams_id": 131,
    "command": "ams_filament_drying",
    "cooling_temp": 40,
    "duration": 0,
    "humidity": 0,
    "mode": 0,
    "rotate_tray": false,
    "temp": 0
  }
}

I am not sure, but maybe this can even be used to dry while printing - but not sure about that. Anyway, even if possible, that may be pretty risky (filament may get stuck, for example).

P.S. Interestingly enough, for PPS it set temp: 85, but cooling_temp: 150. Don't know why :)
It may be worth to take my mqtt-delta tool and experiment on capturing different profile settings.

[Skydev0h]

N.B. Just tested, drying while printing is prevented on firmware level:

>>> 
{
  "print": {
    "sequence_id": "0",
    "ams_id": 128,
    "command": "ams_filament_drying",
    "cooling_temp": 45,
    "duration": 12,
    "humidity": 0,
    "mode": 1,
    "rotate_tray": false,
    "temp": 45
  }
}

<<<
{
  "print": {
    "ams_id": 128,
    "command": "ams_filament_drying",
    "cooling_temp": 45,
    "duration": 12,
    "err_code": 402702444,
    "humidity": 0,
    "is_from_mqtt": true,
    "mode": 1,
    "result": "fail",
    "rotate_tray": false,
    "sequence_id": "0",
    "temp": 45
  }
}

[JakobTewes]

Nice1...finally controlling the AMS HT drying remotely sounds like a dream come true ;-)

[suprak]

Very useful, thank you!

How did you discover this payload?
I want to find a payload for switching the AMS from left to right nozzle for H2Ds, any tips on how to pursue this?

[Skydev0h]

@suprak I am not sure whether you would capture it in this case, but I would advise to use https://github.com/Skydev0h/mqtt-delta to monitor MQTT messages on the printer while you do corresponding actions in the UI.

An example config that you might use for your printer:

mqtt:
  broker: mqtt://<Printer IP>:8883
  password: <Access key>
  topic: device/<Printer SN>/report
  username: bblp
  clientId: mqtt-delta-client
  tls: true
  others: true

messageFiltering:
  condition:
    path: print.command
    value: push_status

changeDetection:
  ignoredKeys: [ version, temp, nozzle_temper, humidity_raw, chamber_temper, cooling_fan_speed, fan, fan_gear, cham_temp, heatbreak_fan_speed ]
  ignoredPaths: []

logging:
  level: info

You may not get the payload to send right away, but I hope that you can pretty simply deduce on what the command is.

[Skydev0h]

@suprak today I needed to move an AMS from one extruder to another and observed following 2 commands:

[02.08.2025, 17:11:14] Filtered: {"print":{"ams_id":131,"command":"set_ams_led","duration":0.5,"led_mask":15,"led_mode":2,"repeat":6,"result":"success","rgb":0,"sequence_id":"791"}}
[02.08.2025, 17:11:36] Filtered: {"print":{"bind_list":[{"ams_f_bind":1,"ams_s_bind":6,"extruder":1},{"ams_f_bind":2,"ams_s_bind":9,"extruder":0}],"command":"manual_ams_bind","result":"fail","sequence_id":"794"}}

The first is when I tap the AMS (to "identify" it), and the second actually does the AMS <-> Extruder binding.
I have not yet figured out how to use the command or what the parameters should be - maybe you will have a better luck (I suggest looking at full state ("download diagnostics") along with the deltas)

P.S. Idk why result is fail, UI indicates success.

[suprak]

@Skydev0h thanks for your info and help!
Was able to repro and capture the events as you described.

For others,

To assign the AMS to the left nozzle,

{"print":{"bind_list":[{"ams_f_bind":1,"ams_s_bind":0,"extruder":1},{"ams_f_bind":0,"ams_s_bind":0,"extruder":0}],"command":"manual_ams_bind","sequence_id":"0"}}

To assign the AMS to the right nozzle,

{"print":{"bind_list":[{"ams_f_bind":0,"ams_s_bind":0,"extruder":1},{"ams_f_bind":1,"ams_s_bind":0,"extruder":0}],"command":"manual_ams_bind","sequence_id":"0"}}

Result seems to be always "Fail", but printer correctly reflect the reassignment as tested through Bambu Studio UI.

[Vizzyy]

This doesn't seem to work on the P1S. I'm subscribed to the report topic, and every time I push the above payloads to the request topic it shows something like :
{"print":{"sequence_id":"0","ams_id":128,"command":"ams_filament_drying","cooling_temp":40,"duration":0,"humidity":0,"mode":0,"rotate_tray":false,"temp":0,"reason":"success","result":"success"}}

but without actually affecting either my AMS 2 Pro or my AMS HT. It seems like I can send literally whatever and it will always succeed?

[suprak]

Has anybody discovered how to query the "bind_list" back out?
It looks like the info is not part of the standard "report" MQTT message payload.

Closest I found is "query_bind_status", but looks like that is part of the closed source Bambu Network Agent.

[coltography]

Just to clarify if you're on older FW without authorization control this won't be possible?

[jakubfrasunek]

@Vizzyy I second this, still doesn't work on P1S even on 1.09 FW

[Skydev0h]

Has anybody discovered how to query the "bind_list" back out? It looks like the info is not part of the standard "report" MQTT message payload.

Closest I found is "query_bind_status", but looks like that is part of the closed source Bambu Network Agent.

I'd listen to the MQTT to see how it should be used, because printer replies to commands and includes all (or almost all) parameters passed back.

Just to clarify if you're on older FW without authorization control this won't be possible?

Likely would be if AMS 2 / HT support is present in such a firmware. But I only tested on H2D so far.

@Vizzyy I second this, still doesn't work on P1S even on 1.09 FW

It needs LAN and developer mode because action is "print" class.

[jakubfrasunek]

@Vizzyy I second this, still doesn't work on P1S even on 1.09 FW

It needs LAN and developer mode because action is "print" class.

I am really aware of that, I have a whole app built, yet this does not work on P1S, printer returns the command as success with no action.

[Skydev0h]

@Vizzyy I second this, still doesn't work on P1S even on 1.09 FW

It needs LAN and developer mode because action is "print" class.

I am really aware of that, I have a whole app built, yet this does not work on P1S, printer returns the command as success with no action.

I suggest to try using mqtt-delta app, listen on P1S MQTT and observe command when starting / stopping AMS drying on P1S printer physically, maybe there are some differences or some parameters are incorrect.

[richowen]

I would like to be able to automate drying on the AMS 2 pro, so +1 for adding this to the integration