The ages-old dream of home automation has never been nearer to reality. Creating an Internet of Things device or even a building-wide collection of networked embedded devices is “easy” thanks to cheap building blocks like the ESP8266 WiFi-enabled microcontroller. Yet for any sizable project, it really helps to have a plan before getting started. But even more importantly, if your plan is subject to change as you work along, it is important to plan for flexibility. Practically, this is going to mean expansion headers and over-the-air (OTA) firmware upgrades are a must.
I’d like to illustrate this using a project I got involved in a few years ago, called BMaC, which grew in complexity and scope practically every month. This had us scrambling to keep up with the changes, while teaching us valuable lessons about how to save time and money by having an adaptable system architecture.
Last year, we saw quite a bit of media attention paid to blockchain startups. They raised money from the public, then most of them vanished without a trace (or product). Ethics and legality of their fundraising model aside, a few of the ideas they presented might be worth revisiting one day.
One idea in particular that I’ve struggled with is the synthesis of IoT and blockchain technology. Usually when presented with a product or technology, I can comprehend how and/or why someone would use it – in this case I understand neither, and it’s been nagging at me from some quiet but irrepressible corner of my mind.
The typical IoT networks I’ve seen collect data using cheap and low-power devices, and transmit it to a central service without more effort spent on security than needed (and sometimes much less). On the other hand, blockchains tend to be an expensive way to store data, require a fair amount of local storage and processing power to fully interact with them, and generally involve the careful use of public-private key encryption.
I can see some edge cases where it would be useful, for example securely setting the state of some large network of state machines – sort of like a more complex version of this system that controls a single LED via Ethereum smart contract.
What I believe isn’t important though, perhaps I just lack imagination – so lets build it anyway.
It’s no secret that I rather enjoy connecting things to the Internet for fun and profit. One of the tricks I’ve learned along the way is to spin up simple APIs that can be used when prototyping a project. It’s easy to do, and simple to understand so I’m happy to share what has worked for me, using Web2Py as the example (with guest appearances from ESP8266 and NodeMCU).
Barring the times I’m just being silly, there are two reasons I might do this. Most commonly I’ll need to collect data from a device, typically to be stored for later analysis but occasionally to trigger some action on a server in the cloud. Less commonly, I’ll need a device to change its behavior based on instructions received via the Internet.
Etherscan is an example of an API that saves me a lot of work, letting me pull data from Ethereum using a variety of devices.
In the former case, my first option has always been to use IoT frameworks like Thingsboard or Ubidots to receive and display data. They have the advantage of being easy to use, and have rich features. They can even react to data and send instruction back to devices. In the latter case, I usually find myself using an application programming interface (API) – some service open on the Internet that my device can easily request data from, for example the weather, blockchain transactions, or new email notifications.
Occasionally, I end up with a type of data that requires processing or is not well structured for storage on these services, or else I need a device to request data that is private or that no one is presently offering. Most commonly, I need to change some parameter in a few connected devices without the trouble of finding them, opening all the cases, and reprogramming them all.
At these times it’s useful to be able to build simple, short-lived services that fill in these gaps during prototyping. Far from being a secure or consumer-ready product, we just need something we can try out to see if an idea is worth developing further. There are many valid ways to do this, but my first choice is Web2Py, a relatively easy to use open-source framework for developing web applications in Python. It supports both Python 2.7 and 3.0, although we’ll be using Python 3 today.
What exactly qualifies as comfort food is very much in the palate of the comfortee. Grilled cheese may not work for everyone under every circumstance, but we’ll risk a bet that the gooey delicacy is pretty close to universal, especially when you’re under the weather.
But if you’re too sick to grill up your own and don’t have anyone to do it for you, this grilled cheese sandwich-making robot might be the perfect kitchen accessory. Dubbed “The Cheeseborg” and built as a semester project by [Taylor Tabb], [Mitchell Riek], and [Evan Hill] at Carnegie-Mellon University, the bot takes a few shortcuts that might rankle the grilled cheese purist. Chief among these is the use of a sandwich press rather than a plain griddle. We understand that this greatly simplifies the flipping problem, but to us the flipping, especially the final high arcing double backflip onto the sandwich plate, is all part of the experience. Yes, a fair number of sandwiches end up going to the dog that way, but that’s beside the point.
As realized, Cheeseborg feeds bread and cheese from stacks using a vacuum arm, sprays the grill with butter, and uses a motorized arm to push the uncooked sandwich into the press. At the peak of grilled perfection, the press opens and ejects the sandwich to a waiting plate. As an added bonus, the whole thing is Google Assistant enabled so you can beseech Cheeseborg to fix you a sandwich from your sick bed. See it in action below.
So you just got something like an Arduino or Raspberry Pi kit with a few sensors. Setting up temperature or motion sensors is easy enough. But what are you going to do with all that data? It’s going to need storage, analysis, and summarization before it’s actually useful to anyone. You need a dashboard!
But even before displaying the data, you’re going to need to store it somewhere, and that means a database. You could just send all of your data off into the cloud and hope that the company that provides you the service has a good business model behind it, but frankly the track records of even the companies with the deepest pockets and best intentions don’t look so good. And you won’t learn anything useful by taking the easiest way out anyway.
Instead, let’s take the second-easiest way out. Here’s a short tutorial to get you up and running with a database backend on a Raspberry Pi and a slick dashboard on your laptop or cellphone. We’ll be using scripts and Docker to automate as many things as possible. Even so, along the way you’ll learn a little bit about Python and Docker, but more importantly you’ll have a system of your own for expansion, customization, or simply experimenting with at home. After all, if the “cloud” won’t let you play around with their database, how much fun can it be, really?
The build relies on a Particle Photon to do the heavy lifting of connecting the door to the Internet. Particle offer a cloud service that makes setting up such a project easy for the first timer, and [Brad] was able to get things working quickly. A relay is used to activate the garage door remote button, as it was desired to leave the main control board of the garage door opener untouched. Reed switches are used to sense the position of the door, and [Brad] coded a state machine to ensure the door’s current state is always known.
It’s a simple project, but [Brad]’s use of state machine techniques and position sensing mean it’s less likely he’ll get home to find his garage open and his possessions missing. If you’re new to programming simple physical devices, you could take a page out of his logbook. Of course we’ve seen similar builds before, like this one from parts from the scrapbin.
Most people can tell you the various uses of the umbrella — it keeps the rain off, pokes sleeping train passengers awake, and can be used as an improvised defensive weapon when tension in the hot dog line reaches boiling point. A true Englishman would never deign to employ their brolly so imprudently, of course, but they might just give it an upgrade by packing in a full weather station.
Please do not message us to complain about the redundancy of a rain sensor on an umbrella.
The build uses the Particle Photon as the brains of the operation, interfacing it with several sensors. There’s a DHT11 to handle temperature and humidity measurement, an Adafruit barometric pressure sensor, along with a custom-built anemometer using a brushed motor with 3D printed wind cups. Finally, a breadboard is turned into a rain detector, based on the same principles as those used in automotive applications.
The Particle Photon uses WiFi to tether to a smartphone, deliver the collected data to the cloud via Adafruit IO. This enables the data to be collated and processed further on a PC. Yes, it’s 2018, and they have the internet on umbrellas now.
