The code is here. The credentials and recipient email address are defined in email.h at the moment, so changing settings requires a reflashing at the moment.
The ESP8266 does a DNS lookup for gmail's SMTP servers, then connects with SSL, logs into an email address I set up specifically for this device and sends off an email. I have only tested this with gmail, where I enabled the option to allow "less secure apps" and also created an app-specific password (I don't know if other email services provide this) - which is a necessary precaution, as I haven't implemented certificate verification yet.
If you ever want/need to debug SMTP over TLS/SSL, as I had to do a lot of, here's a useful command to run on Linux if you have OpenSSL installed (you most likely do):
openssl s_client -crlf -connect <server>:<port>
It lets you talk directly to the server in plaintext from a terminal, just as if you were using a telnet terminal to talk over an unencrypted connection. The only thing to note is, do not send the character 'R' as the OpenSSL terminal intercepts this and interprets it as a command to renegotiate. This caught me up for a long time when I was trying to send "RCPT TO: ..." as you do for SMTP; lowercase is a better choice it seems.
Here's a screenshot of sending an email with SMTP, as I thought would be a good idea to figure out how to do by hand before implementing it on the ESP8266. The lines with numbers 1-7 are steps/commands that I sent. The authentication string (step 2) is just the username concatenated with the password, all encoded in base 64.
Some additions to the web page interface:
The page now looks like this before any sensors are triggered:
The additions are the new options to arm/disarm the alarm and time stamping. Pressing these buttons achieves the same thing as pressing the wireless key fob which came with the original alarm base station, which this alarm system now listens for.
After some sensors have been detected:
A printed case:
"But it looked alright on the computer"
Definitely only a first revision enclosure. I designed it a bit small, with walls too thin as well, so it doesn't quite close properly, and the overlap/interlocking bits are tiny (can't really see them in the photos).
Also - oops: I tried polishing the printed plastic with an ABS plastic and acetone solvent solution... but it was white ABS dissolved in the acetone.
Conclusion:
In all, seemed like it would be an easy feature to add; SMTP is simple after all, but to get this one working reliably was a challenge with the complexity of needing SSL on the ESP8266. So if you are looking to get SSL working on the ESP8266 and need more working examples take a look at the code.
I put the CNC engraver to use milling a prototype single-sided PCB for the ESP8266 alarm system I've been working on. The tutorials on the internet for PCB2Gcode and KiCAD were pretty easy to follow, so this post is not a tutorial, but just for documenting my experience and some gotchas.
Design
The final design of the board in KiCAD
The board is a connector board really. It powers the ESP8266 module at 3.3v and the 433MHz module at 5v, pulls up the reset and CH_PD pins on the ESP8266 and the buttons allow it to be easily reset and programmed (there's a UART header on the board too). For the wireless alarm system side of things it has a connector for the 433MHz wireless module to plug into, the output of which is voltage divided to get it down from 5v to somewhere in the neighbourhood of 3.3v, which the ESP8266 can handle.
Toolpath generation
Converting the Gerber and drill files from KiCAD into G-code instructions with PCB2Gcode.
You always have to watch out for potential issues with mirroring at this point in the process, otherwise you might mill and drill a PCB only to find it "off" somehow. That reminds me of an early trap I ran into in KiCAD of the SMD component pads being on the opposite side of the board to the traces. This of course makes no sense for a single sided board without vias. The side that traces and SMD footprints are on can be changed, however.
The drill files were a bit of a nightmare because this PCB needed about five different drill sizes ( which I have), but it means lots of tool changes. The G-code that PCB2Gcode outputs also seems to expect your machine to be capable of automatic tool changes, which mine cannot do. I got around this by manually separating the G-code for each drill size into its own program. I'll have to look into writing a script to do this for me and/or insert a pause command into the G-code, if the feature does not already exist in PCB2Gcode.
It's important that Grbl doesn't have its position zeroed out between programs or it'll make a mess of things. Alternatively, and to be on the safe side, have the machine return to (0,0,0) position at the end of each file and don't do any homing, just so you always have a reference point.
Engraving/Milling
The tooling that was used. None of the tiny little drills were broken, to great surprise. The v bits on the other hand are made of a fair hunk of carbide and are really tough - I accidentally cut the board outline in a single pass (~1.2mm cut depth) and there weren't any issues.
The CNC engraving setup with the board in the process of being engraved.
The finished board.
The clamps holding the board down were scarily easy to undo after
all the vibration of cutting; I'll have to put spring washers under the bolts to stop them coming loose. If the board had come loose in the middle of cutting I would have had to start over again without any way to align the board to the bed.
Even more closeup. Not all traces have been fully isolated, and some have too much taken off. The board must not have been completely flat and level, and I think the settings have underestimated the dimensions of the cutting bit.
A bit more tuning of the settings in PCB2Gcode will be needed, and probably also a program which probes the surface of the board before cutting to determine where the surface of the board is, so that a constant cutting depth can be achieved.
The populated board. The ESP-01 breakout board is socketed (can't be seen from this angle).
EEEEKKK! Not nice soldering. I blame the lack of soldermask and the pads coming out undersized - did not make for very forgiving conditions. There's also one bodge wire, for a trace that was completely wiped out; it isn't very easy to make out in the photo however.
Assembled and ready for programming.
There's a 0.1mm copper wire soldered (and secured with a blob of hot glue) onto the actual QFN package of the ESP8266 to get access to an additional GPIO pin because the ESP-01 board does not break out enough free GPIO. This was actually factored into the design, so the board I designed has a pad which the other end of the jumper lead is soldered onto.
More to come on the ESP8266 wireless alarm system soon...
I bought a light CNC milling/engraving machine off eBay to mill PCBs and other parts in future. I'd have liked to try building my own, but that will have to be a project for the future, if I need a sturdier or larger machine.
The machine, of model "CNC 3020T" (which refers to its travel area of 30 x 20 x ~7cm), came pre-assembled in a large box. There are a lot of similar CNC machines on eBay/Aliexpress in terms of size and style of construction, and there appears to be the option of a model with ball screws, as opposed to the trapezoidal lead screws in the "T" model. I haven't had any issues with backlash yet, but I imagine that depends on loading and how worn the nuts are.
The spindle takes ER11 collets, so I also bought a set of them separately, as well as some PCB drills and V-bits. Some of the collets are sized for bits large enough that I doubt the spindle would have enough torque be able to mill with them, nor the machine have enough rigidity, but I shall see.
All I had to do after pulling the machine out of the box was fit the stepper motors and wire them into the control box that accompanied it - well not quite... The control box that came with the machine had a parallel port for interfacing with the controlling computer; I do not have any computers with a parallel port, and USB to parallel port converters are not suitable for controlling CNCs due to the tight timing which the step pulses must be adhere to for motion to be accurate and smooth.
Arduino-based control with Grbl:
But there was an easy solution that brought the CNC into the modern era of USB - that was via inserting an Arduino, and making use of the fact that the original control box is fairly basic. It has three stepper motor drivers (one for each axis), a linear power supply (presumably with three rails to supply the logic, stepper motors and the spindle motor), and a PWM controller for adjusting the speed of the spindle. The parallel port on the back has two control pins per axis, which feed straight into the motor drivers via opto-couplers. The control pins are the "step" pin, which causes the corresponding stepper motor to move one step when it is driven high; and the direction pin, where high or low indicates the desired direction of movement. "Step/direction" is the exact scheme Grbl uses and is something of a standard in CNC. Some searching provided guidance on how the parallel port was likely laid out, but I tested the pinout by connecting an Arduino running a sketch which sent 100 pulses over a second, then reversed the direction before sending another 100 pulses, and so on, which confirmed that the pins were correct as one motor at a time started moving. This was after verifying ground with a multimeter and that nothing would obviously blow up my Arduino if I connected it. The pinout was as follows:
DB-25 Pin | Function
2 | X step
3 | X direction
4 | Y step
5 | Y direction
6 | Z step
7 | Z direction
18 - 25 | Ground
The rest of the pins on the parallel port I left unconnected, as they are unused on my machine because it has no endstops nor extra axes, etc.
After that, I uploaded the Grbl CNC software onto the Arduino, then configured the steps per mm (400) and "inverted" the appropriate axes so that the machine follows the right hand rule and the back right corner is 0,0 (the back-right corner is just personal preference, as opposed to the front-left corner, which also works). This configuration was done via some Grbl serial commands which store these settings to EEPROM so that I don't have to re-send the commands every time on startup nor change a config file and then re-compile and re-upload Grbl. Here is Grbl running the CNC according to G code commands I sent manually over serial:
A dedicated control server:
Note: no USB hub is installed yet, so I just plug in either the CNC or the 3D printer
To avoid a big PC sitting in the garage alongside the CNC and 3D printer, I hoped to make use of a BeagleBone running OctoPrint to control both my CNC and 3D printer - it should be possible after all, what with both machines running on G code sent over serial. OctoPrint is a fancy webserver and G code sender written for controlling 3D printers via a browser interface; so any computer on your home network can simply connect up to the webserver on the BeagleBone to control/monitor the printer and upload jobs to it - no more tethering a dedicated laptop!
Well in theory - and indeed 99% of it is there, but OctoPrint wouldn't "connect" with Grbl and so let me send G code, likely because Grbl doesn't support some of the custom commands which RepRap firmware has for reporting temperature, version number, etc. rather than because Grbl lacks any basic G code commands. OctoPrint, as of my admittedly dated install, finds these custom commands crucial. All very frustrating given OctoPrint picked up the serial port fine and both ends supported the same baud rate and were communicating in plain ASCII.
So when controlling the CNC, instead of using OctoPrint, I use the stream.py script that comes in the Grbl repository. At present, this means that I have to SSH into the BeagleBone and transfer G code to it using SFTP, then start jobs over the command line instead of a nice, easy web interface - gah!
Some other hiccups along the way:
Ubuntu on the BeagleBone wouldn't detect hot-plugged USBs (restart needed every time the USB port was plugged/unplugged) - solved this by installing Arch Linux, which must've had a less-funky kernel, because hot-plugging works now (and more free space - didn't want a GUI anyway)!
The USB port on the BeagleBone would get disabled when I turned the power to the CNC controller off while the Arduino was connected to the BeagleBone's USB port. But how?! The Arduino was connected to the stepper drivers through opto-couplers (inside the control box). Even more puzzling, the solution was to change the USB cable to a higher quality one. One where the shielding was actually grounded on both ends. I don't think the BeagleBone was acting as a ground path, because it was on a floating power supply, and the control box, which does have a ground-referenced power supply, also has a grounded case which should stop EM emissions, so I can't really make sense of it. My laptop, also floating, had no issues with either cable.
Conclusion:
All in all, I'm happy with the purchase - nothing was broken or missing, and postage was quick. The control box is useful and easily interfaced with Grbl. I've got a post on isolation routing PCBs coming (and then also a post on the project that I made the PCB for), spoilers: this CNC is more than capable of making a good job of PCBs.
