Synchronizing Device Payloads with Eclipse Vorto: A Practical Guide

Alexander Edelmann

你好 (Chinese for “Hello”), I’m Alexander Edelmann, based in Singapore and have been a software engineer at Robert Bosch since 2006. I am passionate about IoT and advocate for open standards that enable seamless device interoperability across platforms. I actively contribute to the Eclipse IoT Vorto project, which delivers cloud‑based tools for uniform device description and integration across diverse IoT ecosystems. Outside of engineering, I enjoy Asian cuisine, practicing my chop‑stick skills, and tennis.

In an environment lacking a global standard, IoT device manufacturers, integrators, and platform providers struggle with the sheer variety of payload formats, APIs, and proprietary protocols.

Eclipse Vorto tackles this challenge by offering cloud‑based editors that abstract vendor‑specific payloads into reusable Vorto Function Blocks. These blocks are assembled into a Vorto Information Model that defines a device’s digital twin. Both Information Models and Function Blocks are written in vortolang, a concise grammar that specifies the interface between a physical device and its digital twin. IoT solutions communicate exclusively through these abstract Function Blocks and their related data schemas, thereby decoupling from disparate device data formats. Converting raw device data into these abstract interfaces is achieved via Vorto Mapping Specifications, which encode the instructions needed to harmonize device‑specific payloads.

Payload normalization in general

Data normalization can be performed at various points in the IoT stack, allowing stakeholders to retain control over where proprietary data is transformed into a standardized form.

1. On the device node – A smart device, such as a Bosch smart oven, processes sensor data locally, normalizes it, and may expose analytics that can be aggregated into a cloud data lake.
2. On the gateway node – A gateway that aggregates multiple sensors or devices via diverse protocol drivers (BLE, GPIO, etc.) normalizes incoming data to provide gateway‑level analytics or other business functions.
3. On an IoT platform node – Similar to a gateway, a cloud IoT platform normalizes telemetry received through protocol adapters (MQTT, CoAP, etc.) to power device‑management or analytics services.
4. On an application node – An application normalizes data so that it can remain agnostic of specific devices, focusing instead on business logic rather than device‑specific decoders.

When a device cannot perform payload mapping—perhaps due to limited processing power or bandwidth constraints—a separate mapping engine must execute this step on an intermediary, gateway, platform, or application node.

Normalization of data can be handled either on a device node (1), on a gateway node (2), on an IoT platform node (3) or on an application node (4).

Tim Grossmann

As a German computer‑science student, I have completed projects in three different Bosch departments over the past year and a half. My interests lie in Open Source and EduTech technologies. I believe IoT and automation hold immense potential to transform daily life. I am a dedicated learner and developer, and I maintain the world’s largest free open‑source Instagram automation bot. In my spare time, I enjoy climbing and traveling abroad.

How Eclipse Vorto addresses normalization

Eclipse Vorto provides a runtime library that, when configured with a Vorto Information Model, applies the mapping specification to transform raw device payloads into their normalized form. The mapping specification is versioned and stored alongside the device’s Information Model in the Vorto Repository, enabling reuse across different deployment nodes—device, gateway, platform, or application. The library is currently available for Java and Node.js. Read more about the Vorto Payload Mapping library.

Example: Normalizing industry data using Eclipse Vorto

To illustrate these concepts, consider a scenario where CSV telemetry from a permanent‑magnet synchronous motor (PMSM) is transmitted to an Eclipse Hono MQTT connector.

The Vorto Payload Normalization middleware consumes this data from Hono, routes it through the Vorto Payload Mapping Engine, and publishes the harmonized data as an AMQP topic. Any AMQP 1.0 subscriber can then consume the standardized data regardless of the original device, leveraging a digital‑twin platform such as Bosch IoT Things.

In this example, we employ Eclipse Ditto, an open‑source digital‑twin service, to ingest and store the normalized data. The Vorto Dashboard then queries the Ditto API and presents the information using pre‑defined Vorto‑compliant UI widgets.

The full conceptual setup of our device payload mapping pipeline.

If you wish to observe the entire mapping pipeline in action, visit the Vorto Dashboard Demo.

This article provides a brief overview of Payload Mappings. For a comprehensive, step‑by‑step guide to configuring your own pipeline, consult our detailed tutorial.