Ah yeah, they are using a different image. That’s the stock one - in mine I had the same one and just altered it to be mostly greyscale since I couldn’t find a way to auto colour the bg image. Don’t think it’s possible without a lot of wizardry.
That will be a later one I work on next week or even this weekend if I have time, since it’s a bit more complex, but it will be made 
EDIT:
Round 2: Dashboard YAML configurator
This separates the three main pieces (Printer, AMS, Printer Control) into three configurable YAML files which you can copy and paste into a dashboard. I also show recommendation for having all three in a layout card, but that’s optional. Another reason for the separation - multiple AMS’s
Now to start round 3: Making the FTP Fetch and DB flow more configurable… probably also throw in my Grafana dashboard for that, mainly for the queries, filters, and transformations.
2 Likes
Okay, so the new firmware treats printing from the slicer differently again, so the FTP fetch requires a new workflow to work.
Last firmware, whenever I printed from bambu studio, it sent it to the sdcard and it saved. Now, unless I Send first, but just Print, it actually sends the 3mf with a random number for a name (equivalent to the task id .3mf) and it’s saved to the “Internal” category on the printer, which is not accessible via FTP. I didn’t even know it was possible to upload there. And this isn’t the same as the new “Cache” category either.
Must be new for cloud prints maybe? Either way, for the FTP fetch to work now, I need to manually send to printer and it will work. On the bright side, if the new print cache feature ever gets filled up, that can be FTP’d into. Just nothing “internal”, and need to figure out if there’s a way to always send to SD card from studio…
1 Like
One of the features I saw somewhere was being able to reprint one of the last 10 (?) prints direct from the machine without redownloading from the cloud. That seems like it could be why you see a difference in behavior now.
Yeah, I thought that would have been the new “Print Cache” section which is still empty for me. That print file is still in the “internal” section. I just need to make it a habit to send to print when I print now I guess, until I figure more of it out.
I hope it doesn’t end up with me going down a rabbit hole of trying to find how the slicer/cloud sends that file to the printer to see if maybe I can connect to it for the internal files too, I doubt it but… Given they’re using FTPS of all things, wouldn’t be surprised if there was a sudden secondary server.
What does the get_version payload look like for the X1? I want to compare it to the P1P to see if the esp32 entry I see is, as I suspect/hope, unique to the P1P.
Here’s from an X1C. I expect it is possible to detect if it’s a P1P via the esp32 entry, but I wonder if there’s another common entry with a specific hardware version or not. Because I also wonder if there’s a detectible hardware_ver difference between the X1 and X1C.
{
"info": {
"command": "get_version",
"module": [
{
"hw_ver": "",
"name": "ota",
"sn": "",
"sw_ver": "01.04.00.00"
},
{
"hw_ver": "AP05",
"name": "rv1126",
"sn": "<SERIAL>",
"sw_ver": "00.00.17.65"
},
{
"hw_ver": "TH07",
"name": "th",
"sn": "<SOME_OTHER_SERIAL>",
"sw_ver": "00.00.04.95"
},
{
"hw_ver": "MC07",
"name": "mc",
"sn": "<YET_ANOTHER_SERIAL>",
"sw_ver": "00.00.13.24/00.00.13.24"
},
{
"hw_ver": "",
"name": "xm",
"sn": "",
"sw_ver": "00.00.00.00"
},
{
"hw_ver": "AMS08",
"name": "ams/0",
"sn": "<AMS_SERIAL>",
"sw_ver": "00.00.05.96"
}
],
"sequence_id": "20004"
}
}
For curiosity, “ota” is the firmware version, “rv1126” and “AP05” are for the printer given the serial number matches. “TH07”/“th” I still don’t know, “MC07” / “mc” I am believe is the MC board, both software and hardware versions available with SN. XM I have zero clue as it gives no info, and finally it has an ams/id for each AMS unit.
This is what I have:
{
"info": {
"command": "get_version",
"sequence_id": "20069",
"module": [
{
"name": "ota",
"sw_ver": "01.01.01.00",
"hw_ver": "OTA",
"sn": "<SERIAL>"
},
{
"name": "esp32",
"sw_ver": "00.02.10.39",
"hw_ver": "AP04",
"sn": "<SERIAL>"
},
{
"name": "mc",
"sw_ver": "00.00.12.53",
"hw_ver": "MC07",
"sn": "<OTHER SERIAL>"
},
{
"name": "th",
"sw_ver": "00.00.04.60",
"hw_ver": "TH09",
"sn": "<ANOTHER SERIAL>"
},
{
"name": "ams/0",
"sw_ver": "00.00.05.75",
"ota_ver": "00.00.00.00",
"hw_ver": "AMS08",
"sn": "<YET ANOTHER SERIAL>"
}
],
"result": "success",
"reason": ""
}
}
I think the letters stand for:
AP = Application Processor
mc = Motor Controller
th = Tool Head
So esp32 present == P1P; rv1126 present == X1 (are there any differences between X1 and X1C?)
Yeah, the MQTT explore interface is not very helpful when there’s lots of data flowing. Can you only subscribe to the /request channel so you aren’t overwhelmed by the /report channel content? I can’t on my P1P - it just disconnects me immediatey.
There are at least from a logistical standpoint, differences between X1 and X1C, and even if some versions match, I would expect the hardware version of something could be different.
Interesting to see then that a P1P is AP04, while X1(C) is AP05. Could still be X1 is the same as X1C. I would think these versions may change with small revisions, but that may not be the case since I know for a fact the AMS has gone through at least 2 revisions and the X1C has gone through 1, and my kickstarter AMS hardware version is the same as a new person’s.
I think that will work to differentiate - esp32 and AP04 is P1P, rv1126 and AP05 is X1(C?). I would say the combo, just in case they do release more printers that share same processor then we can guarantee hw_ver would be different. I guess we could just scan all objects hw_ver for one that starts with AP?
As for the request topic, it should be quite slow as it would only log what comes in, not their output. I.E. commands - like running get_version would pop up there. I don’t know how to specifically do stuff via mqtt explorer though.
This is all I can do with my P1P. Almost anything else immediately disconnects me. I was thinking just monitoring /request
Yes, the filament colors are synchronized. I got the code from a Discord
I finally have a writeup and configurator for the FTP and Postgres DB advanced flow and as a bonus, tossed in my Grafana dashboard configuration for tracking prints across all printers you have linked to the database (even works with resin printers, just need to have the right sensors pushing data in the right places for any printer).
This writeup is a lot more technical than the previous two and makes some assumptions, hence it being an “advanced” flow. If I wrote it up like an ELI5 it would easily be 10x longer. For what you get out of it, only those looking for granular database recording or those who just want a pretty picture would benefit for it, so I don’t fully recommend anyone set it up unless you are prepped for some technical babble.
However, I still think it’s worth a read since it may give others some ideas, such as a metering plug just for a passive insight into how much energy your printer uses every now and then.
1 Like
Can you please link it, want to do this
And for those of us that don’t have a pgsql host running at home yet and want an easy button for a database, I’m working on an add-on to host it. The only one I saw out there was a full TimescaleDB and that’s more overhead than I want.
1 Like
Here’s the mqtt request to get the device to push all state:
{ “pushing”: { “sequence_id”: “1”, “command”: “pushall” }, “user_id”: “1234567890” }
1 Like
Wow, that’s a new one! How did you find that out? I could only find messages of print/mc_print/info/system before.
For P1P I would probably think due to power of the board, to call it no more than once every 30s, maybe once a minute.
EDIT: Don’t think it works on the X1/X1C, but it could just be because it reports the print all status every second, so not really “required”. I’m still going to add it to my flow just so in the future I may be able to make it P1P compatible.
I gave up on trying to be effective browsing source on github and just cloned the bambu studio repo locally so I could effectively search it. That got me to the single file that does all the mqtt calls in seconds and it’s in there (along with a few others):
BambuStudio/DeviceManager.cpp at master · bambulab/BambuStudio (github.com)
I wouldn’t use this to poll for state for a P1P. It’s already sending out all state as it changes. It just lets you initialize all the current state once at mqtt connection and then use the normal pushed state changes to update as things change. That way you aren’t making it do any more work than it currently does with BS and Handy.
2 Likes
Fair point, just thinking maybe then a force update button. Can’t believe I never thought to browse the repo for the mqtt commands… I even browsed it for the filament codes and such!
And as I suspected… the red “work light” can be turned on/off/flashing except… it doesn’t actually turn on or off or flashing. The state changes but in reality it doesn’t change.