Join Documentation
Version: 2.0.6
Retrieved: 2025-10-09 15:15:59
Join
The Join module combines messages arriving from different sources at slightly different times into an array of messages aligned on regular time intervals. For example, if you have three sensors sending data once per second you can use the Join module to deliver one message per second, containing an array with data from the three sensors.
Based on the time window specified the Join module will look for the number of message sources specified with the Unique measurements in window setting. Message source are identified by looking at the combination of the Source and Category properties. When the module has seen messages from the number of sources specified it will start to generate output messages for each time interval, as long as their is at least one new value received within the current time window. If a data source is not updated the previously seen value will be used. This is to accommodate for data sources with different update intervals. If multiple values are received from the same source within a time window the Value Policy setting is used to select the value to use in the outgoing message. If no updated measurements have been received within the time window either an empty message or no message will be delivered, based on the settings. Additional settings are available to tune the information in the outgoing messages.
Settings
| Name | Requirements | Purpose | Default |
| Minimum time window | Number 1-100000 | The interval for collecting data | 1000 |
| Unique measurements in window | Number 1-10000 | How many unique combinations of source/category in each time frame. engine.temp, engine.humidity is 2 unique measurements where engine is the source and humidity/temp are the categories | 3 |
| Source property | String 1-128 in length | The name of the property containing the source of the data being collected | source |
| Category property | String 0-128 in length | The name of the property containing the category, such as temp, vibration etc | category |
| Value property | String 0-128 in length | The name of the property containing the actual value | value |
| Value policy | First, Last, Average, Median | The policy deciding how to get the value when several measurements for the same source/category arrives several times during the same time window | First |
| Timestamp policy | First, Last, Middle | The policy for how to set the timestamp on each individual item in the collection | First |
| Add timestamp | Boolean | If checked the result will have a timestamp set for the data collection | False |
| Add item timestamp | Boolean | If checked each item in the collection will have a timestamp | False |
| Include count | Boolean | If checked each item will have a property showing how many items that arrived during the current Time Window | False |
| Send empty collection | Boolean | If checked the module will pass an default message even if no data was collected during the Time Window | False |
Example 1
This sample show the output when the flow is started. The module will not output anything until it has 3 unique measurements. So there will be no output until after message 5.
# Settings:
Minimum time window = 1000
Unique measurements in windows = 3
Source property = source
Category property = category
Value property = value
Value policy = Average
# Incoming messages:
// 1
{
"source": "machine1",
"category": "temp",
"value": 84
}
// 2
{
"source": "machine1",
"category": "temp",
"value": 82
}
// 3
{
"source": "machine1",
"category": "rpm",
"value": 4500
}
// 4
{
"source": "machine1",
"category": "temp",
"value": 74
}
// 5
{
"source": "machine1",
"category": "psi",
"value": 430
}
# Outgoing message:
{
"timestamp": "2018-09-26T12:44:55.718941Z",
"data": [
{
"source": "machine1",
"category": "temp",
"value": 80,
"count": 3
},
{
"source": "machine1",
"category": "psi",
"value": 430,
"count": 1
},
{
"source": "machine1",
"category": "rpm",
"value": 4500,
"count": 1
}
]
}
Example 2
This example assume that we already have the data from example 1 in the module state. This means that historical data will be used when time windows expires. In this example the historical data for temp is used since no new measurements was received during the new time window.
# Incoming messages:
// 6
{
"source": "machine1",
"category": "rpm",
"value": 4600
}
// 7
{
"source": "machine1",
"category": "psi",
"value": 400
}
# Outgoing message:
{
"timestamp": "2018-09-26T12:44:55.718941Z",
"data": [
{
"source": "machine1",
"category": "temp",
"value": 80,
"count": 3
},
{
"source": "machine1",
"category": "psi",
"value": 400,
"count": 1
},
{
"source": "machine1",
"category": "rpm",
"value": 4600,
"count": 1
}
]
}
Search Documentation
Array Modules