IoT decision-making tree continued: Your device is IP enabled with customisable firmware

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?

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

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


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.

Richard Barry
Richard Barry
Chief Innovation Officer at Polymorph

Want us to solve your business problem too?

Speak to us about your app development project

"*" indicates required fields


Enter your details below and our team will get in touch to provide you with more information about our supplementary solutions

I want to know more about:
This field is for validation purposes and should be left unchanged.

Enter your details below to get the free 5 Technology trends currently disrupting the healthcare sector.

Enter your details below to get How Predictive Maintenance Can Reduce Manufacturing Breakdowns By Up to 75% for free.
  • Hidden

Request a free consultation

Please complete this form & we will be in touch to set up a meeting.

"*" indicates required fields