Feature Proposal: support Prusa Connect Local (PrusaLink successor), with proper multi-tool support

[gheydon]

Summary

Prusa has announced Prusa Connect Local: local-network management with no cloud required, positioned as the from-scratch successor to PrusaLink and built as an "open, extensible, multi-protocol" system the community can extend. Early-access (compile-it-yourself) today; no published API or release date. We do not have its API docs, but today's Prusa Connect (cloud) already shows the target feature set, and Connect Local is that, locally. Source: Prusa blog, Aug 2026 (link below).

Why it matters for PFM

• Foundation shift. PFM's Prusa driver (server/drivers/prusa.js) talks to printers over PrusaLink (/api/v1/status, upload). Prusa says Connect Local replaces PrusaLink, so the integration's base is changing.
• Proper multi-tool support. MMU/XL toolchanger is where the current PrusaLink path is weakest: no per-tool filament/material in live telemetry (only the slicer's per-tool estimate in G-code metadata). Connect is multi-material-aware, so Connect Local should expose per-tool status/material/consumption locally, feeding the multi-filament/tool-mapping proposal (Feature Proposal: Multi Filament and Tool Mapping #32) and mixed plates (Feature Proposal: multiple parts on one build plate (mixed plates) #59).
• Weak 8-bit PrusaLink. The external/standalone PrusaLink path used by 8-bit printers (MK3S+) has been less reliable in practice than built-in PrusaLink on 32-bit machines (MK4/Core One). As PrusaLink's successor, Connect Local is a chance to fix exactly those printers. On an MK3S+MMU3 this is also the multi-tool case, so both wins land on one machine.
• Fit. Local-only, no-cloud, open/multi-protocol aligns with PFM's self-hosted farm model.

Strategic angle: possible multi-vendor / local hub

The announcement only says "open, multi-protocol" and that the community can add other integrations (it does not explicitly mention non-Prusa printers or OctoPrint). But Prusa already bridges non-Prusa printers into cloud Connect via OctoPrint, so Connect Local plausibly aims to ingest non-Prusa printers locally too. If so it becomes a local hub for a mixed fleet: both an opportunity (PFM integrates with one endpoint to reach many printers) and an overlap (PFM should be clear where it adds value: its part/plate/quantity model, operator-hold workflow, dispatch scheduling).

What we can infer from today's Prusa Connect (capabilities, not wire format)

Per-printer status/history, job queueing, cameras, user roles, multi-material/tool awareness. Enough to shape direction; exact endpoints, auth, and field names stay open until official docs or hands-on early-access confirm them (this project never guesses protocol shapes).

What we do not know yet (blocks implementation)

No public API/protocol docs; unknown endpoints/auth; unknown supported printers/firmware; unknown whether it is per-printer (like PrusaLink) or a fleet hub; unknown whether /api/v1 remains for compatibility.

Proposed direction (for discussion)

• Track now. The reporter is signed up for early access and can capture the real local API and behaviour once available, so driver work is grounded in the actual protocol, not guessed.
• When documented, add a prusa-connect-local driver (or evolve prusa.js) using the standard four-function contract, keeping the existing PrusaLink driver working in parallel (current machines keep PrusaLink for now), selectable per printer.
• Wire its per-tool telemetry into PFM's multi-tool data model (gcodes.ams_slot plus the tool-mapping work in Feature Proposal: Multi Filament and Tool Mapping #32).
• Decide early: if Connect Local is a hub, PFM integrates with one endpoint rather than N per-brand drivers, a different shape.

Open questions

1. Per-printer service or fleet hub?
2. Real per-tool/per-slot telemetry (material plus actual filament used), unlike PrusaLink?
3. Multi-vendor: does it ingest non-Prusa printers locally (e.g. via OctoPrint), like cloud Connect does?
4. Will it support 8-bit printers (MK3S / MK3S+MMU3) via an external host, and improve on the current external PrusaLink reliability?
5. Auth/discovery, and does /api/v1 remain for backward compatibility?
6. Timeline and first supported printers.

Reference

• Prusa blog (Aug 2026): https://blog.prusa3d.com/better-prints-easier-use-prusa-xl-core-one-l-and-core-one-gen-2-our-big-product-update_137539/