Email/notifications from Duet wifi
-
Anyone know if it is possibleto get email/notifications from Duet wifi? I was looking at chrome based apps to monitor the DWC web page (and look for changes in text etc.) but these all seem to need the DWC to be available to the internet which is not something I wish to do! I did have a little bit of success fitting a buzzer that sounds when the heated bed has been off for 5 minutes but this is far from optimum!
Ideally what I want is a pop-up or email on my phone when the print is done (or there's an error/filament out) so I can pop into the room the printer is in as have recently moved it into the next room to minimise working in the fumes (as well as running in enclosed with an activated carbon filter).
I do have a webcam monitoring it but often find a print has finished 2-3 hours before I notice!
-
-
Our latest thoughts about this are to embed a MQTT client in RRF that publishes messages about the current state of the printer e.g. printer powered up, print started, print completed, print paused by filament monitor.
-
@dc42 MQTT integration would be awesome... my home automation uses an mqtt broker and openhab so I could check print status securely anywhere via the openhab internet gateway and mobile app.
-
@dc42 said in Email/notifications from Duet wifi:
Our latest thoughts about this are to embed a MQTT client in RRF that publishes messages about the current state of the printer e.g. printer powered up, print started, print completed, print paused by filament monitor.
any ETA there?
-
@dc42 So there will be a implematation for Google Home/Alexa with some commands like:
''How long does the Print take to finish?''Or:
''Pause print''
-
@AS-3D-Druck thats should be doable with MQTT then.
But @dc42 didnt mention anything about receiving commands via MQTT.
So only getting status info for now?! -
Basically everyone wants to get a message on their phone saying either "print finished"; "change filament" or "heater problem"... Could be by e-mail, by SMS, by some more custom means..... We just want the notification so we can stop checking on our printer (s) and concentrate on doing other things (having dinner, chatting, sleeping....).
Is the MQTT option difficult to setup? How is it received on the phone?
This will be a big ease-of-use leap forward: let's not hang around!
-
Having an MQTT push is easier.
However, right now, any RRF release short of 3 can be polled by HTTP. There are lots of examples, including things that run on tiny little IOT devices like ESP8266 or ESP32. Or a little script running somewhere could then connect to whatever push notification you want.
Or... on your local network, build one of these: https://github.com/DanalEstes/DuetMonitor
RR3 can be polled by websocket. Not as many examples, because it is newer.
-
@Danal what would the MQTT push be read by on my phone? A Duet specialist app? Or...
-
MQTT is a defacto standard for IOT interaction. The most effective way to use it with a 3D printer that produced MQTT messages would be to configure (not code) a small MQTT broker on an always running machine at your house. PC, Mac, Pi, whatever. Probably mosquito.
That MQTT broker would receive the messages, and invoke whatever you want to push to your phone. SMS, Email, Pushover, Airship, whatever service you wish.
-
Why not just write a "send email" capability into the Printer? Because that would (more or less) require the printer to contact a web IP address. Bad, bad juju to have IOT devices like printers open anything to the internet.
Also lack of flexibility. There are dozens, if not hundreds, of notification services. The printer firmware would always be lacking some specific interface.
MQTT from printer to broker, broker is the one handling internet stuff, and can probably interface to almost anything, either built in, or via command line. Much better juju.
-
I thought ssl smtp access was just a single port?
An IOT gadget can’t be made “broadcast only” (thus safe) in its internet access?
-
@r123 said in Email/notifications from Duet wifi:
I thought ssl smtp access was just a single port?
An IOT gadget can’t be made “broadcast only” (thus safe) in its internet access?
Safe is relative. Better that a firmware based device have absolutely zero direct connectivity. In, out, whatever.
But really, the much bigger reason is... what list of things to support from the firmware? "Just" SMTP?? What about SMTP with authentication? (there are VERY few open mailservers around anymore). With TLS? or some other encryption? or MAPI (a much more secure mail protocol)? Or...
MQTT for IOT devices. MQTT broker to do anything you want.
-
@dc42 Is there any update on the MQTT progress?
Will it be available with RRF 2 or only with the new RRF3 ?Will it publish all information from the WebIF? Like temps, speed, job status etc?
-
@Nightreaver said in Email/notifications from Duet wifi:
@dc42 Is there any update on the MQTT progress?
Not yet.
Will it be available with RRF 2 or only with the new RRF3 ?
I will not be adding any new features to RRF2.
Will it publish all information from the WebIF? Like temps, speed, job status etc?
No, just "major event" messages. Other devices can use HTTP requests rr_status and rr_model to get the data they want.
-
@dc42 said in Email/notifications from Duet wifi:
@Nightreaver said in Email/notifications from Duet wifi:
@dc42 Is there any update on the MQTT progress?
Not yet.
@dc42 Any news on that?
-
For those who are interested...
I took a similar solution for MQTT and adapted it to duet3d api endpoint.
It works fine so far as im using it for myself, tho not all options for MQTT publishing are implemented yet.
Feel free to try it and report bugs. -
I'll definitely try this mid-December after my current printing set is complete.
One thing: In my MQTT experience, it's a good idea to have a topic like "State" where you set the last-will to publish with retain a payload of "Offline" and then in the connect routine, publish a payload of Online" with retain.
That way, you can check the state easily without looking at any other topics.
I see you have a last-will set, but I'm not familiar with those three systems, so I don't know if that's the by-the-book way to use last will. If so, ignore me.
Also, it's also good to have a unique device ID in the topic so many devices can all publish to a broker and you can weed them out by which topics you subscribe to.
-
I see, thats what LWT means! I will check up on that topic, thanks