Business decision-makers are increasingly moving beyond the point where IOT is just a buzzword to them. They are seeing the real benefits of IOT for business productivity, profits, and future growth. Nevertheless, during the planning phase of adopting an IOT strategy into their business operations, decision-makers are still faced with typical questions such as: Where do I start? And which IOT solution will best fit my business needs?
In our first post we unpacked the IOT decision-making tree premised on questions/statements with essentially only a yes/no answer. The focus of this post will only be on branch 1 (highlighted in yellow below).
Here is a quick outline:
Is your device is IP-enabled? Yes
Frequent communication plus regular firmware updates
Infrequent communication using one-way communication
These are multi-faceted questions. For example, when considering the advantages and disadvantages of the type of IOT connectivity to use, it should be based entirely on the use case of the IOT product you are developing, which is, in turn, based on stakeholders’ needs. The next point of consideration is which communication protocols (such as MQTT, HTTPS or COAP) best serve the purpose of your IOT product.
Figure 1: Branch 1 of the IOT decision making tree
Your device is IP-enabled: YES
Custom firmware: No
If you cannot implement and control the firmware, you must ascertain whether or not your firmware is already connected to a backend. Following this route means you have control and ownership of your data. This will be evaluated in more detail in a future article.
Custom firmware: Yes
Having a device with an IP-enabled stack with full control over the firmware gives you substantial flexibility with full control down to chip-level. If you can implement and control the firmware yourself, the next consideration is communication frequency to and from the device such as sending commands and firmware updates.
The next question is, do you require frequent communication with the ability to send firmware updates?
- a) If yes:
This means you typically require reciprocal communication and real-time feedback. This approach runs on a publish/subscribe mechanism which means that nodes in this network can communicate with each other. MQTT that runs on TCP/IP is an example of this. This does not include a central server with clients; communication is directed at the broker that in turn transmits the data to the correct node. This means the frontend can communicate with and send commands to any of the devices. It’s an always-on connection that allows frequent communication with the ability to send commands and firmware updates to the device. An example of this approach is smart irrigation to manage irrigation schedules and decrease water overflows, where commands such as when to switch on/off are sent to an irrigation and real-time data is returned for analysis.
- b) If no:
Your application will only require data to be sent to the cloud at regular intervals without any/minimal return communication (such as running a firmware update) with the end goal being able to store large chunks of data. A practical example is a weather station that only needs to capture data and log it logically on an IOT service; in other words, send the data only one way. For this type of architecture, you will look at HTTP or COAP. COAP is semantically aligned with HTTP to allow one-to-one mapping to and from HTTP. The benefit of this form of architecture is that it is fairly simple to use as there is only one-way communication, the client is in complete control. You can, for example, add an HTTP stack to your device, open firewalls for your HTTP etc.
Conclusion
The ultimate question is, therefore, which option do you want to use. It is a complex, multifaceted question. In our final post unpacking the IOT decision-making tree we evaluate the scenario where you IOT device is IP enabled, but with no customisable or preconfigured firmware and your firmware is either connected to an existing backend or not.
