Mobile App directly with PrusaLink API  

RE: Mobile App directly with PrusaLink API

Posted by: @rob-chartier

Based on 

https://raw.githubusercontent.com/prusa3d/Prusa-Link-Web/master/spec/openapi.yaml

We have an API exposed from Prusa Link, directly off my MK4 and/or anything running the PrusaLink software.

Are there any (negative) implications with using this API? 

1. Any notable performance issues while printing?
2. Is the API itself too young?
3. Will Prusa maintain some sense of backwards compatibility (version this API correctly)?
4. I noticed the MODEL of the printer doesn't seem to be exposed (or I just cant find it)
5. If we go over SSL, is the API Key method good enough for security considerations? 
   1. Can / will the software support some other mechanism?
6. and so on...

I have started a mobile app which talks directly to my printer via this API and before I invest any more time in it I want to make sure the time is well spent.  My goal is to be able to do full management of a "print farm" from the app, from anywhere.  Maybe its competition to PrusaConnect, I'm not sure; but it suits my mandate of no-cloud-dependencies.   There has been a few times where I could not see the status of my print remotely because of issues with PrusaConnect.

 

Thanks,

 

-Rob

 

This could work I don't see any downside should work for prusalink running on rpi for mk3 too are you going to make a github so we can follow progress I certainly would like to follow this

RE: Mobile App directly with PrusaLink API

Ill be publishing it as open source to github as soon as I have a 1/2 way decent UI done.  Right now I have most of the backend support plumbed in (full API support, printer instance management, auto-refresh of data, and so on), but my UI is as ugly as sin...  🙂

Ill loop back here once it is published.

RE:

 

• Any notable performance issues while printing?
• Is the API itself too young?
• Will Prusa maintain some sense of backwards compatibility (version this API correctly)?
• I noticed the MODEL of the printer doesn't seem to be exposed (or I just cant find it)
• If we go over SSL, is the API Key method good enough for security considerations? 
  1. Can / will the software support some other mechanism?
• and so on...

 

1 - if you keep spamming the api, it will lag the RPi zero W. Use API sparingly while printing.
2 - It's not undergoing turbulent development right now, who knows what will we do on any new printers? I don't
3 - No idea, i wouldn't trust us, then again, it's just api calls, we should bump the version on any change, if we don't call us out
4 - it is and it is and the stupidity of it is mind boggling. /api/version under original - the openapi-legacy.yaml is implemented in PrusaLink MK3, no idea about MK4
5 - we got digest auth, but it's MD5 digest auth, because browsers don't support anything more secure. How would you use SSL on MK4 PrusaLink? you'd have to reverse proxy it through a raspi or something.

RE: Mobile App directly with PrusaLink API

Posted by: @rob-chartier

Ill be publishing it as open source to github as soon as I have a 1/2 way decent UI done.  Right now I have most of the backend support plumbed in (full API support, printer instance management, auto-refresh of data, and so on), but my UI is as ugly as sin...  🙂

Ill loop back here once it is published.

Itd also be cool if you made it a windows app

RE: Mobile App directly with PrusaLink API

And a windows mobile app. (derp) 😀

RE: Mobile App directly with PrusaLink API

Currently I have it setup to poll once every 5 seconds.  Seems ok against my MK4, and I suspect an RPI should be able to handle that much usage!

Please do your best to version the APIs, my preference is in the uri...   follow semver.org if possible

It does seem silly not NOT have the printer version in the API.  I dont see it.  I see a type "PrintFileMetadataPrinter_model", with MK3, MK3S, MINI, but no MK4, and this seems to be related to uploaded files and not the printer...  Ideally I would like to see the specific version, and ideally a link to an image URI which I can just embed into the app.  IMHO that will improve the experience.

I suspect a reverse proxy would suffice for anyone who wanted it over SSL, agreed.  The auth, as is, seems to be a good start..for now...  🙂

Windows and Android Screenshots:

Currently all data is stored to a simple, unencrypted/unprotected file on disk.  

Thanks!

RE:

I don't know if this would be helpful, but I did have the same problem with getting to the API from OBS (I could not find a way to support Digest Auth), so I wrote this proxy.  The proxy could easily be extended to mirror all of the APIs (I only needed the one, the job API), but as to using SSL, how are you getting to the printer's API now?  I didn't see any API for the cloud Prusa Link site that would proxy for the printer, so I assume you are running your phone app inside your firewall now?  If that's the case then SSL support isn't really an issue.

For a commercial entity you could certainly put a proxy like mine in your DMZ and then use your domain to secure the connection.  You'd probably want to put other limits on it though to make sure some outside agency couldn't slow your prints down by hitting the interface.  I'm only using mine inside the firewall, and the twitch stream is how I monitor it from outside.

It mainly provides a graphic that shows the current state of the print for my twitch stream (through OBS).  Here's my proxy in case it sparks some ideas for you:

https://github.com/42degrees/PrusaPrinterApiForObs

Posted by: @rob-chartier

Currently I have it setup to poll once every 5 seconds.  Seems ok against my MK4, and I suspect an RPI should be able to handle that much usage!

Please do your best to version the APIs, my preference is in the uri...   follow semver.org if possible

It does seem silly not NOT have the printer version in the API.  I dont see it.  I see a type "PrintFileMetadataPrinter_model", with MK3, MK3S, MINI, but no MK4, and this seems to be related to uploaded files and not the printer...  Ideally I would like to see the specific version, and ideally a link to an image URI which I can just embed into the app.  IMHO that will improve the experience.

I suspect a reverse proxy would suffice for anyone who wanted it over SSL, agreed.  The auth, as is, seems to be a good start..for now...  🙂

RE:

I have Prusa Mini+ with firmware 4.4.1 and 5.1.2 which has PrusaLink embedded into a firmware.
I'm hitting that API on the printer something like over 6req/s from different systems (3x Prometheus Json Exporter, 1x NodeRed, 1x Home Assistant, 1x Prusa Link web dashboard in the browser) and I have not seen any issues from the printing side.

About API version
Notice that PrusaLink API for embedded device vs PrusaLink API for standalone app (on rpi) may differ, so I expect it is mixed depending on what device on runs.
For example PrusaLink API for Prusa Mini+ is limited and some methods are returning 404 (or 403).

Printer version
- this is probably hit or miss depending on the PrusaLink on rpi vs on firmware, I have not used one on rpi, but on my printer it shows /api/version:

{
    "api": "2.0.0",
    "server": "2.1.2",
    "nozzle_diameter": 0.4,
    "text": "PrusaLink",
    "hostname": "PrusaMINI",
    "capabilities": {
        "upload-by-put": true
    }
}

Moreover my printer after firmware upgrade still responds on old API endpoints so I did not have to update scripts that talk to the printer, but some new endpoints were added (I see PrusaLink dashboard uses different ones now AFAIR).
So the answer is... it depends 😉

About TLS:
- on Rpi it probably would require hiding API behind reverse proxy such as nginx and you could then add cert to nginx, but that may some impact on lower end hardware such as Rpi Zero W (single core version)
- on devices such as Prusa Mini this is not supported, overall device compute capabilities are quite low and they have a limited available memory capacity so I guess this will not happen on current hardware - even esp32 has issues with serving proper TLS

Other thoughts
- hmm I guess i'll put nginx proxy with request/response logging between the web browser/apps and the printer to see what else it goes there 😉
- see my GitHub repos for some stuff related to 3d-print tools etc.

RE: Mobile App directly with PrusaLink API

If the problem is getting the info to OBS, there's also a different possibility. You could use Home Assistant and the PrusaLink integration and create a custom dashboard for your printer stuff - this is what I did:

The dashboard can easily be added to OBS as a browser source and included in the stream layout:

Not to say anything against Scott's approach - it's just an alternative that may or may not be a better fit for specific requirements.

RE:

PrusaConnect works other way around - PrusaLink does a lot of POST requests to PrusaConnect site to send info what it does and in response it can get commands to execute if needed.

So this is a PrusaLink on rpi/firmware that actively polls cloud service, not the other way around (due to networking issues that it would imply).

RE: Mobile App directly with PrusaLink API

I guess somebody should tell the PrusaLink developers about the existence of Websockets. 🙂

RE:

It works now, and I believe they are aware of it anyway - so maybe some day.
I believe they are limited by the hardware (from the printer side), in addition scaling backends with ws is more problematic than it sounds, so I guess they just chose the easier path for now.

RE: Mobile App directly with PrusaLink API

We knew about websockets, we also knew that getting them working on the buddy platform wouldn't be easy. And thanks for the heads up on the scaling thing. Didn't know that at all