Metadata and Schema
Creation of Measurement Points
The default protocol for receiving data on the thingable! is the MQTT, this protocol is used directly by the SCADA system that performs real-time monitoring and data history.
In order for this data to be correctly interpreted by the platform, it is necessary to indicate its receipt pattern during the process of creating a device. This pattern varies according to the device and manufacturer, so it becomes necessary to know these standards in detail. The following is an example of a data received by a remote loT device:
Example code:
In the code above we can identify the basic structure of a json that are key and value, for example, "rain" is the key and "0" is its value.
On the platform, more specifically during the process of creating a device we must insert a code in json format known as Schema, this code in addition to translating the received data packages to a device is also responsible for triggering the creation of points and tags in the SCADA system that will identify the data received on the platform.
The following is an example of Schema appropriate for the example shown above:
The main difference in the second code in relation to the first one is that in the field previously intended for the value, it now presents a series of parameters that will tell the SCADA system how it should work with the received values.
The parameters that can be used for each of the expected keys to be received are:
type: indicates the type of value to be received, the options are "number", "string" or "boolean". This parameter is required.
scada type: indicates the nature of the amount to be received. The accepted values are "analogln" for analog values, "digitalln" for discrete values and "tsField" for values that refer to the timestamp of the device.
point: indicates the single point referring to the tag in the SCADA system. For example, if my device is sending temperature, pressure and humidity data to the platform, I will need three different points because there are three tags. Values from 1 to 20 are accepted without repeating.
factor: defines the degree of precision when the decimal places. The values are accepted 1,10,100,1000,10000 and 100000, e.g. 1 for no decimal place, 10 for one decimal place, 100 for two and so on. For any value below this scale, the Lower Limit (1) will be considered, and any value above will be considered the Upper Limit (100000). SCADA only accepts numbers up to 9 digits, this should be observed carefully to prevent excessive pressures from overflowing the entire part of the number, or very large whole parts from reaching the desired decimals. This parameter, when not used, is considered the value 100 as default.
HighlimitValue: Maximum expected value. This parameter is optional and is only used when you want to enable the platform alarms feature, in this case the other alarm limits must also be configured.
HighlimitAlarm: Enable maximum limit alarm notification reached.
VeryHighValue: Value considered too high. This parameter is optional and is only used when you want to enable the platform alarms feature, in this case the other alarm limits must also be configured.
VeryHighAlarm: Enable very high alarm notification reached.
HighValue: Value considered high. This parameter is optional and is only used when you want to enable the platform alarms feature, in this case the other alarm limits must also be configured.
HighAlarm: Enable high value alarm notification reached.
NormalAlarm: Value considered normal. This parameter is optional and is only used when you want to enable the platform alarms feature, in this case the other alarm limits must also be configured.
Normalization: indication of normal value for points with typeScada configured as digitalIn.
LowValue: Value considered too low. This parameter is optional and is only used when you want to enable the platform alarms feature, in this case the other alarm limits must also be configured.
LowAlarm: Enable low value alarm notification reached.
VerylowValue: Value considered too low. This parameter is optional and is only used when you want to enable the platform alarms feature, in this case the other alarm limits must also be configured.
VerylowAlarm: Enable very low value alarm notification reached.
LowlimitValue: Minimum expected value. This parameter is optional and is only used when you want to enable the platform alarms feature, in this case the other alarm limits must also be configured.
LowlimitAlarm: Enable minimum limit alarm notification reached.
Ignored: consists of an array where all the keys used are listed. If for a key we use all the parameterizations listed here, the ignored key would have as value the following array: ["typeScada", "point", "factor", "HighlimitValue", "HighlimitAlarm", "VeryHighValue","VeryHighAlar m", "HighValue", "HighAlarm","NormalAlarm","LowValue","LowAlarm", VeryLowValue "," VeryLowAI arm"," LowlimitValue "," LowlimitAlarm "].
Note1: When we enable the notification of alarms for points with typeScada configured as "digitally" just parameterize the HighAlarm, Normalization and LowAlarm keys.
Note2: Keys with typeScada configured as "tsCampo" do not occupy points in the SCADA system, its parameterization requires only the type (must be configured as string), typeScada and ignored. The accepted values for this type of key are timestamps in ISO 8601 format, for example: "2022-08-08T13:00:00.000Z".
Note3: The limit values of the alarms must correctly obey the order of magnitude, for example a HighValue value must be lower than the value placed in HighlimitValue and so on.
Following the same example above, but now contemplating the parameterizations for alarm notification and with an extra point configured as digitalln.
When finalizing the creation of the Schema appropriate to the context of your device we should make use of it. The use can occur in two ways:
Using the Schema field in the device type: In the documentation Creating a Device (Create a Device)?) the division of devices into types is displayed, the editing of a type has a field called Schema, in this field we will insert the created Schema. When we use the Schema on the device type, all devices created under this type will have the same parameterizations.
Using the Metadata field of a device: When we create a device we have the Metadata field, which is a field intended to load device-specific information in json format, among this information we can put the Schema created, so the parameterizations will only apply to this device, but for this to work correctly it is necessary that the Schema is inside an object identified by the “schema” key as shown in the following figure:
Author: Angelo Guimarães
Last updated
