Contents


IoT Lessons Learned

Lessons learned from my first DIY IoT project

Comments

Content series:

This content is part # of # in the series: IoT Lessons Learned

Stay tuned for additional content in this series.

This content is part of the series:IoT Lessons Learned

Stay tuned for additional content in this series.

I have been a DIY person my whole life. From building numerous contraptions out of old plywood and 2x4s in the backyard when I was a kid, to fabricating parts and test equipment to help calibrate sensitive astronomy instruments when I was in college, I have always loved getting my hands dirty and working "close to the metal."

These days, I've got an electronics shop in my home, where I've built robots from old mouse parts and worked on numerous other projects from Nuts and Volts magazine. I know my way around a soldering iron, and heck, I even have a Tektronix 100MHz 4 channel oscilloscope I'm very proud of:

My Tektronix 2246 100Mhz 4-channel oscilloscope
My Tektronix 2246 100Mhz 4-channel oscilloscope

So when I was offered the opportunity to put together a tutorial series where I built a smart home system from scratch, I jumped at the chance! IoT smart home? Heck, yeah, I've got this. Big time. IoT? Yeah, I'll own those "things" in no time.

Or so I thought.

Now, allow me to say up front that the IoT smart home automation project was one of the most awesome and fun projects I've ever done. It was also one of the most difficult, frustrating, and tedious projects (and if you've ever built a Sumobot from a kit, you know that's saying something).

In this article, I share with you some lessons that I learned while putting together the smart home automation system I built for my tutorial series called IoT and the Smart Home. If you've decided to tackle an IoT DIY project, maybe these lessons can save you some time, energy, and money.

1

Choose your parts carefully

Depending on your IoT project, you might want to consider an IoT developer kit. Because I'm a serious DIYer, I did not for a second consider any of the Raspberry Pi 3 kits.

There are so many Raspberry Pi 3 kits you can order, it can be overwhelming (perhaps intentionally). They all come with lots of seemingly great add-ons like a case, heat sinks, HDMI cable, micro SD card, and the like. In my book, I say forget it. Just order the Raspberry Pi and a power adapter, and that's it.

In my mind, why pay a premium for a kit that contains a micro SD card preloaded with NOOBS (or some other OS you might or might not want), when you can save yourself some money and order the SD card separately and then burn the image of your choosing onto it?

Speaking of SD cards, when I first started the project, I only had one micro SD card. As I was experimenting with the project, installing software, figuring out what I actually needed versus what I had already installed as I was experimenting, there were times when I installed software that I couldn't cleanly remove once I realized I didn't want it. It would have been nice to be able to back up to a "known good" state. But with a single SD card, my options were to trudge forward (not really certain what the state of my Pi was) or erase it entirely by burning a new Raspbian image onto it.

So I ordered two more 16GB micro SD cards. I could experiment with reckless abandon, and I had two other Raspbian Stretch installations I could boot up with if I installed something that turned out to be bad news. Plus, I was able to create different configurations (like separate "profiles," if you will) of the software to run the smart home and boot up the one I wanted just by swapping out the SD cards.

Oh, and by the way, make sure you hang on to your Raspbian image (or whatever image you download and install on your SD cards). I must have downloaded the Raspbian Stretch image three or four times before I realized I needed to burn it again. You know what I mean: I thought, "Surely this will be the last time I'll need to burn this onto the micro SD card" and then turned out to be mistaken. Any OS image is a large file, but I recommend you keep it on hand. Avoid the lengthy download. This seems obvious, and I'm slightly embarrassed to admit it took me so long to figure it out.

2

Pick a communication protocol and stick with it

The IoT device landscape is fragmented. There are thousands of IoT device types and lots of communication protocols. In the radio frequency (RF) band where I chose to operate, there are three main players: 433MHz, Z-Wave (908.42MHz), and Zigbee (2.4GHz). But there are also other wireless protocols like Bluetooth, Bluetooth Low-Energy (BLE), WiFi, Touch, Cellular (like 3G/4G), and if you want to get up-close and personal, there is Near Field Communication (NFC).

If you want your devices to work together, you need to pick a protocol and stick with it. I chose the 433MHz band for the Smart Home project. Compared to the other protocols, it had the widest range of low cost hardware, lots of open source system software (middleware) for communicating with the devices, and loads of sample source code. It seemed like the logical choice, and — this being my first IoT smart home project — had a much lower barrier to entry versus Bluetooth, BLE, WiFi, and the other available protocols.

I resisted the urge to mix and match devices that use different frequencies, which would require different hardware and software for that frequency. Why complicate an already complicated project? Pick a frequency and stick with it.

Then, after you make your choice, you need to be careful about the devices you purchase. It's not always clear from the product description that the device you want speaks the protocol that you need it to.

I came very close to ordering a WiFi RF Outlet for the project, because it came up in a search of "433MHz RF Outlet," and I didn't pay very close attention to the technical specs.

A promising RF outlet, right?
A promising RF outlet, right?

Just before I was ready to check out, I was interrupted (fortunately, as it turns out). When I came back later, I examined my shopping cart more closely and noticed the RF outlet that I was about to order was not a 433MHz device.

No, wait, it's not the frequency I want!
No, wait, it's not the frequency I want!

I got lucky, but that mistake could have cost me time, energy, and a lot of frustration (not to mention money). Read the specifications carefully. If you're working on a 433MHz project and the device you're thinking of ordering does not explicitly state that it uses the 433MHz band, do not order it. Period.

3

Draw diagrams... lots and lots of diagrams

A picture is worth a thousand words, right? As you can see, I'm no artist, but I draw pictures in my notebook, on the whiteboard, or pretty much anywhere I am when an idea hits me. I like to approach every project I work on in IT as if it was a scientific research project.

From my notebook: CPVan RF remote encodings
From my notebook: CPVan RF remote encodings

This picture is from my lab notebook and shows the encodings for the CPVan home security remote control. It's important to me to capture information like this as I work on projects like the smart home. Why? Let me tell you a story.

When I was an undergraduate physics student, I had the privilege of studying under an astronomer named Al Grauer, whose specialty was studying how the light output of stars varied as a function of time. One night, as we shivered in the sub-freezing temperatures under the dome of the 61-inch telescope at Mount Bigelow in the mountains of southern Arizona, I noticed he was taking notes. I asked him what he was doing, and his answer changed my life.

He showed me his research notebook: a bound notebook full of graph paper (called a quadrille notebook). In it were diagrams of the sky, graphs of data points, and various other stellar observations. "Write everything down," he told me. "As a scientist, you record everything you can," he went on to say, "because it's all about the data."

He reached into his backpack, pulled out an empty quadrille notebook, and handed to me what would be the first of many such notebooks I would fill over the next three decades. Using these notebooks is a habit that I use to this day. Here is a picture from my lab notebook of the encodings for the Etekcity RF Remote control.

From my notebook: Etekcity RF remote encodings
From my notebook: Etekcity RF remote encodings

When I was working on the Smart Home series, I drew pictures of the remote controls I was working with like the one above, and added the encoding values of the corresponding buttons on the remotes.

Write everything down. You never know what you will need later. Taking good notes is just good science.

4

Don't reinvent the wheel

Take advantage of those who have come before you ("Stand on the shoulders of giants") and the work they have done. I knew I wouldn't try to build my own IoT devices. I love to build things, but I knew that I would buy any IoT devices that I used for the smart home project.

When it came to the system software (the middleware) running on the Pi to communicate with the hardware, though, I thought how fun it would be to write the system software myself, but that turned out to be hard. Really hard. I quickly learned that there were lots of open source libraries out there like wiringPi, rc-switch, and 433Utils (to name three that I used in the series), and I decided to use them. There is no dishonor in not building everything from scratch.

Here, be giants (or some other giants). Let me give you two examples.

First, to enable the Home Automation Controller — running on the Pi — to communicate with the Watson IoT platform, I decided to use Node-RED, mainly because the code was easier to develop and test (plus there is something about the flow-based programming paradigm that is just really awesome).

But how would I communicate with Watson IoT? Fortunately for me, there are great components available for Node-RED, and I used those, which allowed me to focus on solving the problem at hand, rather than writing the middleware.

Next, to enable the Android client app in the Smart Home series to communicate with the Watson IoT platform, I needed an Android MQTT client. There are many good MQTT libraries out there, and I evaluated several before deciding to use Eclipse Paho Android Service. It handles the intricacies of background processing on the Android platform, again, leaving me free to focus on the functionality.

Combine thorough research with the use of open source libraries for your project to find the balance between the joys of creation and the satisfaction of timely delivery of the ultimate solution.

Conclusion

Most IoT projects are quite complex, with lots of moving parts and lots of things to be connected and configured. In this article, I shared some of the lessons that I learned while doing my first complex IoT project, a smart home automation project. Hopefully, these lessons can save you the time, energy, and money, but also some tooth enamel (you know, from all the gnashing of teeth).


Downloadable resources


Related topics


Comments

Sign in or register to add and subscribe to comments.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Internet of Things
ArticleID=1060382
ArticleTitle=IoT Lessons Learned: Lessons learned from my first DIY IoT project
publish-date=04262018