Version 4.1 by Hera Guo on 2024/11/07 15:49
Show last authors
1 **Table of Contents:**
2
3 {{toc/}}
4
5
6
7 = 1.About rule chains =
8
9 The system provides a rule chain library for developers to configure message transformation, filtering, computation, and transmission on their own.
10
11 = 2.Rule chain creation =
12
13 The system provides a default root rule chain that supports user use. No changes are made on the root rule chain, but the root rule chain is exported and re imported, and then modified and configured in the newly imported rule chain.
14
15 Firstly, follow the steps below to export the root rule chain. After clicking on export, the system will automatically download it, and the exported file will be in JSON format.
16
17 [[image:1730343544790-113.png||height="711" width="1364"]]
18
19 Re import the exported configuration into the system. After clicking on import, the system will directly jump to the configuration page of the newly imported rule chain. Simply click on the "Apply Change" button in the bottom right corner.
20
21 Re exit to the rule chain library menu to see the newly imported rule chain library configuration.
22
23 [[image:1730344152898-509.png||height="711" width="1363"]]4
24
25
26 [[image:1730344348542-260.png||height="701" width="1361"]]
27
28 = 3.Rule chain modification =
29
30 Follow the steps below to modify the basic information of the rule chain. You can rename the rule chain imported in the previous section.
31
32 [[image:1730344632740-435.png||height="702" width="1362"]]
33
34 [[image:1730345137320-999.png||height="705" width="1366"]]
35
36 [[image:1730345353615-959.png||height="706" width="1369"]]
37
38 = 4.Rule chain deletion =
39
40 You can delete a newly created rule chain by following the following steps.
41
42 note: the default root rule chain provided by the system cannot be deleted.
43
44 [[image:1730346321550-495.png||height="705" width="1371"]]
45
46 = 5.Rule chain configuration =
47
48 If you need to configure the rule chain, you need to follow the following steps to enter the configuration page of the rule chain.
49
50 [[image:1730346571913-889.png||height="714" width="1373"]]
51
52 [[image:1730346890962-926.png||height="711" width="1376"]]
53
54 [[image:1730347084731-765.png||height="717" width="1377"]]
55
56 [[image:1730347231071-931.png||height="712" width="1377"]]
57
58 Next, we will explain the configuration of rule nodes that may be commonly used in different classes to manipulate data. As the default device configuration was applied in the creation of the previous device ,
59
60 the rule chain used in the default device configuration is the Root Rule Chain. Therefore, the following demonstrations are all configurations made in the Root Rule Chain.
61
62 = 6.About Nodes =
63
64 == 6.1 filter ==
65
66 === 6.1.1 check fidles presence ===
67
68
69 (% id="cke_bm_11489S" style="display:none" %) (%%)This rule node is used to verify the existence of certain attributes in the message body or metadata, and distribute the message based on the verification results. The configuration content of this node includes:
70
71 * **Name:** required field, indicating the name of the node;
72 * **Message field names:** The name of the attribute to be verified in the message body, which is the content of the message actively sent by the device. Multiple attributes can be configured here, and after entering each attribute, press' Enter 'to enter;
73 * **Metadata field names:** The attribute names that need to be validated in the message metadata. The metadata is the data attached to the system and generally includes three metadata attributes: DeviceType, DeviceName, and ts. Multiple attributes can be configured here, and after entering each attribute, press' Enter 'to enter;
74 * **Check that all specified fields are present: **Select the box, and when performing the above attribute verification, connect each verification condition with "and"; When not selected, during the above attribute verification, each verification condition is connected by "or";
75 * **Explanation: **Non mandatory field, additional explanation;
76
77 According to the judgment result, there are two types of exits for this rule node: true and false.
78
79 A simple usage example is as follows:
80
81
82 [[image:1730353965218-437.png||height="724" width="1374"]]
83
84 === 6.1.2 script ===
85
86
87
88 (% id="cke_bm_12553S" style="display:none" %) (%%)This rule node allows developers to implement data filtering through programming, that is, to distribute messages using custom filtering rules. The configuration content of this node includes:
89
90 * **Name:** required field, indicating the name of the node;
91 * **Function Filter:** Code (customizing filtering rules through code), the function parameters include msg (message), metadata (metadata), msgType (message type pushed by the previous node), and the return value should be a Boolean value;
92 * **Explanation:** Non mandatory field, additional explanation;
93
94 According to the code logic, there are two types of exits for this rule node: true and false.
95
96 A simple usage example is as follows:
97
98
99 [[image:1730354366308-318.png||height="708" width="1374"]]
100
101 === 6.1.3 switch ===
102
103
104
105 This rule node allows developers to implement data grouping filtering through programming, that is, to distribute data using custom distribution rules. The configuration content of this node includes:
106
107 * **Name:** required field, indicating the name of the node;
108 * **Function Switch: **Code (customizing grouping rules through code), function parameters include msg (message), metadata (metadata), msgType (message type pushed by the previous node), return value should be a string array, indicating the path to be distributed;
109 * **Explanation: **Non mandatory field, additional explanation;
110
111 According to the code logic, the exit of this rule node is defined by the coding personnel, as shown in the example.
112
113 A simple usage example is as follows
114
115 {{code language="none"}}
116 if (msg.temperature > 25) {
117 return ['High temperature'];
118 } else if (msg.temperature < 18) {
119 return ['Low temperature'];
120 } else {
121 return ['Normal temperature'];
122 }
123
124 {{/code}}
125
126 (% class="wikigeneratedid" %)
127 (((
128 The above code defines three exits, namely High temperature, Low temperature, and Normal temperature. Therefore, when connecting to the next node, we need to customize the connection according to our defined exit path, as shown in the following figure. After completing the input, press "Enter" to create a link label, and then click "Add".
129 )))
130
131 (% class="wikigeneratedid" %)
132 (((
133
134 )))
135
136 (% class="wikigeneratedid" %)
137 (((
138 [[image:1730355203367-790.png||height="715" width="1392"]]
139 )))
140
141 (% class="wikigeneratedid" %)
142 (((
143 [[image:1730355288161-463.png||height="725" width="1390"]]
144 )))
145
146 == 6.2 properties ==
147
148 === 6.2.1 calculate delta ===
149
150
151
152
153
154 This rule node is used to calculate the difference between the data in this message and the corresponding data in the previous message, and to refine and distribute the message content based on the calculation results. The configuration content of this node includes:
155
156 * **Name:** required field, indicating the name of the node;
157 * **Input value Key:** required field, the name of the attribute to be incrementally calculated;
158 * **Output value Key:** required field, the attribute name of the incremental value calculated and added to the message body;
159 * **Decimals: **Accuracy of incremental computation;
160 * **Use cache:** Select option to store the value of the previous data in memory, checked by default;
161 * **Tell Failure if delta is negative:** Select option. If the increment value is negative, it is considered a message processing failure and is checked by default;
162 * **Add period between messages: **Select option to add the time difference from the previous message in the message body, not checked by default. After selecting, you need to fill in the Period value key as the attribute name added to the message body as the calculated time difference;
163 * **Exclude zero deltas from outbound message:**Only output data with delta difference non-zero.
164 * **Explanation:** Non mandatory field, additional explanation;
165
166 According to the running results, there are three types of exits for this rule node:** Success**, **Failure**, and **Other**:
167
168 * **Success:** The data export for successful incremental calculation;
169 * **Failure:** The data exit for message processing failure. If Tell Failure if delta is negative is checked, the data with a negative increment will be calculated and output from this exit;
170 * **Other:** The data export for the attribute value to be incrementally calculated is missing from the message;
171
172 A simple usage example is as follows:
173
174
175
176 [[image:1730356036784-417.png||height="734" width="1378"]]
177
178
179
180
181
182 === 6.2.2 customer attributes ===
183
184
185
186
187
188 This rule node is used to add some attributes configured for users to the metadata of messages and distribute data based on the processing results. The configuration content of this node includes:
189
190 * **Name:** required field, indicating the name of the node;
191 * **Latest telemetry:** a selection option that will retrieve the latest attribute values reported remotely by the client based on the configured key. Unchecking it will query the server attributes of the client to which the device belongs, and it will be unchecked by default;
192 * **Source telemetry key:** input item, the name of the customer attribute to be added to the message metadata;
193 * **Target attribute: **Input item, the attribute name to be added to the message metadata, which appears in conjunction with the Source telemetry key and can add multiple pairs of attributes;
194 * **Explanation: **Non mandatory field, additional explanation;
195
196 According to the running results, there are two types of exits for this rule node: Success and Failure. When the customer to which the device belongs is not configured, data is output from the Failure exit.
197
198 This involves setting user attributes, which can be configured as follows.
199
200
201 [[image:1730357095598-358.png||height="717" width="1377"]]
202
203
204 A simple example of using this rule node is as follows:
205
206
207 [[image:1730357340823-311.png||height="613" width="1372"]]
208
209
210
211 === 6.2.3 customer details ===
212
213
214
215
216
217 This rule node is used to add some detailed information configured for users to the message and distribute data based on the processing results. The configuration content of this node includes:
218
219 * **Name:** required field, indicating the name of the node;
220 * **Select entity details: **Multiple options, select the detailed information of the customer to be added to the message (the information configured when creating the customer, including country, city, address, email, etc.), and the attribute name format of the added information is "customer-specific content name";
221 * **Add selected details to message metadata:** If checked, the corresponding information will be added to the metadata and passed to downstream nodes; If not checked, the corresponding information will be added to the data and passed to downstream nodes. Not selected by default;
222 * **Explanation: **Non mandatory field, additional explanation;
223
224 According to the running results, there are two types of exits for this rule node: Success and Failure. When the customer to which the device belongs is not configured, data is output from the Failure exit.
225
226 A simple usage example is as follows:
227
228
229
230 [[image:1730357528275-219.png||height="711" width="1387"]]
231
232
233
234 === 6.2.4 tenant attributes ===
235
236 === 6.2.5 tenant details ===
237
238
239
240
241
242 This rule node is used to add some detailed information configured for tenants to the message and distribute data based on the processing results. The configuration content of this node is exactly the same as that of the customer details rule node, and will not be repeated here.
243
244 A simple usage example is as follows:
245
246 [[image:1730964386323-616.png||height="740" width="1394"]]
247
248
249
250 === 6.2.6 fetch device credentials ===
251
252
253
254
255
256 This node is used to add the device's key and token type to the message and pass it to downstream nodes. The node configuration includes:
257
258 **Name:** required field, indicating the name of the node;
259
260 **Retrieve credentials to metadata: **Select the option and add the device key information to the metadata. Otherwise, add it to the message data and select it by default;
261
262 **Explanation: **Non mandatory field, additional explanation;
263
264 According to the running results, there are two types of exits for this rule node: Success and Failure.
265
266 A simple usage example is as follows:
267
268
269
270 [[image:1730965249482-406.png]]
271
272
273
274 == 6.3 transformation ==
275
276 === 6.3.1 copy key-value pairs ===
277
278
279
280
281
282 This node is used to copy key values from metadata to data, or to copy key values from data to metadata. The node configuration includes:
283
284 **Name: **required field, indicating the name of the node;
285
286 **Copy from:** a selection option that allows you to choose the direction of copying, from data to metadata or from metadata to data.
287
288 The following input boxes allow you to enter the name of the attribute to be copied, and you can enter multiple names. After entering, press Enter to complete the typing once;
289
290 **Explanation:** Non mandatory field, additional explanation;
291
292 According to the running results, there are two types of exits for this rule node: Success and Failure.
293
294 A simple usage example is as follows:
295
296
297
298 [[image:1730965445070-151.png]]
299
300
301
302 === 6.3.2 delete key-value pairs ===
303
304
305
306
307
308 This node is used to delete key values in data or metadata. The node configuration includes:
309
310 **Name: **required field, indicating the name of the node;
311
312 **Delete from: **Select an option that allows you to choose where to delete data, from the data, or from the metadata.
313
314 The following input boxes allow you to enter the name of the attribute to be copied, and you can enter multiple names. After entering, press Enter to complete the typing once;
315
316 **Explanation: **Non mandatory field, additional explanation;
317
318 According to the running results, there are two types of exits for this rule node: Success and Failure.
319
320 A simple usage example is as follows:
321
322
323
324 [[image:1730965545372-196.png]]
325
326
327
328 === 6.3.3 rename keys ===
329
330
331
332
333
334 This node is used to rename attributes in data or metadata. The node configuration includes:
335
336 **Name:** required field, indicating the name of the node;
337
338 **Rename keys in:** a selection option that allows you to choose where to change the data, either from the data or from the metadata.
339
340 The following Key name and New Key name appear in pairs, indicating the original attribute name and the new attribute name;
341
342 **Explanation:** Non mandatory field, additional explanation;
343
344 According to the running results, there are two types of exits for this rule node: Success and Failure.
345
346 A simple usage example is as follows:
347
348
349 [[image:1730965632561-703.png]]
350
351 === 6.3.4 deduplication ===
352
353
354
355
356
357 This node can be used for message deduplication or changing the frequency of sending messages downstream. The configuration content of the node includes:
358
359 **Name: **required field, indicating the name of the node;
360
361 **Interval:** required field, indicating the time interval, that is, how often data is sent downstream;
362
363 **Strategy: **Select option, indicating the strategy for sending messages downstream. The system provides three strategies for developers to choose from, namely First Message, Last Message, and All Messages. The first two strategies are to send the earliest or latest data downstream, and the last strategy is to send a JSON string group of all data. When selecting the latter left strategy, it is also necessary to configure the Output message type and queue. The former is for message type configuration, while the latter is for queue configuration;
364
365 **Explanation:** Non mandatory field, additional explanation;
366
367 According to the running results, there are two types of exits for this rule node: Success and Failure.
368
369 A simple usage example is as follows:
370
371
372
373 [[image:1730965718765-507.png]]
374
375
376
377 === 6.3.5 script ===
378
379
380
381 == 6.4 action ==
382
383 === 6.4.1 math function ===
384
385 === 6.4.2 create alarm && clear alarm ===
386
387 === 6.4.3 delay ===
388
389 === 6.4.4 generator ===
390
391 === 6.4.5 log ===
392
393 == 6.5 external ==
394
395 === 6.5.1 kafka ===
396
397 === 6.5.2 mqtt ===
398
399 === 6.5.3 rest api call ===