Parameter is a required sensor property. Most of the sensors are based on a parameter coming in messages.
Parameters can be of any names. These names are predefined in the device configuration, for example, param199, param240, TEMP, pwr_int, gsm, can6, and the like. Read device specification to find out which parameters are available and what they measure. On the Messages tab, you can also request messages from the unit and view the available parameters in the corresponding column.
The parameters from the last message appear in the dropdown list of available parameters when creating or editing a sensor. However, even if the parameter you need is not on the list, you can enter its name manually.
The same parameter can be used to create any number of sensors. The maximum number of sensors allowed can be viewed on the Account tab of the User settings dialog.
Some parameters are defined in the system by default and are suitable for almost any type of equipment.
speed of motion
altitude above sea level (maybe not supported by some devices)
course (direction of motion)
Unix time of the message
time of registering a message on the server
Some rare types of devices may not support any of these parameters, e.g., altitude or speed.
The system supports up to 32 digital inputs and outputs. They are adjusted in the following format:
digital input parameter, N — input number
digital output parameter, N — output number
analog input parameter, N — input number
For example, adc8 is a parameter that registers the values coming from the eighth analog input.
Usually, the data from digital inputs and outputs are presented in messages in the following format: I/O = 0/0, where I refers to inputs, O — outputs. If I/O = 0/0, it means all bits (inputs and outputs) are inactive. If a value in any of them is not zero, it means that one input/output or several of them are active. To determine which exactly, convert the hexadecimal number to binary and use the latter to define a bit number.
For instance, when the ignition was activated, we received the message with the parameter I/O = 10/0. To get the bit number (input) in which the value of the sensor is shown, it is necessary to enter the received value in the calculator in the mode of hexadecimal values (HEX). That is, enter 10 and switch to the binary mode (BIN). We get a new number - 10000. Now we have to calculate in which position 1 has appeared. The calculation is done from right to left. In the given case 1 is in position 5, i.e. the ignition sensor is connected to the fifth port. Since the changed number is before the fraction (I/O), it is the input. Consequently, the parameter name is in5 (digital input 5).
For a sensor, it is also possible to specify the parameter name as in or out to indicate the sum of all inputs and outputs, respectively.
Besides, constN parameter can be used to create a sensor that always returns the same value. N is any number, e.g., const10, const-8.5. Such a sensor can be helpful in charts or as a validator.
Parameter for a sensor can be set in the form of expression where you can use:
|^||exponentiation & rooting|
brackets of priority
||||value availability check|
For example, ^const2 — square, ^const0.5 — extract the square root.
If one of the parameters that an expression includes is not valid, its total value is also invalid.
The parameters from the previous message are not available for the Private mode sensor and its validator, in notifications and in tooltips for charts.
Expressions allow creating a great variety of sensors that meet any needs and tasks.
It is possible to create a sensor to detect speed by coordinates. It will have the following parameter:
The traditional formula to calculate the speed of the movement is 'distance divided by time'. To calculate the distance, we apply the Pythagorean theorem: squared difference of latitudes in neighboring messages plus the squared difference of longitudes in neighboring messages, and then the square root is extracted from this sum. So, we get the distance (in degrees). This value is divided by the difference of time in two neighboring messages. As the result, we have the distance in degrees per second. To convert this to the more habitual kilometers per hour (or miles per hour), we apply a special coefficient. It varies depending on geographical position. In the example above it is equal to 200000 and applicable to Moscow.
If you have the ignition sensor, the parameter can be set in the following way:
You can use such a sensor only in reports (not in online notifications) because it requires the parameters from the previous message.
To obtain data about real engine hours, create two sensors:
First, create a sensor of Relative engine hours type. The parameter for the sensor is:
That is, the time difference in neighboring messages multiplied by the coefficient of the intensity of work and divided by 3600. The division by 3600 is applied to convert seconds into hours.
Then, create the coefficient sensor that will define the intensity of work depending on engine revolutions. Dependency scheme can be the following:
Suppose, the param1 sends engine revolutions. Then the coefficient parameter is the following:
That is the arithmetic average of engine revolutions between neighboring messages.
To convert revolutions into coefficient, adjust the calculation table for this sensor:
You can use such sensors only in reports (not in counters, nor in online notifications) because they require the parameters from the previous message.
There is equipment installed on the vehicle, which sends some parameter (for example, param1). Then the equipment gets out of order. A new one is installed. The new equipment sends the same data in another parameter (for example, param2). To exclude data loss during report generation, it is necessary to use value availability check in the Parameter field upon creating a sensor. The old equipment worked all December, the new one — all January, and we need a report for these two months. If the value availability check is used during the parameter indication (param1|param2 entered as sensor parameter), then the system takes a value from the param1 parameter, and if the param1 value is invalid (for example, the equipment is broken), then the system takes a value from the param2 parameter. In other words, when using the value availability check, the system takes into account the first valid value of the parameter received.
Does not work with digital sensors.
Most parameters are designed to send numeric data, however, in some cases, they may provide textual data. This can be, for example, a name of a status (business/private), some state (free/waiting/busy, on/off), time passed since a certain event, etc.
Sensors with textual parameters do not require configuration of calculation tables. Textual data is displayed as it is.
The values of text-based sensors can be shown in:
The conversion of parameters can only be applied to the parameters that are received directly from the hardware. The cases of application are described below.
The bitwise parameter control gives an opportunity to control a specific bit and not the whole parameter. For example, in order to control the third bit of the parameter param199 it is necessary to put a colon and the number of the required bit after its name.
This feature is applicable when a device sends various data in one parameter: for instance, the first bit shows alarm condition (on/off), the second bit indicates the state of the driver's door (open/closed), the third — headlights, etc. Thus, using bitwise control it is possible to create several sensors on the basis of one parameter.
The parameters of the double type are converted into int, and only then the bit is retrieved.
We advise you not to address directly a bit above the 53rd. If necessary, you can use the following scheme.
If there is a textual parameter in the sensor formula, it is converted into 53-bit integer. By default, it is interpreted as decimal, however, positional notation can be specified after colon. For example, there is a parameter called text_param and it has the value 100, then:
To determine the number of the day in the year (relative to January 1), it is necessary to indicate d after the colon. For example, for March 28, 2017 11:00:00 the Unix time corresponds to the value 1490698800. Therefore,