Notification via Pushover or other service

elmoret · 10 Dec 2017, 21:00

Did this end up going anywhere? I would find it useful to be notified (push notification, text message, or email) if the printer pauses for any reason (filament detector, heater fault, etc).

I don't print fully unattended but am often in a different part of the office, away from the printer and sometimes away from computers.

resam · 10 Dec 2017, 21:53

FYI: I implemented something like this for the "Pushed" service, which is free: a small Python script running on an Raspberry Pi Zero on the same network.
I guess one could also run this with MicroPython on an even smaller microcontroller or maybe integrate it into the esp8266 or similar…
https://gist.github.com/Kriechi/63c29ed4ad860744107ee4a1b5cf10a2

If anybody want to collaborate & extend it, I can make it into repository…

JohnOCFII · 11 Dec 2017, 03:55

Something like the OctoPrint Telegram plug-in would be great.

https://github.com/fabianonline/OctoPrint-Telegram/blob/stable/README.md

kd · 13 Dec 2017, 21:14

is polling rr_status from a python script safe? The documentation mentions this:

Since RepRapFirmware can only process one HTTP request at a time (excluding rr_fileinfo and rr_upload on certain platforms), DuetWebControl should attempt to avoid parallel requests

but it seems like i'm connecting not to the reprapfirmware but to the duet web control which must pass through the call and return the results?

resam · 13 Dec 2017, 21:19

There is no such thing as "duet web control" that is processing requests.
There is only your client (browser) and RepRapFirmware.

DWC is running in your browser - and does exactly what you said: it is constantly polling RRF for new information. So using it in a python script is as safe as using DWC in your browser. By default DWC polls every 0.25sec or so - which IMO is quite high - without interfering with your regular printing stuff. All in all pretty safe.

kd · 13 Dec 2017, 21:24

so doing it from a browser and doing it from a python script won't result in parallel requests? or will a parallel request just be delayed until rrf can respond?

dc42 · 13 Dec 2017, 22:12

@kd:

is polling rr_status from a python script safe? The documentation mentions this:

Since RepRapFirmware can only process one HTTP request at a time (excluding rr_fileinfo and rr_upload on certain platforms), DuetWebControl should attempt to avoid parallel requests

but it seems like i'm connecting not to the reprapfirmware but to the duet web control which must pass through the call and return the results?

That's out of date. RRF on the Duet WiFi and Duet Ethernet can process multiple http requests concurrently.

elmoret · 19 Dec 2017, 05:08

So as an interim measure, I set up a script to text me (via email) when the status of the printer changes. First, set up mail from a command line:

http://codana.me/2014/11/23/sending-gmail-from-os-x-yosemite-terminal/

I made a new gmail account for this since the password gets stored in plaintext on your computer.

Then, set up a bash script. Currently running on my computer but I'll move this to an always on Raspberry Pi soon.

#!/bin/bash

PREVSTATUS=$(curl -s http://printername.local/rr_status?type=1 | awk '{print substr($0,12,1)}')

while [ 1 ]
do

STATUS=$(curl -s http://printername.local/rr_status?type=1 | awk '{print substr($0,12,1)}')

if [ $STATUS != $PREVSTATUS ]
then
       echo $STATUS | mail -s "Printer Status Changed" email@address.com

fi

PREVSTATUS=$STATUS

done

email@address.com is used to send a text message to my phone, most mobile carriers allow you to send an email to produce a text, a quick google of your wireless carrier and "email to text" should turn up the specific email address in your case.

Be sure to update "printername" as well.

Then I get a single character text message, I'm really only concerned with "P" and "S" but here they all are:

				case 'F':	// Flashing new firmware
					setStatusLabel("Updating", "success");
					break;

				case 'H':	// Halted
					setStatusLabel("Halted", "danger");
					break;

				case 'D':	// Pausing / Decelerating
					setStatusLabel("Pausing", "warning");
					printing = true;
					paused = true;
					break;

				case 'S':	// Paused / Stopped
					setStatusLabel("Paused", "info");
					printing = true;
					paused = true;
					break;

				case 'R':	// Resuming
					setStatusLabel("Resuming", "warning");
					printing = true;
					paused = true;
					break;

				case 'P':	// Printing
					setStatusLabel("Printing", "success");
					printing = true;
					break;

				case 'M':	// Simulating
					setStatusLabel("Simulating", "success");
					printing = true;
					break;

				case 'B':	// Busy
					setStatusLabel("Busy", "warning");
					break;

				case 'T':	// Changing tool
					printing = isPrinting;
					setStatusLabel("Changing Tool", "primary");
					break;

				case 'I':	// Idle
					setStatusLabel("Idle", "default");
					break;

I'll probably add to the bash script to only text me when the printer is stopped, but for now I'll get a text anytime the status changes, provided that it doesn't change faster than the curl update rate (about 5 seconds).

Quick and dirty, probably better ways out there but this is free and worked for me!

briangilbert · 9 Jan 2018, 09:04

Pushbullet is another option that is free
https://docs.pushbullet.com/

briangilbert · 9 Jan 2018, 09:05

would it be possible to have some gcodes that hit the url required to submit a message directly from the duet?

I'm particularly after a way to send a notification to my phone at the end of a print.

strips · 9 Jan 2018, 12:50

This is a similar request that could be fulfilled at the same time

https://www.duet3d.com/forum/thread.php?id=2236

Luca79 · 9 Jan 2018, 15:16

FYI, I am developing a telegram bot (in testing phase) to the purpose that can easily run on a RPI Zero. I will keep you posted as soon as the code is stable I will opensource it.

strips · 9 Jan 2018, 17:44

Any solution should not be locked to a single proprietary service. Some kind of standard should be used so it can be integrated with anything.

E.g rest, json and oauth would be nice. Maybe something simpler and we could make a proxy-service for reaching out to other services.

dc42 · 9 Jan 2018, 17:48

A REST API would still require you to run some process on a PC or RPi etc. to send the notification. Any solution that sends the notification directly from the Duet would need to be configured to use a particular service. To be service-independent, there would have to be a standard interface to push services, that requires just a few details to be configured such as the URL and authentication details.

garyd9 · 9 Jan 2018, 18:27

Why bother with authentication? The DWC is insecure as it is. If some process is needed on a PC or RPi, then let it handle the auth.

So.. my idea on this:

Keeping in mind that whatever notification is sent from the duet (and not from DWC), I'd imagine it would have to be extremely small/tight. That being said, and trying to imagine how I'd implement this as simply as possible, can the duet simply open a TCP socket and perform the equivalent of an HTTP GET?

So, there'd be hard coded notification types. Perhaps "printing", "paused", "stopped", "done", "error", etc (Or just notification numbers. 1, 2, 3, etc - each number having some meaning.)

Then a user configures a simple string that gets prepended to the notification string. For example:

M1234 P"http://mynotification.server.com?notification="

The duet, when any event occurs, just tries to make the call. Timeouts should be short, no retries, etc. Unless it's in some debug mode, and errors are ignored. Basically, the duet shouts something out and ignores the result (if any.)

Then a RPi, PC, or whatever that is running a "server" on mynotification.server.com gets the notification and decides what to do with it. It might ignore it, might run wget/curl/whatever to get more status info from DWC and/or forward the notification (along with encryption, authentication, etc) to something else.

On the duet side, KISS.

Edit: I don't think the duet has any DNS abilities, so the "URL" string would have to be an IPv4 address and not a name. So, replace the fictional "M1234" command with:
M1234 P"1.2.3.4?notification="

JohnOCFII · 9 Jan 2018, 18:38

@Luca79:

FYI, I am developing a telegram bot (in testing phase) to the purpose that can easily run on a RPI Zero. I will keep you posted as soon as the code is stable I will opensource it.

I'm running a Telegram Bot from my other printer so when you are looking for testers with the Duet, put out a request and I'm sure you'll get me (and others) to help test.

Cata · 9 Jan 2018, 18:50

Have some RPI zeros and love the telegram bot

IdefixRC · 20 May 2018, 14:30

@luca79 said in Notification via Pushover or other service:

FYI, I am developing a telegram bot (in testing phase) to the purpose that can easily run on a RPI Zero. I will keep you posted as soon as the code is stable I will opensource it.

Hi Luca,

any news on the telegrambot? Looking so forward to it

dc42 · 21 May 2018, 07:31

I have added Pushover notification support to the firmware work list. I need to get firmware 2.0 released before I implement this or any other new features.