Email/notifications from Duet wifi
-
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
-
@Nightreaver Cool.
You can contact me anytime for MQTT-related discussions.
I spent 4 years doing commercial MQTT implementations on tiny microcontrollers and have tens of thousands devices in the field talking all day long.
