IoT can be addictive, fun and frustrating

The internet of things (IoT) has been taking the internet by storm. There's been a few practical applications of IoT but Arduino has made the barrier to entry quite low if you're willing to spend some time on it. Overall it's been addictive, fun and frustrating. I'll attempt to document my journey with one of the devices I made.

What is the internet of things?

A very loose definition is one that involves a non-traditional 'thing' connected to the internet so that some form of interactivity can be attained. At least that's my take on it.

A connected device uses firmware usually written in C\C++ and has some sort of on-board bluetooth, wi-fi or ethernet connection. It rarely has any sort of input device (i.e. keyboard) or traditional output device (monitor). So when crafting a device, you'll have to accept that if you switch networks (SSID, IP, etc) you may also have to re-flash the device. You could always integrate with an SD card for configuration, or attempt to remotely flash. These latter things are only for the strong-willed.

IoT devices are usually single-purposed and use cheap parts. There are a few 'platforms' for building IoT hardware and most peoples' first choice is Arduino. Arduino is open-source hardware. To get started you simply go to their website and download their IDE, find some samples, upload to your Arduino device connected via USB to your dev box. A typical Arduino board has no internet connectivity so you'll have to add it (ethernet) or buy something that has wi-fi already built-in. 

 

Making a light blink is the hardware equivalent of 'Hello World'. Once you do that you might just get hooked.

What should I make?

This is the first question to ask once you get semi-interested. My short list of things I want to (or have made):

  • Build server status notification
  • Umbraco version notifier
  • Blog visitor notifier
  • Weather alerter

I've made the last two and the first one is on my radar. My future build server status notifier will be an old Lego Darth Vader clock with the guts removed and red LED's that blink and Darth will say "You've failed me for the last time." However this blog post will document the blog visitor notifier instead.

You should be aware that the device has limited memory\CPU cycles and in general shouldn't be doing a whole lot. If you want to parse an XML\JSON feed on the device; you may want to rethink that and send only small bits to your device.

Communication strategy

In order for something in one part of the internet to alert something in another part, we must have a communication path (duh). I see two options in general:

1) Push notification - I like push notifications. They are efficient and direct and do not require a constant polling of a server. However to pull off a push notification, it requires fiddling with the router via port forwarding. The main issue here is that you have to a) fiddle with the router and b) the public IP can change if your ISP decides it wants it to change. If I tell my blog to communicate to my home network via my public IP, this could easily break and I have to update my website (that sends the push) each time that happens.

2) Polling - Dammit I hate polling but this actually solves my router issue easily. If my device can just "ask for some information" via polling, it simplifies the code on my device. However this means I have to have some sort of API endpoint somewhere to ping.

So polling is the solution I chose. I could have also easily just added an endpoint to my website that the device can reach out to but I instead decided to create what I call is a 'fact' server. In general it's just a key-value pair API exposed to the public internet and secured by API key and\or device ID. The details of the fact server aren't really the point of this blog, but if you want to integrate with it; ping me on twitter. I'd say it's in beta form right now. This image below helps illustrate the interconnections:

My device(s) reach out to the fact server and poll it once every minute. I've added rate limiting to reduce device abuse. When a visitor visits my blog, I tell the fact server; the devices then check the fact server for information. With this information, the devices can decide what to do.

On a side note, I've also added an IFTTT integration that listens to Jeroen Breuer's twitter account. When he tweets, a fact gets created on the fact server if he tweets a certain pattern of characters. He's widely known for tweeting when the Umbraco CMS releases a new version. In the near future, I will have yet-another-device examine the created fact and react.

What's the code look like?

I posted my sketch (Arduino term for the solution) here to inspect if you wish.

So now that you've got the idea that you need some hardware, need a way to communicate to the device; you now need to tell the device to do something. And this for me is where it became fun and frustrating at the same time.

The fun is easy, this 'thing' is gonna do something.

The frustrating is that a slight bit of code misplaced can prevent the device from connecting to your endpoint. Some of the tutorials are out-of-date and some of the cheap hardware I got does not support things like SNI SSL, DHCP, etc.

Also the Ethernet shield (shield is an Arduino term for expansion board) I bought was cheap and it doesn't work properly with a switch and I therefore had to connect it to my PC ethernet port and bridge it to the wireless adapter (super long time to figure that out).

Also parsing the response from your endpoint can be super tricky too. I don't claim to be an expert, but I eventually figured it all out and that's where the addictive part comes in.

My device does only a few things:

  1. Initialize it all (setup() method)
  2. Loop infinitely (loop() method)
    1. Inside the loop we connect to an endpoint
    2. Parse the response
    3. React to the response
    4. Wait (so not to hit the server so much)
    5. Repeat

Those few things can be tricky. Therefore I want to reiterate; avoid any complex logic in your IoT device. Push most of that to your API endpoint. For instance I made a weather box that reacts to severe weather; but the integration with the National Weather Service isn't done on the device. The device just asks the fact server for it's current 'state'. That value it receives determines what the box should do.

The IDE that Arduino provides is nice and easy. However since I'm used to Visual Studio, I found a plugin that allows you to use it with all the intellisense glory. Using Visual Studio certainly makes things better for me :)

 

Therefore I want to reiterate; avoid any complex logic in your IoT device.

 

One last piece to my blog notifier is that I have to actually notify the fact server about a visitor. I make a simple POST request to my fact server that stores the current timestamp. My device reads this value and if there is a difference, blink the light and store the new value locally.

Summary

It sounds like a lot but it was fun and addictive. I'm certain I will continue to make IoT devices that do all sorts of things. Since I have my fact server, I can easily create an IoT device that detects an event (movement, light, proximity, etc) and sends that to the fact server. I can then choose to have another device react to that fact or even integrate with a mobile app\website.

I spent about ~$60 USD for the boards, cases, wiring, etc. It could easily get expensive as I continue to think of new and wonderful IoT ideas (but it's truly fun and educational). The great part about Arduino is that it's relatively cheap and you can re-purpose an old device by re-flashing it with a new sketch and hooking up new lights, sensors and motors.

My final device looks like the image below, enjoy!

 

P.S. You just made this light blink by visiting!