Skip to content

Add plugin discord_notifier - #1498

Closed
devouted wants to merge 1 commit into
OctoPrint:gh-pagesfrom
devouted:add-discord-notifier
Closed

devouted wants to merge 1 commit into
OctoPrint:gh-pagesfrom
devouted:add-discord-notifier

Conversation

@devouted

Copy link
Copy Markdown
  • 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?

OctoPrint-DiscordNotifier (plugin identifier: discord_notifier)

What does your plugin do?

It sends OctoPrint print notifications directly to a Discord channel via a
Discord webhook — no intermediate relay script or bot required. You configure
the webhook URL in the plugin settings and choose, via checkboxes, which events
trigger a notification (print started/done/failed, paused/resumed/cancelled,
printer connected/disconnected). Notifications can optionally attach a snapshot
from the webcam configured in OctoPrint, and a configurable throttle prevents
bursts of identical notifications. A "Send test" button lets you verify the
configuration.

Where can we find the source code of your plugin?

https://github.com/devouted/OctoPrint-DiscordNotifier

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

Yes. The plugin was developed with the help of AI (Kiro). It is marked with the
ai-developed attribute in the registration file. As the maintainer I
understand how it works and am responsible for maintaining it going forward.

Is your plugin commercial in nature?

No.

Does your plugin rely on some cloud services?

It only talks to the Discord webhook URL that the user configures (Discord's
HTTPS webhook endpoint). It does not use any other cloud service, contains no
tracking, and if Discord is unreachable it fails gracefully without disrupting
OctoPrint.

Further notes

The plugin targets OctoPrint 1.9.0+ (uses the webcam system introduced in 1.9)
and Python 3. The webhook URL is stored as a sensitive setting and the test API
endpoint is admin-only.

@jacopotediosi

Copy link
Copy Markdown
Member

@devouted, how does this plugin differ from the existing ones, Octorant and DiscordRemote?

@devouted

Copy link
Copy Markdown
Author

@devouted, how does this plugin differ from the existing ones, Octorant and DiscordRemote?

Good question — thanks for pointing to both.

vs. DiscordRemote: DiscordRemote is a full Discord bot (requires a bot
token and provides two-way control — issuing commands to the printer from
Discord). DiscordNotifier is intentionally much simpler and one-way: it only
needs a webhook URL, no bot, no token, no gateway connection. Different scope
— I just want reliable notifications, not remote control.

vs. Octorant: this is the closer one — both use a webhook and send a
snapshot without third-party services, so there is genuine overlap. The
differences are:

  • Rich embeds: DiscordNotifier sends Discord embeds with a per-event
    color, a progress bar and structured fields (file, times, etc.), whereas
    Octorant sends plain templated text messages.
  • Connection events: it notifies on Printer connected / disconnected,
    including the serial port and baudrate — which I didn't find in Octorant.
  • Notification throttle: a configurable minimum interval between
    notifications of the same type, to avoid bursts (e.g. a flapping serial
    port). 0 disables it.
  • Architecture: the Discord logic lives in a standalone, OctoPrint-independent
    library with unit/integration tests and a small CLI for local testing.

To be fair, Octorant currently has things this plugin does not, such as
fully customizable message templates and printing progress notifications
(every X%). So it's not a strict replacement — more a different take focused on
rich embeds and connection/port notifications. Happy to adjust the listing
description if you'd like me to make the distinction clearer there.

@jacopotediosi

Copy link
Copy Markdown
Member

The LLM you used to reply hallucinated, because it didn't actually look at the code or the features of the Octorant plugin. This is why I hate AI slop.

Going point by point:

Rich embeds: DiscordNotifier sends Discord embeds with a per-event
color, a progress bar and structured fields (file, times, etc.), whereas
Octorant sends plain templated text messages.

This is false. Every Octorant event has a "Display as Embed" option, with per-event colors and structured fields: https://github.com/bchanudet/OctoPrint-Octorant/blob/4b262ab16d19d0dd73b1cb6e062285649818d9b1/octoprint_octorant/templates/messages_prints.jinja2#L33-L38

Connection events: it notifies on Printer connected / disconnected,
including the serial port and baudrate — which I didn't find in Octorant.

Octorant also handles PrinterStateChanged events: https://github.com/bchanudet/OctoPrint-Octorant/blob/4b262ab16d19d0dd73b1cb6e062285649818d9b1/octoprint_octorant/__init__.py#L202-L212

It's true that it doesn't include the serial port and baudrate in the message. That's a small difference, though, and it would make more sense to propose it as a PR to Octorant than to publish a whole new plugin for it.

Notification throttle: a configurable minimum interval between
notifications of the same type, to avoid bursts (e.g. a flapping serial
port). 0 disables it.

This is false. Octorant also has a configurable throttle: https://github.com/bchanudet/OctoPrint-Octorant/blob/4b262ab16d19d0dd73b1cb6e062285649818d9b1/README.md?plain=1#L75

Architecture: the Discord logic lives in a standalone, OctoPrint-independent
library with unit/integration tests and a small CLI for local testing.

On architecture, I actually find Octorant more mature. It sends messages from a dedicated thread with a queue, while your plugin does everything synchronously inside on_event. That can block OctoPrint's event processing, which the method's documentation explicitly warns against:

Do not perform long-running or even blocking operations in your implementation or you will block and break the server.


For these reasons I'm rejecting this PR as a duplicate of an existing plugin. I'd really encourage you to contribute these improvements to Octorant instead, so users get them without having to choose between two nearly identical plugins.

One last request: please reply to reviewers in your own words. Answers that read as AI-generated and aren't checked against the code make our job much harder.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

Status: Done

Development

Successfully merging this pull request may close these issues.

3 participants