Weird thing is that FTPS is working out of LAN-only mode. It’s just MQTT that isn’t
That… surprisingly makes it more understandable. I assume it is then because the slicer uses FTPS locally for speed on the P1P, but it probably fetches the mqtt data from the cloud instead of local - whereas the X1C does both I think… weird.
Wonder if it’s technically a bug and may change?
When printing from the slicer it still goes through the cloud, but now the option to Send finally works, and sending happens over LAN. It seems slower to send via LAN than it does to print via cloud, though, lol
I submitted it as a bug report. Fingers crossed.
FTPS I got working out of lan mode but I seemed to need very specific settings that FileZilla didn’t support me setting. Probably because my P1P is segregated on an IOT only wireless network. But i found an ftp client that worked - what’s annoying me is that the bambu studio device tab that seems like it’s for file access doesn’t work - am I misunderstanding what that tab is / what it does with an X1?
It looks like ftps + mqtt lets you build a replacement for the bambu handy app that does everything except the video?
It’s still sending a 3mf though (files are called .gcode.3mf)? So presumably that means if you go to print it via the screen it has to then unzip it. I haven’t tested yet since I’ve been printing some things I wanted to grab timelapses for. And then I’ve been using ftps to copy the files off the printer.
Max tranfer rate is ~233KB/s. So some of the big organic models that clocked in at ~30Mb of .3mf file are still 2+ minutes of copying. I was fairly sure the download speed was entirely slow perf to the printer than local copies wouldn’t help with (my suspicion is that the sd card IO subsystem is actually the bottleneck). Question is whether being able to send uncompressed gcode is a net win by avoiding the also slow decompression on the underpowered esp32 and the extra sd card IO that additional requires.
The bottleneck may actually just be the P1P controller too - remember, it is running just a basic esp board.
There are build in commands to run actual .gcode files so it’s possible you could load gcode on the printer instead of a 3mf and print, however the data it reports about the print will be missing quite a bit of supplementary info and I’m not sure if it will work as expected.
And yeah, it’s essentially possible to replace the entirety of the handy app and actually add more functionality (in fact I think if I just add in fan control to my nodered flow I would have fully replaced it with a cherry on top) except for video. I could probably use ftps to also download/search timelapses and recordings but live video is yet to be done in a “nice” way.
Yes, I was able to download incomplete timelapses while they were being written via ftps so you probably could hack something together to grab the latest data and recreate it as snapshots (at least at the P1P video data rate). Not sure how much latency there would be. The raw videos are being saved too - that should give you much lower latency but probably still noticeably behind the x11 video on port 6000.
I’m sure the esp32 and/or its network capability is a bottleneck. But my theory is that the SD card IO is the dominating bottleneck. But it’s all guesswork.
Eh, I would think constantly downloading an ever-growing timelapse to fetch the latest frame may not be the most efficient method for just a snapshot. Raw videos only get saved if you have it enabled to record or have auto record monitoring on in bambu studio and click play at any point. Latency wouldn’t be the issue - but data download rate mostly. And due to data differences I doubt even FTP’ing a partial file would work out.
I would think streaming a live feed via ftps, while extremely slow and definitely will cause a bottleneck on the printer, has its own separate issues. I find that at least the X1C likes to disconnect FTPS clients pretty much as soon as it sees it is being idle - and if you were streaming a timelapse file I could see it kicking you, and if you did the live recording video well, the downside aside from datarate would be a constantly ever-growing storage on the sd card.
Just hoping bambu makes the RTSP stream lan accessible from any client without a middleman.
The default setting for the P1P is to have it recording all video whether or not you view it. I was assuming ftps lets you request specific block ranges during download. I think from (very ancient) memory that ftp allows for that. So if that’s the case, you’d just keep grabbing the latest - enough that you can piece together complete frames. But the full video files would be too high bandwidth. Even the 2m25s timelapse of a 2.5hour print was 177Mb (windows say 56kbps data rate for it but it’s much higher than that). And it took over 12 minutes to copy that off the device at 220+kbps.
Yep, fingers crossed they allow RTSP.
1 Like
Your point on the P1P data rate has me curious again - I know there “exists” SD cards that have built in wifi… Now if you had one of those extenders to wire one of them into a micro-sd end and put it in, I wonder if the download rate off that would be faster or not 
would cut out the bottleneck of the mainboard control unit if any, but at that point you’re one step away from connecting a Pi via micro-sd and mimic a “storage device” to the printer (I remember people doing this before as an alternative to octoprint waaaaay back)
May be moot. Each time I try and upload a relatively small gcode (1.6Mb) to the sd card (root or models directory) it drops the FTP connection, any in progress print just stops and the printer goes offline in Bamby Handy. So it seems to be hanging/rebooting it. After 30s or so it comes back.
Luckily the in-progress print was just a relatively small one - the blocky benchy and I’d printed enough of it to learn what I wanted to know.
Yeah that’s one thing I fear may be an issue with P1P stuff. Also models directory? Is the structure different on the P1P FTPS directories? In the X1C the root / is where most perma files live, but /cache/ is where “new cached” files are sent to. No models folder for x1c
General structure is the same as the screenshot I posted above. The models directory is extra and where all the preloaded files came located. I kept it when I swapped to a better sd card.
Noticed I have a ‘corelogger’ directory that also wasn’t in the earlier screenshot:
It isn’t just gcode files that restart the printer. I downloaded a .gcode.3mf sent to the printer by the send to printer button and triggered the exactly same hag at upload. It almost completed - it kind of looks like the ftps upload hang is at 256kb of data.
New P1P firmware today, would be interesting to know if the MQTT connection is working again outside of lan only mode.
It doesn’t look like there’s new firmware. Just delayed notification on fb from Bambu I think.
Ah right, just saw the date on it now, saw the tweet today about it and thought it was yet another since it was edited a bit.
I asked them about mqtt in future releases in their fw update post on fb but propably they don’t even answear for that question.
Hey all!
I saw that there is some kind of possibility to access the P1P now via MQTT. I tried it with a pre made workflow where I added my printer infos, but it does not seem to connect. Has anybody a working nodered flow which works for the P1P?