Add Alexa OctoPrint (revised after #1463)

[RICLAMER]

• 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?

Alexa OctoPrint

What does your plugin do?

It simulates local smart devices for selected OctoPrint and 3D printer actions. Alexa discovers and controls those actions on the LAN without an external backend, Alexa skill, or integration account. It includes Portuguese, English, and Spanish device names, configurable printer actions, and optional OctoPrint-Enclosure power/light outputs.

Where can we find the source code of your plugin?

https://github.com/RICLAMER/AlexaOctoPrint/tree/0.2.0/Source

Tests: https://github.com/RICLAMER/AlexaOctoPrint/tree/0.2.0/tests

Release: https://github.com/RICLAMER/AlexaOctoPrint/releases/tag/0.2.0

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

Yes. OpenAI Codex assisted with implementation, tests, debugging, and English documentation. The maintainer defined the requirements and performed iterative testing against a physical Raspberry Pi, OctoPrint installation, Alexa devices, printer, HAProxy, and Enclosure outputs. The registration metadata includes the required ai-developed attribute.

Is your plugin commercial in nature?

No.

Does your plugin rely on some cloud services?

No cloud backend, Alexa skill, account, telemetry service, or relay is used for discovery or control. Runtime device communication stays on the LAN. GitHub is used only for source, releases, installation, and OctoPrint Software Update checks.

Changes made after the review in #1463

• Published the complete source and test suite instead of only a distribution ZIP.
• Replaced the previous license with AGPL-3.0-or-later and included the full license text.
• Replaced the custom update metadata with OctoPrint's github_release configuration and tagged source archives, following the jneilliii/OctoPrint-BLTouch pattern.
• Removed the shared static Hue-compatible username. A random 40-character username is generated per installation, validated on light routes, and redacted from logs.
• Restricted HAProxy ACLs by HTTP method and exact local smart-device paths; normal OctoPrint API routes such as /api/job and /api/files are excluded.
• Added explicit, optional Easy HAProxy Setup with listener detection, backup, validation, rollback, removal, and preservation of unrelated routes. The helper never kills a port owner.
• Simplified the settings UI and removed the temporary test device and mutable network/SSDP controls.
• Added optional Enclosure output dropdowns with controlled unavailable handling when the dependency is absent or disabled.
• Added Espalexa attribution as the protocol research/reference used for local interoperability.

Verification

Version 0.2.0 passed 30 automated tests and the gallery front-matter validator with no warnings. The tagged GitHub archive installs as OctoPrint-AlexaOctoPrint 0.2.0. It was installed on OctoPrint running Python 3.7.3 and validated on a Raspberry Pi with local Alexa discovery, HAProxy route isolation, and real Enclosure POWER/LIGHT switching.

This PR replaces the closed #1463.

[jneilliii]

Thank you, this is a little better. To continue the review I'll need to know if you plan on using the latest tag or direct zip download option mentioned in the code comment.

[jacopotediosi]

Cookiecutter template

This plugin was written from scratch by some LLM, so it does not follow the structure of the OctoPrint plugin cookiecutter template. That template exists not only to make plugin reviews easier, but also to ensure that installation succeeds in all scenarios supported by OctoPrint.

A brief five-minute look was enough to spot the following issues:

• In setup.py, unlike in the template, the license string for backward compatibility is not defined, so this plugin might fail to install in environments with setuptools<77.
• In pyproject.toml, the requires entries differ from those in the template, and the author's email address is missing.
• There is an empty requirements.txt containing only the comment # The plugin uses OctoPrint and Python standard-library modules only. Usually, when pyproject.toml is used, there is no requirements.txt file at all.
• The plugin sources live in a Source/octoprint_alexaoctoprint subfolder instead of directly under octoprint_alexaoctoprint.
• There is a plugin subfolder which, again, as in the previous PR, contains an OctoPrint-AlexaOctoPrint.zip file, which in turn contains another copy of the plugin sources, with no automation whatsoever guaranteeing that those sources stay in sync with the ones in Source/octoprint_alexaoctoprint.

None of this makes any sense.

Security

The plugin declares API routes through both SimpleApiPlugin and BlueprintPlugin. It overrides neither is_api_protected() nor is_blueprint_csrf_protected(). It sets is_blueprint_protected() to False, and it never imports the Permissions class anywhere.

Thus, anyone can use this plugin's APIs without authentication - APIs that allow, for example, turning the printer on and off, heating the nozzle, moving the axes, and so on.

Some routes take a 40-character "username" as input and use it as a "secret", validating it through the _is_authorized_hue_username -> username_matches -> hmac.compare_digest flow. However, a simple POST to the /api route returns that username in full.

I understand that this design stems from the choice of emulating a Philips Hue bridge: since Alexa has no way to authenticate against the OctoPrint plugin in that scenario, authentication ends up being dropped altogether. But that only means the Philips Hue bridge emulation is the wrong approach to begin with, not that leaving the APIs unauthenticated is acceptable. Other protocols - Matter, for instance - would likely allow an actual pairing between Alexa and the OctoPrint plugin.

AI usage

In this PR, as in the previous one, the author keeps talking like an excessively verbose clanker, which is another element we have historically disliked in past reviews.

The reason we closed the previous PR was not only the AI slop (which is very much present in the current codebase as well), but also the fact that the author demonstrated no understanding of how GitHub, or coding in general, works. The "Registering a new plugin" page clearly states that we expect maintainers to understand why their plugin works, and not to rely solely on their favorite genAI tool.

---

For the reasons stated above, I am closing this PR as well as the previous one.