Ignoring multiple messages in recieved G-Code

[lhalve]

When interfacing with a Prusa MK3S, the printer sends multiple messages when filament runs out. Is it possible to implement a feature that either ignores the same message sent multiple times or add a cooldown option for custom G-Code responses?

[fraschetti]

Seems reasonable. I'll add it to the list and will likely look into trackling this the next time I start working on the plugin (should be soon-ish).

[lhalve]

Great, thanks :)

[fraschetti]

Code changes submitted. Should come out with the next release.

[lhalve]

Hi, I tried the new feature with the Prusa Mk3s, but still get many notifications. I set the minimum notification interval for a custom recieved GCode event "echo:busy: paused for user" to 60 (minutes). When getting the printer to write these messages, i.e. cutting the filament and waiting for the filament sensor to notice, I still get multiple messages in a matter of a few seconds.

[davejhilton]

Same issue here. I'm running Octoslack 1.9.5, and it doesn't seem to be respecting the "minimum notification interval".

I created the same rule as @lhalve (on receive: echo:busy: paused for user), and set the minimum notification interval to 30 minutes, but then I got spammed with dozens of messages, each just a few seconds apart, when my Prusa mk3s sends that signal multiple times.

I would love to see this resolved—it will be SUCH a useful feature to have!

[fraschetti]

Hi @lhalve and @davejhilton

Do you mind providing a bit of info to help me debug this issue for you?

1. The configuration for the specific event you're having an issue with (what criteria, what notification interval settings, etc.)?
2. Can you generate a log file from Octoprint start to the end of the print (or at far as you're willing to endure giving the message spamming) so I can have something to look at?

---

1. Enable DEBUG logging
2. Reproduce the issue
3. Send Octoprint.log

Instructions to enable DEBUG logging for Octoslack

• Enable DEBUG logging Ensure the following has been added to /home/pi/.octoprint/logging.yaml (or appropriate path for your OctoPrint installation)

  loggers:
  octoprint.plugins.Octoslack:
  level: DEBUG

• Restart OctoPrint

  sudo service octoprint restart

For OctoPi releases, the log file will be located in: /home/pi/.octoprint/logs/octoprint.log

[hergtoler]

Same here. Here are my settings. I'll see what I have for logs.

[hergtoler]

OK, the 2020-05-14 file has the event. The print completes in the octoprint.log file. I have a pause embedded in the gcode to allow me to insert hex nuts in the print, and while paused, it outputs these messages about once per second. I hope the logs are more helpful to you than me, because I can't see anything telling in it.

Edit: deleting the log files I created last night while drinking beer because logging wasn't correctly enabled

[hergtoler]

Here is a log from this morning, while eating breakfast. :) Logging is enabled correctly, and I can see debug output from the event. octoprint.log

[fraschetti]

Hi Folks,

I ran through another round of tests for both the standard events as well as the g-code events and unfortunately I've been unable to reproduce the issue. That said, I recognize there's a number of you here reporting the issue so I've added a lot of logging for the upcoming release to hopefully shed a bit more light on the issue. The logic here isn't actually rather simple so there's likely something simple getting in the way.

[hergtoler]

Thanks for digging in to this. Here's an updated log including the new messages.

octoprint.log

[fraschetti]

Good news @lhalve @davejhilton and @hergtoler ...

Thanks to the latest log files provided by @hergtoler, I was able to determine the root cause here and will be submitting a fix shortly. The short version is that my testing always utilized G-code sent as opposed to what I assume all of you have had problems with - Gcode received. The received logic had a bug that was incorrectly setting override flages that would bypass the Minimum notification interval logic.

Btw, great timing @hergtoler - I've been prepping my release notes and had only intended on including the new logging .. but now we have a likely fix. Thanks!

Stay tuned folks as I'm hoping to get a release out in the next day or two.

[fraschetti]

Hello again @lhalve @davejhilton @hergtoler I carved out some time last night to push a new release (Octoslack 2.0.0) which contains the fix referenced above. I'll close out this issue for now but feel free to reopen it if the new plugin vesion doesn't address your issue.

Good luck!

[lhalve]

Sorry for not following up with you. The new release does indeed fix my problems :) Thanks a lot!