In a previous post, we have discussed and compared the advantages and disadvantages of the type of IOT connectivity to use and concluded that it is based entirely on the use case of the IOT product you are developing, which is, in turn, based on what your user needs. In addition, you will also have to decide what type of protocol to use. To make this decision you will have to consider IOT-specific protocols such as MQTT, HTTPS, and COAP. To guide you through this complex process we have designed an IOT decision-making tree premised on questions/statements with essentially only a yes/no answer, which we explain in more detail below.
IS YOUR DEVICE IP ENABLED?
When commencing the development of your IOT product, the overarching question is whether your device is or will be IP enabled. It should be noted that the predominant networking stack is an IP stack which includes an application library to open or close connections to remote devices and can send and receive data between such remote devices. A typical use case would entail whether your device needs to be connected and enabled to send or receive data via the internet? This requires a connection via an IP enabled device, either with its own IP protocol or via a secondary IP enabled communication device.
1. Your device is IP enabled
Your device is IP enabled: YES – In this scenario, your sub-question is: Can you implement and control or customise the firmware yourself? In other words, you can implement and control the firmware yourself – it is worth highlighting that a device with an IP-enabled stack and full control over the firmware is more flexible and gives you more control over what you are developing down to chip-level.
Custom firmware: YES – The next consideration is the communication frequency, that is, whether you require frequent communication to and from the device such as sending commands and firmware updates.
Frequent Communication: YES – the device pushes data to a backend that the hardware manufacturer controls. You would, therefore, have to pull the data from the hardware manufacturer’s backend using an API they provide. The same result can be achieved through a provided MQTT broker.
Your device is IP enabled: NO – If no, it means your device is not connected to a backend and the device will typically publish data to a message broker online that you can integrate with to receive the data. In this case, the protocol that is used is usually MQTT. The device can, however, be set up to push data to an HTTP endpoint that you can configure on the device. The hardware manufacturer, therefore, dictates which protocol to use and the onus is on you to pick an IoT platform that supports the protocol your device already implements.
Custom firmware: NO – You cannot implement and control the firmware yourself. The first question is are you already connected to the backend?
Connected to the backend: YES – If you are connected to the backend, which is provided by the hardware manufacturer, you are able to pull data into your own data pipeline using MQTT broker or HTTP callbacks to API.
Connected to the backend: NO – If you are not connected to the backend, you have to configure a custom backend using MQTT or HTTP as supported by the device.
2. No – your device is not IP enabled
Your device is IP enabled: NO – If your device is not IP-enabled your options include LoRAWAN, Sigfox and NBIOT. With these protocols, your focus is on connecting things over fairly long distances and you are able to pull data into your own data pipeline via a custom bridge between your backend to a connectivity gateway.
The ultimate answer is both complex and multifaceted. To start on your journey of what connectivity and protocol you require for your IOT product contact Polymorph today.
