This shows you the differences between two versions of the page.

Both sides previous revision Previous revision | |||

cms:units:sensors:validation [24/09/2018 15:28] tagr |
cms:units:sensors:validation [24/07/2020 19:27] (current) mary |
||
---|---|---|---|

Line 7: | Line 7: | ||

**Validation type** is the way the validator affects the current sensor. The following validation methods are available: | **Validation type** is the way the validator affects the current sensor. The following validation methods are available: | ||

- | * //Logical AND//: values of both sensors are analyzed, and the logical function AND is applied. It means the output is true (1) if both values are not null. As a result, the current sensor value can be either 0 or 1. | + | * **Logical AND**: values of both sensors are analyzed, and the logical function AND is applied. It means the output is true (1) if both values are not null. As a result, the current sensor value can be either 0 or 1. |

- | * //Logical OR//: both values are analyzed, and the logical function OR is applied. It means the output is true if at least one value is not null. As a result, the current sensor value can be either 0 or 1. | + | * **Logical OR**: both values are analyzed, and the logical function OR is applied. It means the output is true if at least one value is not null. As a result, the current sensor value can be either 0 or 1. |

- | * //Not-null check//: if the validator is not null, current sensor value is considered true and displayed without transformations. Otherwise, it is blank. | + | * **Not-null check**: if the validator is not null, current sensor value is considered true and displayed without transformations. Otherwise, it is blank. |

- | * //Mathematical AND//: the mathematical function AND is applied. | + | * **Mathematical AND**: the mathematical function AND is applied. |

- | * //Mathematical OR//: the mathematical function OR is applied. | + | * **Mathematical OR**: the mathematical function OR is applied. |

- | * //Sum up//: values are summed up. | + | * **Sum up**: values are summed up. |

- | * //Subtract validator from sensor//: the validator value is subtracted from the sensor value. | + | * **Subtract validator from sensor**: the validator value is subtracted from the sensor value. |

- | * //Subtract sensor from validator//: the sensor value is subtracted from the validator value. | + | * **Subtract sensor from validator**: the sensor value is subtracted from the validator value. |

- | * //Multiply//: values are multiplied. | + | * **Multiply**: values are multiplied. |

- | * //Divide sensor by validator//: the sensor value is divided by the validator value. | + | * **Divide sensor by validator**: the sensor value is divided by the validator value. |

- | * //Divide validator by sensor//: the validator value is divided by the sensor value. | + | * **Divide validator by sensor**: the validator value is divided by the sensor value. |

- | * //Replace sensor with validator in case of error//: if the main sensor has no available data, all values are taken from the validator. | + | * **Replace sensor with validator in case of error**: if the main sensor has no available data, all values are taken from the validator. |

- | :!: //Note//.\\ Validation chain can consist of any number of sensors. So, one sensor can be a validator for another sensor and at the same time depend on the third sensor. | + | :!: Validation chain can consist of any number of sensors. So, one sensor can be a validator for another sensor and at the same time depend on the third sensor. |

===== Examples ===== | ===== Examples ===== | ||

Line 38: | Line 38: | ||

The example is the following: every door of a vehicle is equipped with a sensor. Every sensor indicates whether the door is opened or closed. It is necessary to know if the vehicle is opened or closed, and it does not matter which door is open. | The example is the following: every door of a vehicle is equipped with a sensor. Every sensor indicates whether the door is opened or closed. It is necessary to know if the vehicle is opened or closed, and it does not matter which door is open. | ||

- | For this purpose, the sensor with //Custom digital sensor// type should be created in Wialon for every door. Then, one by one, validate the sensors indicating //Logic OR// as the validation type. When using the //Logic OR// function, the vehicle is considered to be opened if any of its doors is opened (the 1st, or the 2d, or the 3d, etc.). For convenience, we can remove the //Visibility// checkbox for all used sensors, except for the last validated sensor. Therefore the visible sensor shows whether the vehicle is closed or opened. | + | For this purpose, the sensor with **Custom digital sensor** type should be created in Wialon for every door. Then, one by one, validate the sensors indicating **Logic OR** as the validation type. When using the **Logic OR** function, the vehicle is considered to be opened if any of its doors is opened (the 1st, or the 2d, or the 3d, etc.). For convenience, we can remove the **Visibility** checkbox for all used sensors, except for the last validated sensor. Therefore the visible sensor shows whether the vehicle is closed or opened. |

==== Mathematical AND ==== | ==== Mathematical AND ==== | ||

Line 44: | Line 44: | ||

Suppose, there is a vehicle with the sensors installed on every door, and these sensors show whether the door is opened or not. In this example, it is necessary to know the state of every door individually. The equipment used in our example sends a value about the state of the doors in one parameter (each bit represents the door). | Suppose, there is a vehicle with the sensors installed on every door, and these sensors show whether the door is opened or not. In this example, it is necessary to know the state of every door individually. The equipment used in our example sends a value about the state of the doors in one parameter (each bit represents the door). | ||

- | The sensor with the //Custom sensor// type is created in Wialon and the parameter for incoming value of the state of the doors is indicated. Then the sensor with the //Customer digital sensor// type is created for every door individually indicating constant parameter (for the first — const1, for the second — const2, for the third — const4, for the fourth — const8). The earlier created custom sensor should be indicated as the validator with the validation type //Mathematical AND// for every created custom digital sensor. Therefore, using //Mathematical AND// the verification of a received parameter is implemented, and we find out the state of every door. | + | The sensor with the **Custom sensor** type is created in Wialon and the parameter for incoming value of the state of the doors is indicated. Then the sensor with the **Customer digital sensor** type is created for every door individually indicating constant parameter (for the first — const1, for the second — const2, for the third — const4, for the fourth — const8). The earlier created custom sensor should be indicated as the validator with the validation type **Mathematical AND** for every created custom digital sensor. Therefore, using **Mathematical AND** the verification of a received parameter is implemented, and we find out the state of every door. |

==== Mathematical Operations Usage ==== | ==== Mathematical Operations Usage ==== | ||

Line 63: | Line 63: | ||

* 111 — all equipment is on. | * 111 — all equipment is on. | ||

- | To make this scheme work, adjust dependency between the sensors. Let us make Sensor A basic. Then the validator for Sensor A will be Sensor B, with the validation type //Sum up//. Sensor C will be the validator for Sensor B (with the same validation type). | + | To make this scheme work, adjust dependency between the sensors. Let us make Sensor A basic. Then the validator for Sensor A will be Sensor B, with the validation type **Sum up**. Sensor C will be the validator for Sensor B (with the same validation type). |

It is also useful to assign a color to each possible value (see [[cms/units/adv|]]) so that these colors could be used to visualize sensor in the Monitoring panel, on the map or in tacks. | It is also useful to assign a color to each possible value (see [[cms/units/adv|]]) so that these colors could be used to visualize sensor in the Monitoring panel, on the map or in tacks. | ||

Line 71: | Line 71: | ||

Supposedly, there is a vehicle with two fuel tanks. Each tank has its own fuel level sensor. We need to know the total fuel level of the two tanks. | Supposedly, there is a vehicle with two fuel tanks. Each tank has its own fuel level sensor. We need to know the total fuel level of the two tanks. | ||

- | In Wialon create a sensor with the type //Custom sensor// for one tank, and the //Fuel level sensor// for the other. For the latter, activate the validation by the sensor with the //Custom sensor// type, validation type — //Sum up//. If it is more convenient, the visibility checkbox for the validated sensor can be kept, for the other — can be removed. Therefore we can see the validated sensor value which is the total fuel level for these fuel tanks. | + | In Wialon create a sensor with the type **Custom sensor** for one tank, and the **Fuel level sensor** for the other. For the latter, activate the validation by the sensor with the **Custom sensor** type, validation type — **Sum up**. If it is more convenient, the visibility checkbox for the validated sensor can be kept, for the other — can be removed. Therefore we can see the validated sensor value which is the total fuel level for these fuel tanks. |

:!: Using any mathematical operation as a validation method is equal to indicating sensor parameter using formula. In other words, any mathematical operation as a method of validation has an alternative without validation usage. In order to understand how it works, we shall use the above-mentioned example with two tanks where we should know the total fuel level of two tanks. | :!: Using any mathematical operation as a validation method is equal to indicating sensor parameter using formula. In other words, any mathematical operation as a method of validation has an alternative without validation usage. In order to understand how it works, we shall use the above-mentioned example with two tanks where we should know the total fuel level of two tanks. | ||

- | In Wialon create two sensors with //Custom sensor// type (//Tank1// and //Tank2//) and a fuel level sensor (//Total//). In the parameter of the //Total// sensor, enter the formula [Tank1]+[Tank2]. The //Tank1// and //Tank2// sensors show their own fuel level, and the //Total// sensor shows the total fuel level of both tanks. | + | In Wialon create two sensors with **Custom sensor** type (**Tank1** and **Tank2**) and a fuel level sensor (**Total**). In the parameter of the **Total** sensor, enter the formula [Tank1]+[Tank2]. The **Tank1** and **Tank2** sensors show their own fuel level, and the **Total** sensor shows the total fuel level of both tanks. |

- | The advantage of using formulas is in the amount of information received. For example, if //Tank2// is validated by //Tank1//, we would know //Tank1// fuel level, but //Tank2// would show us only the total fuel level for these two tanks. Using formulas, we also know //Tank2// fuel level. | + | The advantage of using formulas is in the amount of information received. For example, if **Tank2** is validated by **Tank1**, we would know **Tank1** fuel level, but **Tank2** would show us only the total fuel level for these two tanks. Using formulas, we also know **Tank2** fuel level. |

The disadvantage of using formulas is the creation of a greater amount of sensors than with the use of validation. | The disadvantage of using formulas is the creation of a greater amount of sensors than with the use of validation. | ||

Was this helpful?

Thank you!