ESP8266 Arduino SMTP Server part 3

This is a continuation of part 2, and expands to use the solution developed in this post, along with the latest findings about the specific DVR I’m using.

After creating the linux service described in one of the above links – which received a packet and plays a doorbell sound – the ESP server was modified to relay this signal. The modifications are as follows:

At the top of the sketch, the IPs of my computers were added as such: IPAddress terra(172, 21, 42, 3);

In the beepC routine called by the SMTP handler, code to send the UDP packet trigger was added:
WiFiUDP Udp;
Udp.beginPacket(terra, 42001);
// send a reply, to the IP address and port that sent us the packet we received

Finally, a routine using the millis() function was created to send a ping to a separate port every 120 seconds, which causes the computer to add an entry to a log file. This is so the proper functioning of the device can be checked.

After all this was done, I discovered the DVR sends an email on motion detection, as well as after the delay period is elapsed. The email content is:
(plaintext)Attention please, channel 1 motion detected at 2015-07-21 11:13:44!
(plaintext)Attention please, channel 1 motion resume at 2015-07-21 11:13:45!

In order to only beep on motion detected, the sketch had to be modified to ensure the email body contains “R” at offset 51. But this came with an additional issue: Somewhere in the communication between the two devices, there’s a pause after the “RCPT TO:” command, causing a couple-second delay and occasionally tripping the watchdog timer, causing the device to reset.

It’s arguably possible to count the 120s after tripping the motion detection, to delay further signalling. But this will only work if the chip doesn’t reset, and as I previously established, the DVR doesn’t handle an incomplete SMTP handshake very well.

Turns out, it’s the ESP8266 that delays after attempting to send data. I didn’t really feel like investigating or rewriting everything, so the fix involved removing as much data as possible from the send strings, and even tossing out one. This probably goes back to the DVR’s poorly written SMTP client, which sends a ton of data, disregarding the handshake and filling up the buffers, causing a delay. This fix worked for the test email, but the motion detected email still paused occasionally.

The final solution involved a combination of methods. Having eliminated the watchdog timer reset by slimming the SMTP responses, I added a variable to track when it beeps, so the device beeps on the third line in the handshake (before the delay occurs), and then doesn’t beep within 65 seconds (I changed the delay to 60s on the DVR)

The final code: