IoT, I want it in my business but where do I start?

I want IoT in my business! But where do I start? 

“We need IoT!”, “Tell us more about your IoT offering”, “When can we have IoT?” 

These are some of the soundbites that I hear 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? 

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 hotel that needs to monitor noise in your rooms in order to save your guests from noisy 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 IoT 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 want to go overboard. Do you really need to record data every 15 seconds, or would every 5 minutes suffice?  

What’s the end goal?

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 collecting data  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.  Imagine making 100 calls from your mobile phone to someone when in essence, a single call would do – how quickly would your phone battery run out? 

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 IoT 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. 

Low power communication

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. 

Size

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.  

Distance

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, for example, the reception desk. 

Where and how am I going to store it? 

Great – so our hotel now has noise sensors. 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.  

Hot and cold paths

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 – improving 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 of accessing the data within them. A ‘hot’ path describes accessing lots of data 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. 

Given that we’ve used Microsoft Azure for mpro5 for a long time, I would be looking at two specific tools to analyse my ‘hot’ and ‘cold’ paths. Azure Event Hub would be used to analyse our ‘hot’ path, providing near real-time notifications when the noise breached certain levels. Azure Blob Storage and Azure Stream Analytics would then be used for storing our raw data, averages and calculating them respectively on our ‘cold’ path. 

Using the above tools, we should be able to achieve the business goals we originally set out to accomplish, whilst also ensuring that we’re able to scale quickly and easily as our hotel gets bigger, or as we take on more hotels. 

Hang on, what about security? 

Security really should be thought about as early in the process as possible – after all, you’re opening up potentially thousands of new clients for your application. How are you going to ensure that your clients are not compromised? What are you going to do if they are compromised? 

There are many ways to tackle all of the above, ranging from your hardware connectivity (do you need that USB port on the hub?) to software design. 

Spend some time contemplating the potential risks in the worst case scenario and work back from there. What is the catastrophe situation and how can it be avoided or mitigated? 

This is all completely overwhelming, is there an alternative? 

Yes indeed, for an IoT solution you need knowledge that spans across hardware, software and communications. It is very easy to make the wrong decision and equally as easy to be blinded by the sheer amount of decisions to be made. 

mpro5

Our plan here at mpro5 is for you to be able to come directly to us with your IoT business need and for the mpro5 platform to be configurable enough to solve your IoT problems. We’ll be looking to take care of all the hardware, software and communications on a monthly subscription, as well as allowing you to use all the functionality of mpro5 driven by IoT. 

For our hotel, this could mean that the mpro5 solution would notify us of a ‘noisy neighbour’ and schedule a job down to the mpro5 app on our porter’s smartphone with all of the required workflow attached – all automated without user intervention. You could even use SMS or call that guest directly too – it’s very powerful stuff! 

Learn more

If you’d like to learn more about the mpro5 mobile enterprise platform or talk to one of our specialists about how IoT could be implemented into your business, book a short, online meeting with our team here.

Luke Jefffey

CEO, mpro5