Andrew Shvayka
3 years ago
committed by
GitHub
GitHub
34 changed files with 680 additions and 292 deletions
@ -0,0 +1,60 @@ |
|||
/** |
|||
* Copyright © 2016-2023 The Thingsboard Authors |
|||
* |
|||
* Licensed under the Apache License, Version 2.0 (the "License"); |
|||
* you may not use this file except in compliance with the License. |
|||
* You may obtain a copy of the License at |
|||
* |
|||
* http://www.apache.org/licenses/LICENSE-2.0
|
|||
* |
|||
* Unless required by applicable law or agreed to in writing, software |
|||
* distributed under the License is distributed on an "AS IS" BASIS, |
|||
* WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. |
|||
* See the License for the specific language governing permissions and |
|||
* limitations under the License. |
|||
*/ |
|||
package org.thingsboard.rule.engine.transform; |
|||
|
|||
import com.fasterxml.jackson.databind.JsonNode; |
|||
import com.fasterxml.jackson.databind.node.ObjectNode; |
|||
import org.thingsboard.rule.engine.api.TbNode; |
|||
import org.thingsboard.rule.engine.api.TbNodeException; |
|||
import org.thingsboard.rule.engine.util.TbMsgSource; |
|||
import org.thingsboard.server.common.data.util.TbPair; |
|||
|
|||
import java.util.List; |
|||
import java.util.regex.Pattern; |
|||
|
|||
public abstract class TbAbstractTransformNodeWithTbMsgSource implements TbNode { |
|||
|
|||
private static final String FROM_METADATA_PROPERTY = "fromMetadata"; |
|||
|
|||
protected abstract String getKeyToUpgradeFromVersionZero(); |
|||
|
|||
@Override |
|||
public TbPair<Boolean, JsonNode> upgrade(int fromVersion, JsonNode oldConfiguration) throws TbNodeException { |
|||
return fromVersion == 0 ? |
|||
upgradeToUseTbMsgSource((ObjectNode) oldConfiguration, getKeyToUpgradeFromVersionZero()) : |
|||
new TbPair<>(false, oldConfiguration); |
|||
} |
|||
|
|||
private TbPair<Boolean, JsonNode> upgradeToUseTbMsgSource(ObjectNode configToUpdate, String newProperty) throws TbNodeException { |
|||
if (!configToUpdate.has(FROM_METADATA_PROPERTY)) { |
|||
throw new TbNodeException("property to update: '" + FROM_METADATA_PROPERTY + "' doesn't exists in configuration!"); |
|||
} |
|||
var value = configToUpdate.get(FROM_METADATA_PROPERTY).asText(); |
|||
if ("true".equals(value)) { |
|||
configToUpdate.remove(FROM_METADATA_PROPERTY); |
|||
configToUpdate.put(newProperty, TbMsgSource.METADATA.name()); |
|||
return new TbPair<>(true, configToUpdate); |
|||
} |
|||
if ("false".equals(value)) { |
|||
configToUpdate.remove(FROM_METADATA_PROPERTY); |
|||
configToUpdate.put(newProperty, TbMsgSource.DATA.name()); |
|||
return new TbPair<>(true, configToUpdate); |
|||
} |
|||
throw new TbNodeException("property to update: '" + FROM_METADATA_PROPERTY + "' has unexpected value: " |
|||
+ value + ". Allowed values: true or false!"); |
|||
} |
|||
|
|||
} |
|||
@ -0,0 +1,81 @@ |
|||
#### Fields templatization |
|||
|
|||
<div class="divider"></div> |
|||
<br/> |
|||
|
|||
{% include rulenode/common_node_fields_templatization %} |
|||
|
|||
##### Example |
|||
|
|||
Let's assume that a tenant manages two assets: |
|||
|
|||
- `TemperatureManager` asset - responsible for aggregating data from temperature sensors, essential for environmental monitoring and alerts. |
|||
- `HumidityManager` asset - collects data from humidity sensors, analyzing relative humidity levels |
|||
and correlating them with temperature data for comprehensive atmospheric condition monitoring and automated environmental adjustments. |
|||
|
|||
Each message received from the device includes `deviceType` property in the message metadata |
|||
with either `Temperature` or `Humidity` value according to the sensor type. |
|||
|
|||
In order to change the originator to the corresponding manager for further message processing, you can define the next node configuration: |
|||
|
|||
 |
|||
|
|||
Imagine that you receive the message defined below from the `Temperature` sensor |
|||
and forwarded it to the **change originator** node with configuration added above. |
|||
|
|||
- incoming message definition: |
|||
|
|||
```json |
|||
{ |
|||
"msg": { |
|||
"temperature": 32 |
|||
}, |
|||
"metadata": { |
|||
"deviceType": "Temperature", |
|||
"deviceName": "TH-001", |
|||
"ts": "1685379440000" |
|||
} |
|||
} |
|||
``` |
|||
<br> |
|||
|
|||
The same example for the `humidity` sensor: |
|||
|
|||
- incoming message definition: |
|||
|
|||
```json |
|||
{ |
|||
"msg": { |
|||
"humidity": 77 |
|||
}, |
|||
"metadata": { |
|||
"deviceType": "Humidity", |
|||
"deviceName": "HM-001", |
|||
"ts": "1685379440000" |
|||
} |
|||
} |
|||
``` |
|||
|
|||
<br> |
|||
|
|||
To demonstrate that the originator was changed based on rule node configuration, the screenshots with debug events captured for the **change originator** rule node will be added below: |
|||
|
|||
- Debug events for processed message from the `Temperature` sensor: |
|||
|
|||
 |
|||
|
|||
- Debug events for processed message from the `Humidity` sensor: |
|||
|
|||
 |
|||
|
|||
In the debug events displayed, the `IN` message points to the incoming message received by the node, |
|||
with the originator type specified as `DEVICE`. This reflects the message from the actual sensor (e.g., a `Temperature` or `Humidity` sensor). |
|||
After processing through the `change originator` rule node, the `OUT` message has an originator type of `ASSET`, |
|||
indicating that the message originator has been successfully changed to the corresponding managing asset, such as `TemperatureManager` or `HumidityManager`. |
|||
|
|||
<br> |
|||
|
|||
These examples showcases using the **change originator** node with dynamic configuration based on the substitution of metadata fields. |
|||
|
|||
<br> |
|||
<br> |
|||
@ -0,0 +1,68 @@ |
|||
#### Fields templatization |
|||
|
|||
<div class="divider"></div> |
|||
<br/> |
|||
|
|||
{% include rulenode/common_node_fields_templatization %} |
|||
|
|||
##### Example |
|||
|
|||
Let's assume that a tenant manages temperature sensors. |
|||
When a temperature sensor reports a high temperature, the platform creates an alarm. |
|||
|
|||
In addition, let's assume that each sensor has a group of alarm notification subscribers |
|||
associated with it and a primary user that responsible for updating the alarm status. |
|||
|
|||
Imagine that after alarm creation we fetched information about notification subscribers and |
|||
primary users with the help of enrichment rule nodes and after that our message looks like this: |
|||
|
|||
```json |
|||
{ |
|||
"msg": { |
|||
"temperature": 32 |
|||
}, |
|||
"metadata": { |
|||
"deviceType": "Thermostat", |
|||
"deviceName": "TH-001", |
|||
"ts": "1685379440000", |
|||
"primaryUser": "john.doe@example.com", |
|||
"subscribers": "mike.johnson@example.io,sarah.smith@example.org,emily.davis@example.co" |
|||
} |
|||
} |
|||
``` |
|||
<br> |
|||
|
|||
Here is a node configuration: |
|||
|
|||
 |
|||
|
|||
After message evaluation by a rule node the outgoing message will be looks like this: |
|||
|
|||
```json |
|||
{ |
|||
"msg": { |
|||
"from": "info@testmail.org", |
|||
"to": "john.doe@example.com", |
|||
"cc": "mike.johnson@example.io,sarah.smith@example.org,emily.davis@example.co", |
|||
"bcc": null, |
|||
"subject": "Device Thermostat temperature high", |
|||
"body": "Device TH-001 has high temperature 32", |
|||
"images": null, |
|||
"html": false |
|||
}, |
|||
"metadata": { |
|||
"deviceType": "Thermostat", |
|||
"deviceName": "TH-001", |
|||
"ts": "1685379440000", |
|||
"primaryUser": "john.doe@example.com", |
|||
"subscribers": "mike.johnson@example.io,sarah.smith@example.org,emily.davis@example.co" |
|||
} |
|||
} |
|||
``` |
|||
|
|||
<br> |
|||
|
|||
These examples showcases using the **to email** node with dynamic configuration based on the substitution of message and message metadata fields. |
|||
|
|||
<br> |
|||
<br> |
|||
|
After Width: | Height: | Size: 43 KiB |
|
After Width: | Height: | Size: 43 KiB |
|
After Width: | Height: | Size: 44 KiB |
|
After Width: | Height: | Size: 84 KiB |
Loading…
Reference in new issue