“We need IoT!”, “Tell us more about your IoT offering”, “When can we have IoT?”
These are some of the soundbites that I get asked a lot from our clients.
From my experience, the technology is way ahead of the needs of most of the organisations that are trying to evaluate and implement it. Many organisations I speak to just want to implement a small-scale IoT project – but where do they start?
That’s why I’ve written this blog. To help guide you through some of the key questions you really should be asking yourself as a business before you endeavour on this journey.
For those unfamiliar with the term “IoT” or “Internet of Things”, it is probably one of the most popular buzzwords at the moment. The Internet of Things is essentially about connecting multiple devices together over the internet, and letting them talk to us, applications and each other. For example, your smart TV can be considered an IoT device.
Other common examples include home heating and energy consumption monitors such as Nest and Hive, which allow you to monitor and adjust your home environments via your smart device.
So you think IoT could really help your business, but where do you start?
To answer this question, let’s use a hypothetical example.
Let’s say that you’re a company that needs to monitor noise in hotel rooms in order to save your guests from loud neighbours and improve their stay.
So, embarking on your IoT journey you immediately have some decisions to make.
What am I monitoring and where?
Starting nice and simple, what’s the value you need to record and how is it measured? For simplicity’s sake, we’ll assume that the value is ambient noise and that it’s measured in decibels as a decimal number.
The ‘where’ in this case is easy too, as it’ll be a hotel room.
We can also assume that it’s a non-hazardous environment (you can easily source IP-rated sensors for hazardous ones too).
How frequently do I want to capture my data?
So at first glance, this should be a simple question too. Not so fast. A lot of decisions you make here will impact your solution further down the line. Generally I’ve found that customers are always tempted to go overboard. Do you really need to record data every 15 seconds, or would every 5 minutes suffice?
It’s key to think here of your end goal. As a rule you want the absolute minimum to achieve your business objective. In this scenario, whether we know in 15 seconds, or after 5 minutes is generally irrelevant. In more mission-critical scenarios, these timeframes could be unacceptable, but they’re just fine for our hotel example.
The reason why the method and frequency of data collection is important is all down to power. How much juice is your IoT device going to need to run and how is it going to be supplied? Do you have the ability to provide mains power to your IoT device, or does it need batteries? Then you’re into the calculation of total cost of ownership (TCO) since batteries need replacing. That also means people to replace them too!
The easiest rule of thumb here is to think that the more quickly you capture and report data from a sensor, the more complex the calculations you’ll need to put in place on the device. The more complex the calculations, the greater the amount of power you’ll need to run it. This subsequently means that your batteries will deplete much faster.
Again, think here in terms of the minimum output you need in order to achieve your business objective and then scale up from there.
How am I going to communicate this data?
This is where the real fun begins! You’ve got your data from your IoT device at a frequency that is acceptable – but how are you going to access it? Looking at traditional communication methods, you could select from Ethernet, WiFi and even 3G/4G data sims (yes – just like the one in your smartphone). Similar to the power consideration for your sensor, some methods of data communication require a lot more power than others.
On top of those listed above, there are several networks and protocols specifically designed to allow for low-bandwidth and low-power traffic that you may be less familiar with. Spend some time taking a look at LoRa, Sigfox, and NB-IoT (these are far too broad a topic to be covered here in detail). Each of these can get your data from A to B in a different fashion with different caveats.
When choosing a communication methodology, I would recommend you consider a few factors before you commit to an infrastructure.
First up, in terms of the size of your data, will you be sending large or small packets of data? In this example our noise reading is fairly small, so we don’t need high bandwidth.
Next up, how far is your data going to travel? Is it from the sensor directly to your application or does it go through a hub? If it goes through a hub, what is the distance between the sensors and the hub? How is the hub going to communicate with your application?
For our hotel example, we’re going to install a hub that all of our IoT devices communicate with via the LoRa protocol, which then connects to our application. This means that our devices can be fairly low power and focus on sending data to the hub only, meaning that any calculations can be completed on a higher-power hub device with mains power elsewhere.
Where and how am I going to store it?
Great – so our hotel has had its noise sensors installed. We now know the noise levels in our hotel rooms as the hub can send this to us on a regular basis. But where should the hub be sending this data to and how should it be stored?
There are numerous services available from Amazon, Google, and Microsoft specifically designed for data ‘ingestion’ from IoT devices. In simple terms, they expect massive amounts of fairly uncomplicated, low-bandwidth data. You should be able to find information on these online pretty easily.
If I could make one recommendation when deciding your data processing and storage strategy it would be paths. A path is the route our data needs to take once it hits your application.
For our hotel example, we want to know relatively quickly (every 5 minutes or so) if a room is really noisy. In this instance we could automate sending a message to the TV system in the room to turn it off, or ask our porter to knock on their door. We also want to know average noise levels per room and potentially some information that can enrich our booking process. For example using the data to evaluate the average noise levels to be expected from a family vs. an individual. This could enable the booking of ‘quiet’ rooms – leading to improved customer satisfaction.
In IoT terms, the time to analyse, interpret and provide feedback is directly correlated to the path of data transmission. Paths can be ‘hot’ or ‘cold’ depending on the speed and frequency the data within them is being accessed. A ‘hot’ path describes lots of data being accessed quickly, and a ‘cold’ path describes data that is generally stored for a longer period of time and accessed less frequently. In the above example we have a ‘hot’ path (the 5 minute notifications) and a ‘cold’ path (the summary management information).
Think about your paths when receiving your data, as certain tools will be better suited to the job!
What analysis do I want from it?
On our ‘hot’ path we want to know if the noise breaks a specific decibel value, let’s say 80db. On our ‘cold’ path we want to calculate ongoing average noise levels per room, hotel and time of day.
For full story, please click here.