Add FACTOR Plugin

[kangbyounggwan]

• You have read the "Registering a new Plugin" guide.
• You want to and are able to maintain the plugin you are registering, long-term.
• You understand why the plugin you are registering works.
• You have read and acknowledge the Code of Conduct.

What is the name of your plugin?

FACTOR Plugin

What does your plugin do?

FACTOR Plugin provides remote monitoring and control for OctoPrint via QR code setup. It enables users to access their 3D printer from anywhere with real-time monitoring, camera streaming (MJPEG, WebRTC, RTSP, HLS), and instant notifications (print completion, errors, status updates).

Key features:

• QR code setup - no complex configuration needed
• Remote access from any device (desktop, laptop, tablet, phone)
• Full framerate webcam streaming with multiple format support
• Instant notifications via multiple channels (Push, Telegram, Discord, Email)
• Multilingual support (English, Korean)
• Modern UI following OctoPrint design standards

Where can we find the source code of your plugin?

https://github.com/kangbyounggwan/octoprint-factor-plugin

Was any kind of genAI (ChatGPT, Copilot etc) involved in creating this plugin?

Yes, AI tools were used to assist with code development, documentation, and UI design. All code has been thoroughly reviewed and tested by the FACTOR team.

Is your plugin commercial in nature?

No, the plugin itself is fully open source (AGPLv3 license). The FACTOR service is free to use, though premium features may be offered in the future.

Does your plugin rely on some cloud services?

Yes, the plugin relies on the FACTOR cloud service (factor.io.kr) for:

• MQTT broker for secure remote communication
• Device registration and management
• Notification delivery
• Web dashboard for remote access

All connections are encrypted via TLS/SSL and no OctoPrint credentials are stored remotely.

Further notes

• Version: 2.0.0 (major redesign with QR code setup wizard)
• License: AGPLv3
• Compatibility: OctoPrint >= 1.4.0, Python >= 3.8
• GitHub Release: https://github.com/kangbyounggwan/octoprint-factor-plugin/releases/tag/v2.0.0
• Documentation: Available in both English and Korean
• Support: https://factor.io.kr

This is the first official release to the OctoPrint Plugin Repository. The plugin has been redesigned in v2.0.0 to provide a simpler, more user-friendly setup experience compared to the previous version.

[jneilliii]

I will be reviewing the plugin code in the next few days, but initial review of this PR needs a few changes, see comments.

[jneilliii]

@jacopotediosi since this is cloud based would love to get your review on this plugin's code as well for any security concerns.

[foosel]

Also needs the commercial flag. Free tier or not, this is from a commercial entity.

[foosel]

And for any cloud offerings we also require a link to the privacy policy to be part of the metadata.

[jacopotediosi]

At first glance, this plugin conflicts with the MQTT plugin because of the octoprint_mqtt folder name and the entry point alias configured in both the pyproject and setup.py. In fact, when installing it on an OctoPrint instance where MQTT plugin was already installed, neither plugin works. I suggest renaming the folder to match the plugin ID (factor_mqtt) and removing the custom entry points.

@jacopotediosi since this is cloud based would love to get your review on this plugin's code as well for any security concerns.

I'll perform a more detailed analysis over the weekend, thanks for involving me.

[jneilliii]

At first glance, this plugin conflicts with the MQTT plugin because of the octoprint_mqtt folder name and the entry point alias configured in both the pyproject and setup.py. In fact, when installing it on an OctoPrint instance where MQTT plugin was already installed, neither plugin works. I suggest renaming the folder to match the plugin ID (factor_mqtt) and removing the custom entry points.

Yes, I noticed this as well when I did a quick look. Also the class name should also match the plugin and logging statements should be in English.

I'll perform a more detailed analysis over the weekend, thanks for involving me.

Very much appreciated.

[jacopotediosi]

I have not been able to get this plugin to work at all:

• If I install the release version, at the third step of the setup process I’m redirected to the web page
  https://factor.io.kr/devices/register?code=UUID (with my UUID, of course), which returns a 404.
• If I install from the latest commit on the main branch, the QR code doesn’t load because the /qrcode Blueprint endpoint is not defined.

From what I can see, remote control is supposed to work via MQTT, but looking at the code, the broker_host, broker_username, and the other related settings are never set anywhere and remain empty by default.

There’s also some confusion in the imports: several of them appear unused, while others are in the middle of the code, whereas best practice would be to place them all at the top of the file whenever possible. The os library is also used without being imported anywhere, and I’m unsure how it could work in that state. Maybe a pre-commit linter/formatter could help you there.

Is this plugin still a work in progress by any chance?

The main security concern, in my view, is that the MQTT broker should always use TLS (broker_use_tls), but I see that it’s set to False by default and never switched to True anywhere in the code.

[jneilliii]

Also needs the commercial flag. Free tier or not, this is from a commercial entity.

updated code comments to also include this and free-tier, because after registering on the site there is a pro tier and also enterprise best I can tell, hard to say since the site is not completely multi-lingual.

[kangbyounggwan]

Hi @jneillii, @foosel and @jacopotediosi,

Thank you again for all of your feedback on this plugin and for taking the time to review it so thoroughly. I’ve gone through your comments and made a number of changes to address the issues you raised.

Here is a summary of what has been updated:

1. Metadata and cloud/commercial flags

• Fixed the incorrect date in the plugin metadata (date now reflects the actual initial release).
• Added the requested attributes:
  • cloud
  • commercial
  • free-tier
• Added a link to the FACTOR privacy policy in the metadata:
  • privacypolicy: https://factor.io.kr/privacy

2. Plugin ID, package structure and MQTT plugin conflict

• Renamed the plugin to avoid conflicts with the existing octoprint_mqtt plugin:
  • Plugin ID: factor_mqtt → project/package name: octoprint_factor
  • Folder: octoprint_mqtt → octoprint_factor
  • Entry point: factor_mqtt = octoprint_mqtt → octoprint_factor = octoprint_factor
  • Main plugin class renamed to FactorPlugin.
  • Template and asset filenames updated from mqtt_*.jinja2, mqtt.js/css to factor_*.jinja2, factor.js/css.
• With these changes, the FACTOR plugin should no longer conflict with the existing MQTT plugin when both are installed.

3. MQTT configuration and TLS

• Implemented proper MQTT configuration for the FACTOR cloud broker:
  • broker_host = "factor.io.kr"
  • broker_port = 8883
  • broker_use_tls = True (TLS is now enforced for all MQTT connections).
• The plugin now actually uses the broker settings provided by the FACTOR cloud and no longer leaves these values empty.

4. Imports, logging and code cleanup

• Moved all import statements to the top of the file.
• Removed unused imports and added missing ones (including os).
• Cleaned up the code with a linter/formatter.
• Converted the remaining Korean log messages to English so that logs are understandable for the wider OctoPrint user base.

5. QR code setup, screenshots and images

• Removed the old QR-code-based setup flow from the plugin and documentation.
• Removed all QR-related wording from the description, features and tags (and updated the “What’s New” section to v2.6.2 accordingly).
• Removed the screenshots and featured image sections that referenced non-existing files.
• As a result, the previous image-related issues in this PR (external URLs and missing assets under /assets/img/plugins/...) are now resolved.
• Since the QR wizard has been removed, the plugin no longer relies on /devices/register?code=... or /qrcodeBlueprint, so the earlier 404s and missing endpoint reports should no longer apply to the current version.

6. Current status

• Latest plugin version in the repository: v2.6.3
• MQTT conflict resolved, broker configuration completed, TLS enforced by default, metadata updated, QR-related functionality removed, imports and logs cleaned up.

If you have the time, I would really appreciate another look from the security perspective as mentioned. Please let me know if you spot anything else that should be improved or if you’d like me to adjust the documentation further.

Thank you again for helping me make this plugin safer and better integrated into the OctoPrint ecosystem.

[jacopotediosi]

I’ve finished my review, based on the latest commit as of now: kangbyounggwan/octoprint-factor-plugin@2d607e1. After the implementation of the latest fixes, I was finally able to get the plugin working and successfully connect a printer to the cloud.
Below are my observations.

1. So the new identifier is now octoprint_factor. The plugin code still contains the old identifiers octoprint_mqtt and factor_mqtt in several places. Most importantly, the old identifier is still present in the get_update_information function, which I believe may prevent the plugin from automatically updating to future versions.

2. There are still several log messages in Korean in the mqtt_gcode.py file.

3. Looking at the commit history, why does the version number change in almost every commit, even when no release is published on GitHub? Keep in mind that OctoPrint always installs the plugin from the published release (see the configuration in get_update_information), so the typical workflow for OctoPrint plugin development is to bump the version number only right before publishing a release. That said, this might simply be a deliberate choice by the developer - I mention it only to confirm whether it’s intentional.

4. I think that the plugin code is using the SettingsPlugin mixin incorrectly. In OctoPrint, plugin settings are typically values that the user can change via the UI. Instead, the plugin defines many settings that are simply global constants that never need to be changed (for example, broker_host). Furthermore, some settings are completely unused - apparently leftovers from previous versions - e.g., auth_api_base, register_api_base, publish_snapshot.

5. The Blueprint endpoints /refresh-qr, /upload/local, and /upload/sd, along with their corresponding functions, appear to be unused.

6. I also ran some tests on the cloud component, meaning the API implemented through Supabase, and I have some security-related observations that I will send soon via email to factor@factor.io.kr.

[kangbyounggwan]

@jacopotediosi Thank you very much for the detailed review — it was extremely helpful.

Regarding the frequent version changes in the commit history:
The reason the version number was being bumped so often was because I needed to test whether OctoPrint's update mechanism correctly detected new releases. Since the backend was being modified in parallel, it was difficult to verify whether the plugin update was being applied properly on the OctoPrint side without bumping the version number. Increasing the version number was therefore purely for update-testing purposes rather than for publishing actual releases. Now that the plugin behavior is stabilizing, I will switch to a proper release workflow where the version number will only be incremented right before publishing an official GitHub release.

I will also fix all of the issues you mentioned, including:
• Cleaning up the old plugin identifiers (octoprint_mqtt / factor_mqtt) — especially inside get_update_information
• Removing unused settings and adjusting the SettingsPlugin usage
• Cleaning up unused Blueprint endpoints
• Replacing Korean log messages with English
• General code cleanup to improve maintainability

I plan to push the fixes within today and will notify you once they are committed.

[jacopotediosi]

6. I also ran some tests on the cloud component, meaning the API implemented through Supabase, and I have some security-related observations that I will send soon via email to factor@factor.io.kr.

I just sent it, you should have received it.

[kangbyounggwan]

All requested changes have been addressed, including the attributes field.
Let me know if anything else needs to be updated.

[jacopotediosi]

Hi @kangbyounggwan, I performed another round of review on the plugin code (up to commit kangbyounggwan/octoprint-factor-plugin@ee6fdb6).

I noticed that there are still several unused BlueprintPlugin routes: /confirm-registration, /camera (both GET and POST), /snapshot, /path-history (both GET and DELETE). Looking at the commit history, it seems these were generated by Claude, likely because it assumed you needed to expose new APIs for the features you were prompting for. However, in the context of this plugin, these endpoints do not serve any purpose if they are not consumed by the frontend. Is that correct? If so, I would suggest removing the unused endpoints to minimize the potential attack surface, in line with secure development best practices.

I also noticed that you recently added a new function, set_fan_speed. This function takes a speed parameter and attempts to infer whether it is expressed as a percentage or as a PWM value using the following logic:

# If value is 0-100, assume percentage and convert to 0-255
if 0 <= speed_value <= 100:
    pwm_value = int((speed_value / 100.0) * 255)
elif 101 <= speed_value <= 255:
    pwm_value = speed_value
else:
    return {"error": "Fan speed must be between 0-255"}

This logic is ambiguous. For example, it is not possible to indicate a PWM value below 100, because any value under 100 is always interpreted as a percentage. In addition, the function does not exhibit linear and monotonic behavior as one would expect: changing from speed_value=100 to speed_value=101 actually reduces the fan speed instead of increasing it.

[jacopotediosi]

Additionally, considering that you have already encountered a bug where the plugin mistakenly subscribed to device/unknown/registration instead of the correct topic with the instance ID (as shown here: kangbyounggwan/octoprint-factor-plugin@29518ca), a more robust design would be to avoid all those fallbacks to "unknown" and instead raise an exception when the instance ID is not defined at a time when it should be.

From a security standpoint, it seems quite concerning that the plugin could accidentally subscribe all instances to the same incorrect topic, especially considering that topics are used in this plugin to receive remote commands from the cloud.