Today’s post will be on how I see the smoothest way to do prototyping & hobby projects in regards to IoT. What is my main principle in deciding this? I only want to spend time on “business logic” and not waste time on the nuts & bolts of the engine.
So what’s the architecture we’ll be using for this?
- Device : Particle Photon + Grove Expansion Board + Grove Sensors (Temperature & Air Quality )
- Particle Platform : Used for the development
- Azure IoT Hub : Basically a 1:1 link with Particle, which will take over once we go to a production grade setup.
- Azure Stream Analytics : Streaming the ingest data from our IoT Hub towards our various landing zones.
- Azure CosmosDB : For storing the data we’ll use in our reports.
- Azure Storage Account : Cheap storage where we keep all the data we collected, and which we could use for our analytics.
- PowerBI : The make nice reports of the data we collected. 😉
Now let’s delve into these parts one by one!
IoT Device : a definition
One of the first things I want to say is that IoT devices typically revolve around three aspects ;
- limited power consumption
- limited compute power
- really small form factor
Where a Raspberry PI (RPi) will allow you to simulate the communication flow. Be aware that using an arduino alike chipset will force you into situations that you would not have seen with a RPi. For instance, an Arduino Mega is only a fraction of an RPi. Where you typically want a stable 2 A(mpere) feed for your RPi, you can see that the Mega is thinking in mA.
IoT Device : The setup used for my last hobby project
For my last hobby project I wanted to measure Temperature & Air Quality in a remote location. So I built the following little prototype ;
What do you see here?
- Grove System Expansion Board (info) : The black thingie in the middle
- Particle Photon (info) : The thingie that has the power cable attached to it, residing on top of the expansion board
- Grove Temperature Sensor (info) : Down below on the left… Actually, in the picture it was still a sound sensor (info). Though that (oddly enough, different story) got switched by a temperature sensor later on.
- Grove Air Quality Sensor (info) : Up to the left.
Why did I choose these? Basically because they are very fair in terms of price! Though be aware that I would only advise you to use them for your prototyping! Once you go for a production deployment, you’ll probably go for a custom designed PCB board and want to rely on more industry grade sensors. The grove ones are very good “to play around with”. Though I do not seem them as components that I would want on an IoT device where it’s very hard to perform maintenance on.
There are basically three reasons why I love using particle for my prototyping / hobby projects ;
- Device Management is a breeze. The entire life cycle of the device is well thought of and it’s very intuitive. Though I have my considerations when we would consider scale… Though that’s not an issue when prototyping. 😉
- Development Life Cycle just works. You can work from their IDE and easily flash your device. When you include their “application.h”, then it’s the equivalent of the “Arduino.h” when you would go for a typical arduino setup. Their compatibility is pretty decent, so you can leverage the libraries from the Arduino community too.
- Native Azure Integration. And when it’s all done, I can just hook it up to my Azure IoT hub… How sweet is that?!?
So in essence, I find it a great platform to work on the “front end” part during the prototyping. The back-end part (the next chapters) is something I see on Azure, and which I see as easily reusable when going towards a production grade deployment. So you can make this work for you as a kind of “growth model”!
Azure IoT Hub
During the prototyping it’s mainly used as an intermediate queue. Though once you go “production grade”, then you can start leveraging the great capabilities of Azure IoT Hub.
Azure Stream Analytics & Outputs (Azure Storage / CosmosDB)
We’ll leverage our streaming job to send the events to three different locations ;
- Azure Storage : This will serve as our archive. We can use it later on for replaying scenario’s or for doing analytical queries on the entire archive.
- Azure CosmosDB – Long Term Collection : This contains the information we want to report on, but where the reports are more “ad hoc”.
- Azure CosmosDB – Short Term collection : This contains the information we want to have in our dashboards. For this I setup a time-to-live on cosmosdb that purges all data older than one day.
Now if we would take a look at the job… For now it’s still very basic ;
In a next phase, additional queries will be added to have a kind of hot path where we do alerting.
Last but not least… The reporting on the sensor data! For this we can leverage PowerBI (PBI) to easily create reports. CosmosDB has a native connector in PBI, so that we can retrieve the data and “play with it”.
Just tweak the data a bit, so that model suits your needs ;
And create the reports/dashboards you want!
I hope this post inspired you for your IoT Prototyping! In my mind, it’s a very budget friendly way to explore if an IoT project makes sense for your business without going into big investments. You can immediately see value and have your first MVP out there. Next to that, you won’t lose any of the investments you made and can build further on top of this. As mentioned, I see this setup as the first step for a possible growth model where you can expand on top of.