[threedprinter] Initial contribution

[computergeek1507]

[3D Printer Binding] Initial contribution

Description

I created a binding to monitor 3D printers status, temperatures, and job progress.
PrusaLink, Klipper, and OctoPrint firmware/server platforms are supported.
It uses HTTP to poll the printer to update the status.

I have build it locally and tested it with my Prusa and Snapmaker printers with the 5.2M4 release.

[Copilot]

Pull request overview

This PR contributes a new threedprinter binding for monitoring and controlling local 3D printers over HTTP, supporting PrusaLink, Klipper/Moonraker, and OctoPrint.

Changes:

• Adds binding metadata, Karaf feature, BOM/module registration, README, and thing/channel/config XML.
• Implements shared HTTP polling and platform-specific handlers for status, temperatures, progress, previews, and commands.
• Adds DTOs and configuration classes for PrusaLink, Klipper, and OctoPrint APIs.

Reviewed changes

Copilot reviewed 25 out of 25 changed files in this pull request and generated 11 comments.

Show a summary per file

File	Description
bundles/pom.xml	Registers the new binding module.
bom/openhab-addons/pom.xml	Adds the binding artifact to the add-ons BOM.
bundles/org.openhab.binding.threedprinter/pom.xml	Defines the new binding Maven module.
bundles/org.openhab.binding.threedprinter/NOTICE	Adds standard project licensing notice.
bundles/org.openhab.binding.threedprinter/README.md	Documents supported platforms, configuration, channels, and examples.
bundles/org.openhab.binding.threedprinter/src/main/feature/feature.xml	Adds Karaf feature definition.
bundles/org.openhab.binding.threedprinter/src/main/resources/OH-INF/addon/addon.xml	Adds binding add-on metadata.
bundles/org.openhab.binding.threedprinter/src/main/resources/OH-INF/config/config.xml	Defines thing configuration parameters.
bundles/org.openhab.binding.threedprinter/src/main/resources/OH-INF/i18n/threedprinter.properties	Adds localized labels, descriptions, and status messages.
bundles/org.openhab.binding.threedprinter/src/main/resources/OH-INF/thing/thing-types.xml	Defines PrusaLink, Klipper, and OctoPrint thing types.
bundles/org.openhab.binding.threedprinter/src/main/resources/OH-INF/thing/channel-types.xml	Defines shared printer status/control channels.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/ThreedprinterBindingConstants.java	Adds binding, thing, channel, and state constants.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/ThreedprinterHandlerFactory.java	Creates handlers for supported thing types.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/AbstractPrinterHandler.java	Adds shared scheduling and HTTP helpers.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/PrusaLinkHandler.java	Implements PrusaLink polling and controls.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/KlipperHandler.java	Implements Moonraker/Klipper polling and controls.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/OctoPrintHandler.java	Implements OctoPrint polling and controls.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/config/PrusaLinkConfiguration.java	Adds PrusaLink configuration model.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/config/KlipperConfiguration.java	Adds Klipper configuration model.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/config/OctoPrintConfiguration.java	Adds OctoPrint configuration model.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/dto/prusa/PrusaStatusResponse.java	Adds PrusaLink status DTOs.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/dto/klipper/KlipperObjectsResponse.java	Adds Moonraker object-query DTOs.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/dto/klipper/KlipperMetadataResponse.java	Adds Moonraker metadata DTOs.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/dto/octoprint/OctoPrintPrinterResponse.java	Adds OctoPrint printer DTOs.
bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/dto/octoprint/OctoPrintJobResponse.java	Adds OctoPrint job DTOs.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 27 out of 27 changed files in this pull request and generated no new comments.

Suppressed comments (11)

bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/KlipperHandler.java:186

• time-remaining is defined as Number:Time, but it is updated with a DecimalType. Use QuantityType with seconds so the channel publishes the correct quantity type.

        if (display != null && stats != null && display.progress > 0) {
            long elapsed = (long) stats.printDuration;
            long remaining = display.progress < 1.0 ? (long) (elapsed / display.progress - elapsed) : 0L;
            updateState(CHANNEL_TIME_REMAINING, new DecimalType(remaining));
        }

bundles/org.openhab.binding.threedprinter/README.md:114

• The print-speed and fan-speed channels are Number:Dimensionless (unitHint %), but the Items example uses plain Number. Update the example types so item-channel links work without conversion issues.

Number   MK4_PrintSpeed     "Print speed [%d %%]"            { channel="threedprinter:prusaprinter:mk4:print-speed" }
Number   MK4_FanSpeed       "Fan speed [%d %%]"              { channel="threedprinter:prusaprinter:mk4:fan-speed" }

bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/PrusaLinkHandler.java:126

• The channel-types define time-elapsed/time-remaining as Number:Time, but the handler updates them with DecimalType. This can lead to type mismatches on the event bus and items not accepting the updates. Use QuantityType with seconds instead.

            updateState(CHANNEL_JOB_PROGRESS, new DecimalType(job.progress));
            updateState(CHANNEL_TIME_ELAPSED, new DecimalType(job.timePrinting));
            updateState(CHANNEL_TIME_REMAINING, new DecimalType(job.timeRemaining));

bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/PrusaLinkHandler.java:145

• When there is no active job file, the preview cache is cleared but the job-preview channel state is not. This leaves a stale thumbnail on linked items/UI. Explicitly clear the channel (e.g., UnDefType.UNDEF) when file == null.

        if (file == null) {
            updateState(CHANNEL_JOB_NAME, new StringType(""));
            lastPreviewFilename = "";
            lastPreviewState = null;
            return;

bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/OctoPrintHandler.java:150

• The channel-types define time-elapsed/time-remaining as Number:Time, but this handler updates them with DecimalType. Use QuantityType with seconds to match the channel item type and avoid item/state type mismatches.

            updateState(CHANNEL_JOB_PROGRESS, new DecimalType(progress.completion > 0 ? progress.completion : 0));
            updateState(CHANNEL_TIME_ELAPSED, new DecimalType(progress.printTime));
            updateState(CHANNEL_TIME_REMAINING, new DecimalType(progress.printTimeLeft));

bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/OctoPrintHandler.java:184

• When filename is blank, the preview cache is cleared but the job-preview channel is not. This can leave the last thumbnail displayed even though no job is active. Clear the channel state when resetting the cache.

                } else {
                    lastPreviewFilename = "";
                    lastPreviewState = null;
                }

bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/KlipperHandler.java:147

• time-elapsed is defined as Number:Time, but the handler updates it with a DecimalType. Use a QuantityType with seconds to match the channel item type.

This issue also appears on line 182 of the same file.

            updateState(CHANNEL_JOB_NAME, new StringType(stats.filename));
            updateState(CHANNEL_TIME_ELAPSED, new DecimalType((long) stats.printDuration));

bundles/org.openhab.binding.threedprinter/src/main/java/org/openhab/binding/threedprinter/internal/handler/KlipperHandler.java:163

• When no file is being printed (stats.filename blank), the preview cache is cleared but the job-preview channel is not. Clear the channel state as well to avoid showing a stale thumbnail.

            } else {
                lastPreviewFilename = "";
                lastPreviewState = null;
            }

bundles/org.openhab.binding.threedprinter/src/main/resources/OH-INF/i18n/threedprinter.properties:64

• job-preview is defined in channel-types.xml, but there are no corresponding i18n entries in threedprinter.properties (other channels have them). Add label/description keys so the channel can be localized consistently.

channel-type.threedprinter.pause-resume.label = Pause / Resume
channel-type.threedprinter.pause-resume.description = ON pauses the print, OFF resumes it.
channel-type.threedprinter.cancel.label = Cancel Print
channel-type.threedprinter.cancel.description = Send ON to cancel the current print job.

bundles/org.openhab.binding.threedprinter/README.md:108

• The channel item types for progress/time/speeds are Number:Dimensionless and Number:Time (per channel-types.xml), but the Items example uses plain Number. Users copying this will get type mismatches when linking items to channels; update the example item types accordingly.

This issue also appears on line 113 of the same file.

Number   MK4_Progress       "Progress [%.1f %%]"             { channel="threedprinter:prusaprinter:mk4:job-progress" }
Number   MK4_TimeElapsed    "Time elapsed [%d s]"            { channel="threedprinter:prusaprinter:mk4:time-elapsed" }
Number   MK4_TimeRemaining  "Time remaining [%d s]"          { channel="threedprinter:prusaprinter:mk4:time-remaining" }

bundles/org.openhab.binding.threedprinter/README.md:136

• The print-speed channel type sets a minimum of 1, but the sitemap example allows 0 (minValue=0). Align the example with the channel constraints to avoid UI validation/errors when users copy it.

        Slider item=MK4_PrintSpeed minValue=0 maxValue=200 step=10

[lsiepel]

Some comments I gathered earlier. Might not be valid anymore, flush them now to not waste them

[wborn]

Thanks for the contribution. The overall structure looks promising, but I found a few functional issues that should be addressed before merging, particularly the PrusaLink job-control endpoints and the handling of unit-aware channels.

The review comments are AI-assisted.

[wborn]

Thanks for addressing the previous review findings. The PrusaLink job-control endpoints, unit-aware channel handling, asynchronous command execution, semantic tags, and job-state cleanup are substantially improved.

A thorough pass against the openHAB development guidelines and review checklist, together with the upstream APIs, found a few remaining functional issues. Most importantly, the writable PrusaLink temperature/speed/fan channels use an endpoint that Buddy firmware does not expose, and the OctoPrint thumbnail URL does not match the path generated by the PrusaSlicer Thumbnails plugin.

There are also a few smaller correctness and static-analysis issues that should be addressed before merging.

The review comments are AI-assisted.

[wborn]

The previous review findings have been addressed well, and CI is clean on the current head. Three functional API-state issues remain:

• Klipper print progress currently depends on optional display_status state.
• Klipper is marked ONLINE when Moonraker is reachable even if Klippy itself is not ready.
• OctoPrint temperature targets can be absent, but the current DTO represents an absent target as 0 °C.

Detailed findings are included inline.

[wborn]

Thanks for addressing the previous Klipper and OctoPrint findings. The current CI and static-analysis run are clean, and the previously reported Klipper state/progress and OctoPrint temperature-target issues have been addressed.

Three OctoPrint correctness issues remain around the /api/job response: nullable file fields can cause runtime failures, nullable progress values are currently converted to real zero values, and failures of the job request are silently ignored while the Thing remains ONLINE.

Detailed findings are included inline.

This review was AI-assisted.

[wborn]

Thanks for addressing the previous OctoPrint findings. The nullable job fields and progress values are now handled correctly, failures of the OctoPrint job request are reported, and the current CI/static-analysis run is clean.

One functional error-handling issue remains that should be addressed before merge: normal API-level command rejections can currently mark an otherwise reachable printer OFFLINE. There are also two smaller correctness issues around the auxiliary PrusaLink job request and OctoPrint transition-state handling.

Details are included inline.

This review was AI-assisted.

[wborn]

Thanks for addressing the previous findings. The PrusaLink auxiliary job request and OctoPrint transition-state handling are fixed.

One command-status issue remains for Klipper/Moonraker: Moonraker reports Klippy command errors as HTTP 400, which still falls through to the connectivity-failure path and can mark an otherwise reachable printer OFFLINE. Details are included inline.

There is also a small semantic-tag correction for the PrusaLink fan RPM channel.

This review was AI-assisted.

[wborn]

Thanks for addressing the previous findings. The command-status handling and PrusaLink fan semantic tag are now fixed, and the current CI/static-analysis run is clean.

The new multi-toolhead support introduces two closely related correctness issues: the primary nozzle setpoint channels report a fixed first tool (extruder / tool0), while their commands do not consistently target that same fixed tool. On multi-tool printers this can change the temperature of a different nozzle than the one represented by the channel.

Details are included inline.

This review was AI-assisted.

[wborn]

Thanks for addressing the previous multi-tool setpoint findings. Klipper now explicitly targets the primary extruder, and OctoPrint explicitly targets the corresponding tool.

One lifecycle issue remains in the Klipper multi-tool support: dynamically added nozzle channels can already exist when a new handler is created, but discovery currently adds them again unconditionally. This can make the first scheduled refresh fail after a binding restart, and for managed Things also after an openHAB restart.

There is also a smaller stale time-remaining case when a new Klipper print starts at 0% progress.

Details are included inline.

This review was AI-assisted.

[wborn]

Thanks for addressing the previous Klipper multi-tool lifecycle findings. The duplicate-channel and stale time-remaining fixes are correct, and the current CI/static-analysis run is clean.

One configuration-lifecycle issue remains. openHAB reinitializes the same handler instance after configuration updates, but the binding retains endpoint-derived configuration, discovery, and preview state across dispose() / initialize(). This can leave a reconfigured Thing using state from the previous printer, including skipped Klipper extruder discovery and stale preview data.

Details are included inline.

This review was AI-assisted.

[wborn]

BaseThingHandler.handleConfigurationUpdate() reuses the same handler instance by calling dispose() and then initialize(), but this only cancels the refresh job; the subclasses retain endpoint-specific configuration, discovery, and preview state.

For example, after changing a Klipper Thing to another host, extrudersDiscovered remains true, so discovery is skipped and queryUrlSuffix / extraSetpointHeaterByChannel can still describe the previous printer. The preview cache can likewise reuse the previous printer's image when the new printer has the same filename. If the new configuration is invalid, the early return from initialize() also leaves config pointing at the previous endpoint.

Please invalidate endpoint-derived state when the handler is reinitialized/configuration changes, including the corresponding config and preview caches in the PrusaLink and OctoPrint handlers.