Latest P1P/S beta firmware blocks all mqtt push commands when not in lan mode - breaks ability to determine what the hardware is

[AdrianGarside]

Bambu Studio Version

-

Where is the application from?

Bambu Lab Official website

OS version

Windows 11

Additional system information

No response

Printer

P1P / P!S

How to reproduce

Configure printer in cloud mode. Connect to local mqtt. Monitor data. Try to send the get_version command - nothing happens, the critical version data is never received. The type of printer, number of connected AMSs and firmware version(s) cannot be discovered.

Actual results

Monitoring solutions are broken.

Expected results

Monitoring solutions should still work.

The problem is that even for just monitoring the printer you need to be able to send some mqtt commands to find out what the printer is and how many AMSes are connected to it. The commands don't control the printer - they are just a request for more specific information needed even for monitoring.

For diagnosis the pushall command is extremely useful to get a complete snapshot of all the mqtt state: {"pushing": {"sequence_id": "0", "command": "pushall"}}

A variant of this that was necessary with (much) older firmwares was that the printer sometimes silently stopped sending data to the mqtt client. This was fixable by sending the start push command: { "pushing": {"sequence_id": "0", "command": "start"}}

On the X1C, this command also is another one that isn't control, but just a request for specific data: {"system": {"sequence_id": "0", "command": "get_accessories", "accessory_type": "none"}}

None of these work anymore unless the printer is in lan mode.

Even if you now want to block control commands (turning the light on/off is an especially sad loss), the other commands above are not printer control commands - they're just requests for information and should still be supported. Please can you allow these to continue to work even when not in lan mode.

Project file & Debug log uploads

.

Checklist of files to include

• [ ] Log file
• [ ] Project file

[gaolegao-lx]

Please upload log through Handy APP, and give us your ticket number

---

Upload log files through Bambu Handy Log files from the Bambu printer can be uploaded via Bambu Handy over the network, with an upload speed of around 150 kbps under optimal network conditions. When uploading logs, you have the option to select a specific time frame, allowing you to reduce the volume of logs transmitted and shorten the upload duration. To upload files, go to Me → Support Tickets → Choose the ticket for log upload and proceed with the operation.

[AdrianGarside]

@gaolegao-lx this isn't a problem with my printer. It was a behavioral change in the 1.5.4.7 beta firmware. This seems to have been reversed in the 1.5.4.10 beta firmware as mqtt commands are now respected again when the printer is not in lan mode.

[sodachen22]

Before this firmware update, the printer's local MQTT Broker can process control commands under cloud mode. This meant that two asynchronous channels were controlling the printer simultaneously. The command from the two channels would execute in an overlapping manner without any order assurance, which is considered conflicting. To ensure the stable operation of the printer and avoid malfunctions caused by control channel conflicts, we will disable certain printer control functions via the local MQTT Broker under cloud mode. These functions have higher security requirements, and we want only one channel to be able to use these functions at any given time. The restricted controls includes:

1. initiating print
2. heating the nozzle
3. heating the heatbed Please node that this restriction will affect the use of software and hardware such as Home Assistant and BiQu Panda Touch. Suppose you still need to use such software and hardware to control the restricted functions. In this case, we recommend enabling the printer's LAN only mode to continue using the restricted control functions with Local MQTT broker.

[capsel22]

Before this firmware update, the printer's local MQTT Broker can process control commands under cloud mode. This meant that two asynchronous channels were controlling the printer simultaneously. The command from the two channels would execute in an overlapping manner without any order assurance, which is considered conflicting. To ensure the stable operation of the printer and avoid malfunctions caused by control channel conflicts, we will disable certain printer control functions via the local MQTT Broker under cloud mode. These functions have higher security requirements, and we want only one channel to be able to use these functions at any given time. The restricted controls includes:

1. initiating print

2. heating the nozzle

3. heating the heatbed
   Please node that this restriction will affect the use of software and hardware such as Home Assistant and BiQu Panda Touch. Suppose you still need to use such software and hardware to control the restricted functions. In this case, we recommend enabling the printer's LAN only mode to continue using the restricted control functions with Local MQTT broker.

This makes sense, however the OP mentioned you cant use "get" commands, to see current temp, AMS, version etc. I wouldn't think those are, as you said "control commands" and shouldn't be blocked.

[AdrianGarside]

Yes, that's correct. The essential ones are the commands to request more information.:

GET_VERSION = {"info": {"sequence_id": "0", "command": "get_version"}} START_PUSH = { "pushing": {"sequence_id": "0", "command": "start"}} PUSH_ALL = {"pushing": {"sequence_id": "0", "command": "pushall"}} GET_ACCESSORIES = {"system": {"sequence_id": "0", "command": "get_accessories", "accessory_type": "none"}}

These are essential just to monitor the printer.

Other commands that do actually control the printer but that I hope you won't lock down are:

• Control of the lights
• Fan speed control
• Print speed control