Closed Tominka closed 4 months ago
Adding a way to get at the mmu state via API is actually pretty easy. I've already got a POST call to getmmu
you can make that triggers the nav refresh loop.
Getting at the filament manager data would be harder. I only retain the tool id on the server, all else is handled client side using those plugin's exposed functions. You're going to need to find a way to get that information from those plugins if you need it. And find a way to get at plugin settings to read the filament names stored in this plugin.
I'll update getmmu
to return the mmu state data in the next release. I'm not sure if it'll be enough for you but without a significant refactor the other data isn't readily available on the server to send.
The response object will look like:
{
"lastLine": "", // last response line from the MMU
"previousTool": "", // previous tool id (used for detecting when we are swapping filament
"response": "", // response code from MMU (see readme)
"responseData": "", // additional data from MMU
"state": "OK", // state of the MMU (loading, unloading, etc)
"tool": "" // current tool id
}
It seems that will be enough.
FilamentManager
plugin has an API request which returns filament selection for toolheads.
It is octoprintAddress/plugin/filamentmanager/selections
.
So from the data array I am able to extract toolhead´s numbers for each filament.
Thank you.
Latest release includes the update for getmmu to pass the state data. Closing this request as done :)
Hello,
In my opinion would be nice add GET and POST api requests for use of 3rd party applications.
For example: Current MMU state with integration of filament managers.