IoT Stack - 10 components every IoT project should have

One IoT project barely matches another, there are always differences. Extra requirements, new functions, special circumstances to be considered. Never then less all IoT projects are based on the same building blocks.

Each block has its own capabilities and functions by itself. The Magic, however, is in stacking the blocks together in a way that leads to the perfect outcome.

IoT Stack (Bottom-Up)

Let's start building the IoT Stack from the bottom-up and work toward the top.


The Thing

The "Thing" is a physical "Object", a "Device" that should be connected to the Internet. This could be any physical object one can think of.

Examples: Chair, Car, Door, Weather station, Water meter, Keys, Smoke detector, Wall, Room, ...


The chosen object requires one or multiple sensors to measure various attributes. The attributes could be of the object itself or the surroundings where the object is placed (or both).

For example, one sensor could measure the inner temperature of the object. Another sensor, placed on the outside of the same object, could measure the environmental temperature. Both sensors will lead provide insight into three specific states of the same object:

  1. Object Temperature
  2. Surrounding Temperature
  3. Object Temperature at a specific surrounding Temperature

Other sensors might be:

  • Humidity
  • Light
  • Counter
  • Weight
  • Motion
  • Vibration
  • Location
  • ...

Going forward the term asset will refer to objects or devices with sensors (combined).


Data is the reason why IoT exist!

The generated data is based on the sensors chosen for this job. It can be recorded in a continuous flow e.g. every minute or the recording could be responsive with planned gaps and be triggered by events e.g.: Movement.

Both approaches have their pros and cons.

For Example, an hourly temperature measurement (asset is still OK - no changes) is sufficient when monitoring the overall state. This has the benefit of extended battery life and therefore longer asset usage.

On the other side, the hourly interval can be increased to a 5 min. interval once a temperature event is triggered e.g.: Temperature moves out of the "optimal" range. This will allow accurate recordings of specific edge cases and ensure crucial for operations.


The IoT protocol has a huge impact on the total data consumption and therefore also on the connectivity costs. It is strongly advised to pick a protocol that benefits the IoT project's diverse usage patterns.

Different IoT protocols have different benefits. Yet all of them transmit data and some of them provide predefined functionalities.

While comparing various protocols the following two attributes should be reviewed thoroughly:

  1. ... the overhead of a protocol - how much additional data will be transmitted in addition to the actual payload (sensor data).
  2. ... the automation capability of the protocol - how to manage millions of connected assets

Two very common protocols in the IoT world are LwM2M and MQTT.

  • The idea behind LwM2M is automation, monitoring and management (FOTA/SOTA). This requires a strict parameter definition.
  • MQTT on the other side has a very loose parameter definition but requires much more effort in asset automation and management.


All assets need to connect over a network to a server and become a fleet of connected assets. This is achievable through the usage of cellular technology (4G, 5G, NB-IoT, LTE-M) or going to the next step and selecting an LPWAN solution (LoRA, Sigfox, MIOTY ). Both approaches have their specifications and benefits and limitations and have a huge impact on the total asset. Things like reachability, battery lifetime, communications interval, responsiveness, data throughput, infrastructure, TCO, ... and many more.

The one most common concern raised in IoT projects is the topic of public or private networks. The benefit of a public network is that an asset "just" needs to connect to it. The network is managed by someone else. A key component of the IoT project is outsourced for example to a telco and relies on the telcos responsiveness in managing problems.

A private network on the other side requires additional network management resources. This can have a huge cost impact (reduction or increase) and in most cases increased at the same time security aspect of the total solution.

As with all the other parts of "The Stack" there is no solution that fits all.

The Cloud / The Server

The Server (also known as the mysterious "Cloud") is the central point where all assets connect to.

A Server can be operated in two major setups:

  • On-premises The server Hardware is at a private location
  • Private or Public Cloud The server is hosted inside the Google, Amazon or Microsoft ecosystem.

Security and privacy is the motivation for choosing an "on-premises" solution. While projects that require extended access and connectivity (also cheaper) tend more towards the "Cloud" solution.

The second most important aspect of any server is the suite of IoT Applications running on it. These applications are at the core and can be seen as a glue for the whole IoT solution. They must understand the transmission protocol (some projects require more than one) and handle at the same time the transmitted asset/sensor data.


Automation is where the IoT user stops working hard and start working smart.

A fleet of hundreds of thousands of connected assets must be looked after and ...

  • Kept operational with the latest security updates
  • Exchange data between individual assets as well as groups of connected assets
  • Trigger events and reacts to internal as well as external changes

Instead, a person managing each and every single asset, the roll is swapped and an automated monitoring system takes over.

It informs the operator what needs to be done and which assets require a bit more care.

Automation and Monitoring depends on the capabilities of an asset, the chosen protocol as well as the server software used for this task.

As a result, using industry-standard protocols and assets that can be automated is highly encouraged.

External interface

External interface enriches IoT solutions with additional information from external sources.

For example, the usage of a CRM-Database provides the capability to connect a specific asset to customer data. A connection that enables a completely new set of functions and automation. For example scheduling inspections around the availability of a customer. Or defining the asset location based on the customer address.


Another way to add more value to IoT assets is by analyzing the measured data in "big style".

Once a fleet of assets grows in numbers the point of interest grows as well. Form the state of one specific device to the state of the whole fleet of connected assets.

It’s still interesting what happens with one individual asset (e.g.: one parking lot = occupied or not). However, the overall condition of the "parking floor" or even "parking house" is important as well (e.g.: total occupancy, spots left, usage patterns, ...).

Analytics use individual measurements and compare them against other sets of data over a defined period. This leads to insights like:

  • Occupancy statistics - time of the day, holiday, weekends, ...
  • Usage patterns compared to weather (external weather API) = For example, higher demand during hail storms
  • Duration of stay compared to special promotions or events
  • ...

Analytics like these enable smart business decisions. When to lower or raise parking fees, extend the parking capabilities or even rent out space or convert to long-term parking over the holidays.


IoT Applications promote a user to a Manager who oversees the whole fleet of connected assets. It can be vertical-specific (e.g.: Smart-Water-Meters) or generic (e.g.: Industrial Monitoring), and be integrated with a customer service system.

It can give project-specific features, like monitoring water usage, as well as more generic features, such as over-the-air software and firmware updates (SOTA/FOTA).

An advanced IoT application will provide insight into historical measurements and data from continuous monitoring. As well as the ability to group assets and compare/monitor group-specific behaviour.

*Special Application

Based on the latest studies, a person that is aware of missing knowledge reacts in the same way as experiencing a high level of Stress. On the other side closing the gap and providing this knowledge is experienced as a huge relief.

This is true for the operator of an IoT project as well as the customer. An operator finds answers to his questions in the Dashboard of an IoT solution or by reading through reports. Customers on the other side are often left out of the loop.

Most of the customers won't be able to articulate the missing information but almost all will be happily gain insight and peace of mind.

Most people are not interested in the technical details but in the general state of an asset. For example, a smoke detector in the kitchen:

  • Is it fully operational?
  • Does it run a self-diagnostic? What is the result?
  • Will I be notified should the sensor be triggered?
  • How do I know it working?
  • Is everything OK while I'm at work or travelling?
  • ...

Sharing with customers a set of information about their assets will give them insight make them feel in control. This openness benefits not only the customers. It leads often to reduced support tickets in the customer-care centre since all the information is just a click away.


As mentioned at the very beginning there is no secrete sauce that works for every IoT project.

A decision in one area of the stack has impacts on other areas and requires a reevaluation of the project.

It is up to the whole project team to define how success should look like and work together on how it can be achieved.