$1,567,000,000,000. That is how much the IoT industry will be worth by 2025, according to estimates by Statista.
As with everything IT-related, you’ll only make the big bucks if you hop on the bandwagon early — miss the bus, and you’ll get thrown under its wheels.
Really quickly, the IoT (Internet of Things) refers to all (related) objects that use the internet to communicate with each other. An extended definition would be a network of objects working on an intranet but the data being sent to the internet.
Both of these are part of the IoT. But what does that “thing” stand for? Exactly that; anything. If it uses the internet; it’s part of the IoT.
But if you’re reading this article and not “What is the IoT” by Forbes, you likely know what you’re doing, so I’ve included a summary of the article below.
Things to remember when developing an app for an IoT device:
- Hardware is key. Choose the best 3rd party hardware available to you. Don’t scrimp here.
If you’re developing the app for someone else, make sure that you know the hardware like the back of your hand (size, weight, temperature ranges, capabilities, and limitations, etc).
- Choose your connectivity wisely. Most IoT devices have at least two (maybe even three) connectivity features (Bluetooth, Wifi, NFC, radio) so choose the ones that best meet your needs.
- Encryption, Encryption, Encryption. No one wants to be the next Keepnet Labs. People want the best in class security available — and they’re willing to pay for it.
Remember that you choose your hardware based on connectivity technology, and not vice-versa.
- Data Capturing, Data Retention, and Information Relay. It is assumed that you will naturally be using the cloud, and not a personal server for your application.
The most powerful tool that one can possess today is information — and in the 21st century, there is quite a lot of that on the open market.
Bonus tip: Language can make or break your app. Choose your language based on your app requirements. The most common languages used are C and java, although C++ and python are also popular choices. If you have a lot of expertise, you might want to consider integrating rust into your C++ application too.
Hardware
If you’re thinking about making an app for an IoT device, remember that you are a specialist (and not a generalist). This means that you have a specialized field (IT) and that you occupy a niche in that field (app development).
Like you cannot ask a pilot to manufacture an aircraft from scratch, you cannot ask a software engineer to design the hardware for a device.
Knowing your limitations is key to integrating your app well with the hardware. What you can do is familiarize yourself with all aspects of the hardware so that your app synchronizes well with the device.
Firmware updates to your app should ONLY be OTA. Please, we’re not in the dinosaur age anymore (where one needed to retrieve, disassemble and reprogram their IoT devices) for firmware updates.
Ensure that you’ve programmed your app to install OTA (over-the-air) updates and that the hardware supports it.
Connectivity
Arguably the make-or-break factor for every IoT device, there are numerous connection-based technologies available for use today.
An IoT device may communicate locally with other devices and then upload to the cloud, or each app may communicate directly with the internet. Both use cases require some sort of connectivity medium.
Here, I’ve outlined the pros and cons of some of the more mainstream choices:
Bluetooth. A very popular technology often used for (instantaneous) data transmitting over short distances. The two most popular kinds are Bluetooth Low Energy (BLE) and iBeacon. Bluetooth uses UHF waves.
Pros: Low cost, low maintenance, easy to integrate, has a power-saving mode (can keep devices in sleep mode until connections are established), and is not power-hungry.
Bear in mind that only BLE offers these features — normal Bluetooth is actually pretty power-hungry.
Cons: Low range, Low frequency (ISM 2.400-2.485), slow speed (~800kbps), requires manual connections.
RFID. Think of this like a barcode scanner — without the need for a scanner. It can track and communicate with objects even outside its line of sight using electromagnetic waves (on the principle of electromagnetic induction).
Unlike barcodes, an RFID tag can store a moderate amount of data. For example, a barcode might say “This shipment of mangoes costs $100.” In the same situation, an RFID tag could tell you “This $100 shipment of mangoes came in from India via Mexico last week and should be refrigerated at 12 degrees to avoid spoilage.”
RFID tags are also not limited to the traditional barcode one-at-a-time scanning either, letting you keep track of quite a number of tags simultaneously.
These are mainly used to track the whereabouts of your devices — handy when dealing with a lot of them.
Pros: Automates data collection, reduces human error, affordable when purchased in bulk.
Near Field Connectivity. Shortened to NFC, these use traditional antennas to power a (normally unpowered) tag that uses electromagnetic waves for communication.
Due to this, NFC devices can only communicate when they are powered on, and are within a short range of each other. They often operate in unlicensed bands.
Pros: advanced encryption (that’s why it is often used for payment systems) and seamless integration with other technologies.
Data Capturing, Collation, Filtering, Retention, and Relay
Any IoT device generates a massive amount of data (weather, temperature, how much it was used, battery life, it remembers certain commands that were issued, etc).
Ensure that your app follows these steps to a T:
- You know what data you want from both the user and the app.
- You’ve written your filtration algorithm to decide which data gets to stay, and which is deleted.
- It’s generally a good idea to backup some (not all) of the unwanted data too, just as a contingency plan.
- If the data is valuable, ensure it is stored in at least two separate locations before being backed up to the cloud.
- If the data is mundane (non-personal), it’s okay to save space, compress it, store it in only one location and then move it to the cloud.
- You decide your retention periods based on the amount and type of data that you have collected. For example, user-defined data is usually kept longer than sensor data.
- Decide your relay mechanism — this is the one place where other factors don’t usually play a major role. Do you want all your devices to transmit their data to a hub and then send it to the cloud? Or would you like each device to upload to the cloud autonomously?
Now let’s look at the main types of data that people may want to collect:
User-Defined Data Captures.
If your application gathers data every time a user performs an action (presses a button/makes an order/ activates the microphone etc), then this is called “User-generated data event capturing”.
App-Specific Data Captures
If you decide to capture data based only on your application’s needs, you are performing “application-defined data captures”.
Event-Based Data Captures
Similar to user-defined data capturing, this type of data collation only happens when a certain action is performed. These actions are called “triggers”.
Next, you would be required to
- Decide the timeframe of the data collation; and
- Choose the amount of onboard storage.
The timeframe is solely dependent on your needs – it could range from data every second (like sports wearables like Fitbit) to every day (soil moisture sensors).
Theoretically, your timeframe could extend for any amount of time. It is only limited by practical factors (when you need the data, the lifespan of the hardware, etc).
The storage that you have onboard your device is called the cache. This is dependent upon a variety of factors, chief among them being:
- The frequency of uploads to the cloud (more frequent = smaller cache required).
- The amount of data collected (more date = bigger cache).
- The total number of devices in your network. (you can choose to give each individual device an independent cache or to allot some fixed cache space in the data hub).
Security
All IoT devices have sensors (temperature, humidity, gas, smoke, pressure, IR, proximity, etc), an OS-based interface, and user interaction capabilities. These features are very useful — but they also make the devices vulnerable to attack.
Everyone has heard the stories of webcams being hacked and microphones being turned on without permission.
Make sure that your app does not have any of the following:
- Unsecured channels of communication.
- Misconfigured settings.
- Malicious APIs.
- Poor password management systems.
As far as possible, try to encrypt your app to one of the industry standards like:
- The Data Encryption Standard (DES)
- The Triple Data Encryption Standard (also DES)
- RSA Encryption
- The Twofish Algorithm
- The Advanced Encryption Standard (AES)
The number one thing to remember is that all IoT devices should provide a satisfying user experience — whether they are for consumer use or not. Nobody is going to use a gizmo that needs you to “breeze” through two 1000-page manuals.
