Stop Integrating IoT Devices from Scratch

A real IoT project rarely depends on a single manufacturer or a single technology. It may combine LoRaWAN sensors, industrial controllers, tracking devices, energy meters, gateways or environmental monitoring equipment, each with its own protocols, payloads, data structures and configuration mechanisms. And the more devices we add, the more integration work is required.

Integrating a device is not simply a matter of getting it to send data. Its messages need to be interpreted, variables identified, conversions applied, uplinks and downlinks managed, and all that information transformed into data that can actually be used by the platform and the applications built on top of it. That work is repeated from project to project, and very often by someone solving a problem that has already been solved before.

That is exactly why Thinger.io Marketplace exists: an integration ecosystem designed to connect devices, communication technologies and IoT tools with Thinger.io without having to start every implementation from scratch.

Add to that the diversity of communication technologies, MQTT, HTTP, LoRaWAN, cellular networks or industrial protocols, and all of them may coexist within the same infrastructure. This means that physically connecting a device and understanding the information it generates are two different problems, and the second is where the hours go. When each project implements that logic independently, a significant part of the work ends up being repeated: payload decoding, variable normalization, device configuration, message handling and adaptation across different connectivity layers.

In a proof of concept with five or ten sensors, manually writing a decoder may seem like a minor task. The problem appears when the deployment grows. New devices usually mean new manufacturers, new payload formats, new firmware versions and new configuration requirements. If all that logic has been custom-built for each project, the amount of proprietary code that must be maintained, documented and reviewed every time a manufacturer releases an update grows as well.

Thinger.io Marketplace is a repository of integrations and plugins that extends the platform through reusable components. Its goal is simple to state and highly valuable in practice: to prevent integration problems that have already been solved from having to be developed again in every new project.

For hardware, an integration contains the knowledge required to work with a specific device: how to interpret its messages, which variables it exposes, how to convert its data and how to manage communication with it. In this way, the work done once to integrate a model can later be reused across other projects, customers and deployments.

Today, Marketplace includes devices from manufacturers and ecosystems such as Siemens, WIKA, Milesight, Teltonika, Dragino, Arduino, Bosch, Abeeway, URADMonitor, Kamstrup, IMBuildings and Tinovi, among many others.

But the value of Marketplace is not only the number of available devices; it is also the range of applications they cover. The catalogue reflects the heterogeneity of the IoT world, and it becomes clearer when grouped by the type of problem each device solves.

Industry, Smart Cities, agriculture, smart buildings, energy, environmental monitoring and asset management are completely different problems. The integration layer is what allows all that hardware to become part of the same IoT ecosystem.

The practical result is that the starting point of a project is no longer a blank code editor, but a device that already sends meaningful data. From there, the work that truly differentiates the solution can begin: business logic, alarms, visualization and integration with the rest of the customer's systems.

An example illustrates this better than any explanation. A LoRaWAN temperature and humidity sensor does not send readable JSON: it sends a few bytes optimized to consume as little energy as possible over the air, something like 0167010A02685A. Inside that message are a channel identifier, a data type, an integer value and a scale factor that only make sense if the manufacturer's specification is known.

What that one message costs, with and without the integration in place:

The difference is not one afternoon of work. It is one afternoon multiplied by every device model, every project and every time the integration has to be touched again.

Not every device communicates directly with the application. In LoRaWAN architectures, for example, the message generated by a sensor normally passes through a gateway and then a LoRaWAN Network Server before reaching the platform where it will be processed.

That is why Thinger.io Marketplace is not limited to device support: it also includes plugins and integrations for the technologies and infrastructure used to transport and manage that data, including solutions such as LORIOT, The Things Stack and ChirpStack.

This separation keeps two responsibilities clearly distinct:

From there, Thinger.io can use that information throughout the rest of the platform: storing it, visualizing it, processing it, generating alarms, automating actions or integrating it with other applications and services.

Separating connectivity, device interpretation and application logic makes it possible to build more modular IoT architectures, where each component can evolve without forcing a redesign of the entire system.

For a technical team deciding how to approach an IoT product, the underlying question is rarely whether they could build the infrastructure themselves. Usually, they could. The real question is how much of their time they want to spend building something that does not differentiate their product.

None of those pieces is impossible. Taken together, however, they can mean months of development before the team even starts solving the business problem that justifies the project, followed by an ongoing maintenance burden. Relying on a platform with an existing integration layer does not eliminate engineering work; it moves that work to where it creates value: the application, the analysis and the service delivered to the end customer.

And that starting point keeps improving. Every device added to Marketplace expands what a new project finds already built on day one. Starting later means starting from a higher level, not from the same blank page teams faced three years ago.

The diversity of devices, manufacturers and technologies is not going away. If anything, it will continue to grow. The goal, therefore, should not be to make every device work in exactly the same way. It should be to make sure that integrating a new one does not mean starting over.

For any questions, join our Discord community: our team and other users will be happy to help.