Projects Research & Design Hub

DIY IoT Solution (Part 1)

Photo 2 This is my phone running the Particle app and Tinker firmware. It is controlling D7, which is connected to an on-board LED. Tap the D7 icon in the app to toggle the LED on and off. Note that the USB cable is only providing power
Written by Tom Struzik

Hardware and Firmware

The Internet of Things (IoT) is the new “everything solution.” However, for small problems, the first step in an IoT solution can be large because it crosses so many technological boundaries: sensors, mechanics, power, radio, Wi-Fi, web, smartphones, and so on. In the first part of this series, Tom explains how he built the hardware and firmware for a Photon-based garage door monitoring system.

  • How build the hardware and firmware for a Photon-based garage door monitoring system

  • How to get started with the Photon board

  • How to develop the firmware

  • How to debug the firmware

  • How to enable Photon to send an e-mail

  • Photon IoT Wi-Fi board from Particle

  • Tinker firmware from Particle

  • Particle Cloud

  • PHP Spark Photon Web Dashboard

I used to have a problem. When I was inside my house, it was almost impossible to determine if my detached garage’s door was open or closed. Thus, there were many nights when the door was left open. The question was, what to do?

Initially, I attempted to solve this problem in a very analog fashion with a simple 315-MHz ASK transmitter/receiver pair, a mechanical switch, and an LED. It worked, but it was not reliable. It also did no good when I was halfway down the street wondering if I’d left the door open. It was clear that a better solution was required. I needed something reliable. I needed a solution that was accessible from a smartphone. I needed a programmable solution that could account for the fact that sometimes I wanted to leave the door open, at least for a while. What I needed was a processor, a Wi-Fi interface, and enough Internet enablement to be able to send e-mail and interact with a smartphone. I finally realized what I needed was an Internet of Things (IoT) device.

Many of the solutions I initially looked at (e.g., an ESP8266 Wi-Fi module) were intriguing, but they were too simple and not complete solutions. On the other side, I found modules like Intel’s Edison that were more expensive and represented a complete wireless computing platform all in one package. There had to be a happy medium. In this article series, I present my solution.

IoT WI-FI BOARD

At this point I stumbled upon the Photon from Particle (www.particle.io), a single module that included both a 120 MHz M3 ARM Cortex processor and a Broadcom Wi-Fi chip. Even better, it included a web-based IDE and a free back-end cloud service to simplify interfacing with the rest of the internet world. Their stated goal was that you should be able to build an IoT device prototype in minutes. At $19 it seemed a perfect fit (see Photo 1).

After my Photon arrived, the first thing I did was browse over to the Particle website and the Photon Getting Started guide. Reviewing the intro, it was organized with the expressed purpose of getting my new Photon up and running as soon as possible. The Photon includes an on-board LED to test with so I did not even need a breadboard to begin. One key piece was the Particle App (available for Android and iOS) and the out of the box “Tinker” firmware delivered with the Photon. Those two parts, working with the Particle Cloud, allowed me to immediately begin interfacing with the I/O ports on the Photon from my Android phone.

I followed the “Anxious to connect right away?” link in the Getting Started guide and immediately began the process of initializing my Photon. Once I downloaded and launched the Particle App on my smartphone and powered up my Photon, the App walked me through the process of getting the Photon’s W-iFi connected to my local network. After a few quick steps, my Photon was talking to my wireless network and I was in control of my Photon. It was a simple matter to define pin D7 as a digital output and start toggling the on-board LED on and off (see Photo 2). Success, and all in less than about 5 minutes! They certainly were right about getting up and running as soon as possible.

— ADVERTISMENT—

Advertise Here

Photo 1  The Photon IoT device as delivered. Just connect power and off you go.
Photo 1
The Photon IoT device as delivered. Just connect power and off you go.
Photo 2 This is my phone running the Particle app and Tinker firmware. It is controlling D7, which is connected to an on-board LED. Tap the D7 icon in the app to toggle the LED on and off.  Note that the USB cable is only providing power.
Photo 2
This is my phone running the Particle app and Tinker firmware. It is controlling D7, which is connected to an on-board LED. Tap the D7 icon in the app to toggle the LED on and off. Note that the USB cable is only providing power.
SELECTING SENSORS

As exciting as getting a complete IoT device up and running in 5 minutes was, I had an actual problem to solve. The first question was, what besides blinking an LED, did I need to do? First and foremost, what I/O would I need to connect to the Photon? Certainly two mechanical switches for determining when the garage door was in the opened or closed position. Second, it might be nice to have an output that ‘pushed’ the garage door open/close button. Third, a day/night sensor would be good as I wanted to change what was considered “open too long” depending on if it was light outside or not. Also, as I was working on designing an IR distance sensor for another project, adding two IR sensors to detect when cars were present seemed reasonable. Finally, just because the Photon had a built-in I2C interface, I wanted to try it out. I added an I2C temperature sensor to the mix (see Photo 3).

FIRMWARE DEVELOPMENT

Once I had the basic circuit design determined (see Figure 1), it was off to building firmware. The Photon module came with the pins, so it was a simple matter to stuff the module into a breadboard and start development of Photon firmware and the I/O devices. For the simple digital and analog I/O devices, I continued to prototype the sensors only using the Tinker firmware. In fact, for a simple application, it might be possible to get by just with the Tinker firmware, but because I wanted to use the I2C interface, I needed to move beyond Tinker.

To move beyond Tinker, I had to understand a bit more about how all the pieces fit together. The basic concept was that the Photon makes variables and functions available to the Particle Cloud. Then, end-user applications communicate with the Particle Cloud in order to interact with the Photon (see Figure 2). The source code for the Tinker firmware was available on the Web IDE, so it was simple to use that as a starting point to add my own function to return the data from the I2C temperature sensor. But how would I call the function? The stock Android Particle App could not call additional functions. Was I going to have to build a whole new Android App in order to test my new I2C temperature sensor function?

My initial solution was to dive into the Particle CLI interface available on Windows (and Mac OS X and Linux). I followed the installation instructions on the Particle website and soon had the Particle CLI up and running. With the LIST command, I could observe what functions the Photon had published. Since it was still running the original Tinker firmware, there were four functions: digitalread()digitalwrite()analogread(), and analogwrite(). Using the Particle CLI, it was possible to manually call any of these functions and observe the results. Once I wrote my own function, this also allowed me to call it and verify correct operations.

Later, I ran across a web dashboard written in PHP for the Photon. The dashboard was nice in that it listed all the variables and the functions that my Photon had published. It showed the variables current value and allowed me to call each of the functions and display the result. It was a much easier troubleshooting tool to set up and use than the Particle CLI. I wish I had found it sooner.

The next step was to dive into the Web IDE to add my own I2C function into a copy of the Tinker firmware. With the Web IDE, I could edit, compile, and flash my new firmware all from one place (see Figure 3). One key part of the Web IDE was the ribbon bar on the left side that included links to all the Photon reference documentation. Of specific importance at this point was the Docs link, which pointed to the Particle Device Firmware libraries under the Reference tab. Under the Firmware heading, it contained documentation on utilizing the built-in I2C functionality.

Figure 1 The Garage Door Minder circuit design features a Particle Photon and a handful of sensors.
Figure 1
The Garage Door Minder circuit design features a Particle Photon and a handful of sensors.
Figure 2 Normal end user interaction with the Photon module is through the Particle Cloud.
Figure 2
Normal end user interaction with the Photon module is through the Particle Cloud.
Figure 3 This is the web IDE with which you can edit, compile, flash your firmware, and access reference documentation all in one place. Also available here are many community-supported libraries and examples.
Figure 3
This is the web IDE with which you can edit, compile, flash your firmware, and access reference documentation all in one place. Also available here are many community-supported libraries and examples.
DEBUGGING

The tricky part of any firmware development is how to debug the code. This was even more challenging here because the code ran on a device not physically connected to the Web IDE. My solution to the debugging problem was that, when the USB port on the Photon was plugged into a PC, it created a serial port on the PC. The Photon firmware libraries included routines for serial I/O, specifically Serial.print(), which writes a string to that USB serial port. By running an appropriate terminal emulator on the PC, I was able to do some basic “print statement” type debugging. Primitive, but passable. That was until I re-flashed the firmware. The USB serial port stopped working! Digging though the Particle website, I finally stumbled upon the solution. You must exit the terminal program prior to flashing the Photon. Also it advised placing a statement to wait for a key press in the Photon Setup function. An example of this is shown in the code in Listing 1.

Listing 1
I use Serial.print() statements as debugging tool. Continuing to call Particle.process() while waiting for the key press is critical to ensure that background startup processes complete successfully. As you can see here, Serial.print() is used to begin testing for building an SMTP class.

TCPClient client;
void setup()
{
  
  // printing of debug statements over the USB serial interface
  
  Serial.begin(9600);   // open serial over USB port...

  // Make sure terminal emulator is closed 
  // power up the Photon device
  // Open terminal emulator and connect
  // Hit any key, to continue beyond this firmware location

  while(!Serial.available()) Particle.process();

  Serial.println(“ Attempting to connect...”);

  if (client.connect(“SMTP.FATCOW.COM”, 587 )) {
    Serial.println(“connected”);
  } else {
    Serial.println(“connection failed”);
  }
} // end setup()

Once I had the new I2C function written, the only thing left was to publish the function to the Particle Cloud by calling Particle.function() from the Setup function. With that I was able to use the Particle CLI to call my new I2C function and observe the I2C temperature sensor’s current value.

SENDING E-MAIL

But I wanted more. I wanted the Photon to notify me automatically when it detected that the door had been opened too long. The question was: how could I do this? I quickly scanned the available Photon libraries and found no SMTP module. So, at least, out of the box, having the Photon send e-mail was out of the question. There appeared to be no direct way for the Photon to use the Particle Cloud to send e-mail either. I really wanted the Photon to send e-mail directly. How hard could it be?

— ADVERTISMENT—

Advertise Here

With Google in hand, I found an open-source SMTP Class Library written in C. This Class Library had more functionality than I needed, so a little trimming was necessary; but ultimately, it was relatively simple to port the C code over to the Photon. However, I then discovered it was almost impossible to find a mail server that would actually allow the connection! Very few public e-mail servers support PLAIN authentication and that’s all the CSMTP class library I found supported. Not supporting PLAIN authentication is understandable given its lack of security. I ended up coding in support for both LOGIN and CRAM-MD5 authentication mechanisms, which gained compatibility with a few more mail servers, but even this still limited which mail servers could be used.

Ultimately, my goal was to be able to send mail using the Gmail mail servers, but the smtp.gmail.com servers only accept TSL or SSL connections. That looked like it was going to require porting SSL to the Photon, which would be a much more extensive port than the SMTP Class. Then inspiration struck. The SSL tunnel didn’t really need to be on the Photon itself! I already had an sTunnel server running on one of my Windows boxes. If I could get the Photon to connect to my Windows sTunnel server, then the sTunnel server could connect to the Gmail servers with the necessary encryption. This worked (see Figure 4). The only trick ended up being that Google required me to use an application-specific password rather than my normal Gmail account password. Once that was set up, the Garage Door Minder could send e-mail directly via Gmail!

Figure 4 I’m sending unencrypted SMTP requests through an sTunnel to become encrypted in order to meet the Gmail SMTP server encryption requirements. 
Figure 4
I’m sending unencrypted SMTP requests through an sTunnel to become encrypted in order to meet the Gmail SMTP server encryption requirements. 

Now the Garage Door Minder could send e-mail alerts whenever the door was left open too long, but this was still a closed system. I wanted to be able to remotely query status and even remotely push the door open/close button. For that, I would need to build some type of application or web interface, and that’s where I’ll begin again next month. 

RESOURCE
Particle, “Introduction to the Guide,” https://docs.particle.io/guide/getting-started/intro/photon/.

SOURCES
PHP Class for interacting with the Spark Cloud (spark.io)
PHP Spark Photon Web Dashboard
Harrison Jones | https://github.com/harrisonhjones/phpParticle | http://projects.harrisonhjones.com/phpSparkDashboard/index.php
SMTP Client
Jakub Piwowarczyk | www.codeproject.com/Articles/28806/SMTP-Client
Photon IoT Wi-Fi board
Particle | www.particle.io

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • DECEMBER 2016 #317 – Get a PDF of the issue

Keep up-to-date with our FREE Weekly Newsletter!

Don't miss out on upcoming issues of Circuit Cellar.


Note: We’ve made the May 2020 issue of Circuit Cellar available as a free sample issue. In it, you’ll find a rich variety of the kinds of articles and information that exemplify a typical issue of the current magazine.

Would you like to write for Circuit Cellar? We are always accepting articles/posts from the technical community. Get in touch with us and let's discuss your ideas.

Sponsor this Article
Website | + posts

Tom Struzik (www.JenRathbun.com/Electronics/) has been building and taking things apart from an early age. He built his first Heathkit project at age 12 and sold his first computer program at age 16. Tom has a BSEE from Purdue University.

Supporting Companies

Upcoming Events


Copyright © KCK Media Corp.
All Rights Reserved

Copyright © 2022 KCK Media Corp.

DIY IoT Solution (Part 1)

by Tom Struzik time to read: 10 min