The world we currently live in is going to change – it is predicted that by 2025 we will be having 7 trillion devices connected to the internet serving about 9 billion people. In this decade we will have to overcome a lot of challenges to increase bandwidth capacity to cater for all these devices (at least in the 3rd world), but for the developers, it will largely increase the complexity of their work.

A common mistake IoT device programmers currently make is to build actual logic in the device itself. The frameworks and hardware cater to this – these devices come with relatively big memory. Granted – if you are dealing with expensive data connections this is the way to go. For instance satellite communication is known to be extremely expensive. From experience I can tell you it is worth the extra coding effort to reduce the data sent – at 5 to 10 dollar cents per byte, this wins back your efforts rather quickly.

If you are not limited in your bandwidth and its price, the following tips will help you build an effective IoT device.

Make sure you can update your software and/or firmware remotely.
Firmware contains bugs like any other code, and although good testing practices will help you find most of them – the best test is in actual production environment. Once a device is installed, it can be very expensive to actually go out and update the device – especially when it is installed in a remote area or installed on a vehicle.

Avoid making your device too smart
The IoT hardware and frameworks have relatively big memory and this allows the developer to make the devices very smart. Technically, it has enough memory and processing power to analyze the data on the device and only send the output you are looking for. The more logic you build in, the more bugs you build in. Ideally have your device just collect the data of its sensors and analyze and process the data in the cloud.

Analyze your data in the cloud
Don’t analyze your data on the device itself. This can keep the hardware cost of the device lower, analytic and processing of the data can be done in the cloud. This scales automatically, and when a bug is found in this part of the process – you can update this in the cloud with just a single click. Updating hundreds or thousands of devices – even when done remotely – is a tedious process because of connectivity issues, and you will have situations in which multiple versions of the software are running at the same time.

Limit your configuration parameters
Configuration parameters are great. You can setup your device to behave differently on command, catering to the needs of every client. Although this all sounds great, when you get to the point of thousands of devices, this is exactly what you don’t want. You want all your devices to behave similarly because it becomes harder to detect any anomalies. Also, when the device is the same, you want the analytics and the processing to be the same. Any exception to the rule is expensive to create, adds additional complexity to the code and is expensive to maintain in the long run.

Avoid versioning problems
When it comes to maintaining thousands of devices remotely – nothing is more frustrating to support than having to maintain different versions of firmware and hardware, which all have their special little exceptions. Make sure to incorporate versioning from day 1, and also make sure that your firmware can be updated remotely before you start (see requirement number 1). Now, because you took the advice and you’re doing the processing and analytics in the cloud – also here keep a single version of this application. Hardware changes, and so does the software, but the less versions you maintain – the easier it gets.

Validate before use
This is a rule that is common throughout all applications, and is not different for device to device communications. When accepting user input, developers are used to validate the data before it is actually accepted. The same should be done before accepting data from the sensors. Some sensors are easily influenced by external factors – for instance GPS can be influenced by reflection (off tall buildings), or by the speed it travels at (doppler effect). GPS jammers are already commercially available products. A compass can be influenced by a magnet, and a moisture sensor can be influenced by heat. Your machine learning algorithms will work a lot better on clean data, and you want to avoid having your clients (or algorithms) make the wrong decisions based on false data.

Operating environments
You just finished your first version of a device that monitors the flow of an oil pipeline. In your little office setup it all works perfectly. Now you need to install it in the middle of the Sahara and burning sun heats up your device to 90 degrees Celcius, and makes it report funny values, or if you are lucky doesn’t report at all. I intentionally call this lucky – as when the device reported false data, the odds you are going out to fix it would be pretty slim. Temperature can be one thing that can affect your devices’ functionality, but also consider other weather conditions such as sand, mud, trembling or altitude.

Power
Your IoT device likely needs a constant power source. What happens to your system when the power goes down? Do you have an internal back-up battery? Do you send a signal to your service when it goes on reserve power? What happens if the device powers up again? Did you save its internal state? Power interruptions can be a source for bugs and undesirable side effects. Make sure your device knows how to deal with it. Keeping your device as dumb as possible and not keeping state is a good strategy to be affected by power interruptions.

Connections
When it comes to managing all your devices remotely – your connection is your lifeline. I am used to working with SIM cards to connect to devices and not all networks support the same protocols. UTP, for instance is not enabled by default on all GSM networks worldwide, and make sure that when you install connections work bidirectional. When devices are installed in manufacturing plants or other make sure they have their own subnet, and that corporate firewalls don’t interfere with their traffic.

Health Check
Build in a health check that makes sure that all the hardware is working properly. When you have the luxury make sure the installer can see it from device using a simple LED that the device is working properly.

Avoid direct device to device communication
Use a Service Assisted Communication model instead. Having devices directly communicate with each other may be very useful – but do not forget that making decisions (processing and analytics) should be done in the cloud. Using a Service Assisted Communication model – you have the benefits of added security, a more reliable connection (no roaming, no firewalls) and you don’t have to run a server (security) on the device itself. On top of that – when the device is out of reach, the cloud model can return the latest known state, which can be more useful than a completely unknown state (arguably that can also be the cause of some bugs).

Did you think about these requirements when implementing your IoT device? What are your thoughts on this? Please share and put any questions in the comments!