Having discussed the project motivation, use case(s) etc, it is time to move on to the beginning of the technical work. This stage of project definition will encompass the main technical decisions that have to be made before actual implementation work can be done. These decisions are mostly high-level, even when pertaining to the specific hardware to be used. There wont be any discussion of actual code or nitty gritty details about protocols because at this stage, even if I have ideas about what I might have to do, I want to dig into the details at a time in which I can put them into action. The overall structure is going to be as follows:
Communication Architecture, (high level)
Protocols (a little lower level)
Server-software (lower level still)
Embedded hardware (lowest level)
The first part of this project from a development/technological position is to make some architectural choices. There are a number of different IoT architectures available for this kind of project, and each has a cascading effect on the rest of the system and requirements, so this is the kind of choice that needs to be made up front and stuck to. There are two main “categories” of architecture in my mind (citation definitely needed), the first I call the “sleepy system”, and the second being normally called “Real time” but I think that is a misnomer and confused with actual real time systems (which is a more somber, serious topic that deserves respect). Instead of real time, I will call this second category “on demand”.
A sleepy system is one that is designed for low power operations that doesn’t place a lot of emphasis on current information. Knowing some measurement or observation that is a couple hours old is not a problem, and in many cases you might be more interested in the last few days or weeks worth of data more than what is happening right now. This well classifies the compost monitor, but day old graphs aren’t as sexy as minute by minute updates you know? Bi-directional communication is still possible in a sleepy system, but only when the embedded system initiates it.
On Demand Systems
There are some very cool developments in IoT techniques that are based on more asynchronous, bi-directional styles. The overall emphasis of the on demand architectural style is that data is requested from the device it is desired. This means the device may be polled from a server periodically to keep a dynamic web-page up to date, or the device may actually host the web page that displays the data. This type of system is open to bi-directional communication, the system could still operate as a sleepy system but then it wouldn’t be accessible if it were asleep, and it would cease to be available on demand. This is an attractive method, it would be cool to have the device posting data periodically but also being pollable such that an immediate value could be gathered. This would require some tricks to find a way to wake the device up on demand so that it could service these asynchronous requests.
To make this post shorter, check out the summary of IoT communication protocol architectures here. That post covers several of the specific implementations and protocols that could be used to implement a system like this. The details were muddling up the perfection that is this post so I moved it all out.
The overall category I’ve chosen is the “sleepy system” due to the lower complexity and cheaper components and the lack of necessity in accessing the system in real time. In the future I will attempt a more bi-directional but that can be V2.
In terms of protocols with which to implement the system, a REST interface is by far the easiest to implement which makes it an attractive option. I find the MQTT protocol very interesting as well and it would make a good addition as an implementation of a real-world IoT protocol. CoAP is also an interesting protocol that seems to be growing in popularity. As a result, I have decided to attempt to implement each protocol, starting with HTTP/REST since it is the easiest to get up and running, implementing MQTT next since it seems potentially easier than CoAP, and finally trying to implement CoAP.
This will require some forethought on the embedded system side by the use of a Strategy or Template pattern (depending on whether I wish to be able to switch between the methods at runtime or compile time. For the server components, it will be more of a matter of finding the appropriate server software to install, as there seems to be plenty of open source projects for both MQTT and CoAP. I’ll discuss how I am going to organize the implementation of multiple commnication protocols/architectures in the next post.
The choice of server software to be used comes mostly from availability and what I want to learn as a result of the project. At work we use a .NET WebAPI based REST interface so to learn a popular upcoming REST api technique, I am going to use NodeJS based on the popular express framework. To store the data I am going to use MongoDB because it allows me to be less strictly structured up front and allows for more flexibility in the long run.
My background in embedded systems involves mainly AVR microcontrollers (or, lower level VHDL digital prototyping). To choose a more modern system I had to chose between Arduino, Raspberry PI, or a TI development system (three of the more popular embedded technologies for hobbyists). I choose to use Arudino due to the fact that a) it is possible to access the lower-level architecture (which is an AVR microcontroller, which I have some experience with) and b) the way the AVR architecture is designed, it is often possible to minimize an arduino system to a smaller AVR microcontroller after the prototyping stage.