> For the complete documentation index, see [llms.txt](https://docs.kpnthings.com/kpn-things/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kpnthings.com/kpn-things/building-blocks/data-processing/merger.md).

# Merger

{% hint style="warning" %}
**Add-on feature**\
This feature is only available for contracted customers. Please contact <iot@kpn.com> if your are interested!
{% endhint %}

When configuring your Destination, you can also configure merger functionality. When you enable the merger for your Destination, you can have data from different decoders merged into one message to your Destination.&#x20;

The merger could be useful to merge LoRa Geolocation information with the decode payload from your LoRa device, in order to present this LoRa Geolocation data as an ordinary measurement to your application.

<figure><img src="https://1453626848-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2Fl6RrePMSAjRvOgcHjMBZ%2Fuploads%2F1uwbVYZzOnZuMWjZhMau%2Fimage.png?alt=media&amp;token=acd940bf-1365-411e-a659-39a25e18af65" alt=""><figcaption><p>The merger can merge the output of multiple decoders back to one message.</p></figcaption></figure>

{% hint style="warning" %}
If two SenML packs that are merged contain a record with the same SenML name, both SenML records will be put in the final SenML pack. You application should.

In the future, we plan to implement *priority*, where measurements with the same SenML name can overwrite the other measurement.
{% endhint %}

## Attributes

| Attribute                    | Value             | Description                                                                 |
| ---------------------------- | ----------------- | --------------------------------------------------------------------------- |
| `merge`                      | *true/false*      | Whether to enable merger functionality.                                     |
| `mergeDecoderSpecifications` | array of uuid's   | Array of decoder specification uuid's of decoder outputs you want to merge. |
| `ttl`                        | nr. seconds       | (Default: 10) max. time to wait for all messages to merge.                  |
| `orphanStrategy`             | *DISCARD/FORWARD* | What to do with messages arriving after the ttl.                            |

Decoder specification uuid's are listed on the [Supported device types](/kpn-things/getting-started/tutorials/connect-devices/supported-devices-and-kpn-devices.md) page and the [KPN Things devices](/kpn-things/the-portal-explained/things-manager/iot-devices.md) page.

{% hint style="info" %}
With a ttl of 10s you could expect up to 2% of LoRa Geolocation messaged to be outside the ttl. With a ttl of 15s, up to 1% can be outside ttl.

A higher ttl will increase the change all messages are merged. A lower ttl will introduce a shorter delay for message that could not be merged.
{% endhint %}

## Example

Below an example of two merged messages is given.

### Before merge

```javascript
// Output from the LoRa Geolocation decoder
[
  {"bn": "urn:dev:DEVEUI:0059AC00001B036E:", "bt": 1599058945, "n": "locOrigin", "vs": "KPNLORA"},
  {"n": "latitude", "u": "lat", "v": 51.982597},
  {"n": "longitude", "u": "lon", "v": 4.467995},
  {"n": "radius", "u": "m", "v": 111.272842}
]

// Output from the ThingsML for LoRa decoder
[
  {"bn": "urn:dev:DEVEUI:0059AC00001B036E:", "bt": 1599058946, "n": "temperature", "u": "Cel", "v": 25},
  {"n": "humidity", "u": "%RH", "v": 13.6},
  {"n": "radius", "u": "m", "v": 20}
]
```

### After merge

As you can see the two decoder outputs have been merged into one SenML pack. Because the LoRa Geolocation data is one second newer than the data from the payload, all SenML records from the latter are given an extra `t`-attribute to express the time difference.&#x20;

Also, since both decoder outputs contain a `radius` measurement, there are now two SenML records with this measurement name.

```javascript
[
  {"bn": "urn:dev:DEVEUI:0059AC00001B036E:", "bt": 1599058945, "n": "locOrigin", "vs": "KPNLORA"},
  {"n": "latitude", "u": "lat", "v": 51.982597},
  {"n": "longitude", "u": "lon", "v": 4.467995},
  {"n": "radius", "u": "m", "v": 111.272842},
  {"n": "temperature", "u": "Cel", "v": 25, "t": 1},
  {"n": "humidity", "u": "%RH", "v": 13.6, "t": 1},
  {"n": "radius", "u": "m", "v": 20, "t": 1}
]
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.kpnthings.com/kpn-things/building-blocks/data-processing/merger.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.