The parameter is a required sensor property. The sensors in the system work mainly on the basis of the data received in the parameter.
Parameters can have any names. These names are predefined in the device configuration, for example, param199, param240, TEMP, pwr_int, gsm, can6, and so on. Read the device specification to find out which parameters are available and what they measure. Besides, you can request messages from the unit on the Messages tab and view the available parameters in the corresponding column.
When adding or editing a sensor, you should select its parameter in the drop-down list or enter the parameter name manually.
The same parameter can be used to create any number of sensors. You can see the maximum allowed number of sensors on the Account tab of the user settings.
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.
Inputs and outputs
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, the 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:
- parameters in the current message (adc1, in1 etc.),
- parameters in the previous message (they begin from the hash sign #, for example, #adc1),
- bitwise parameters (like param199:3),
- sensors (sensor name must be in square brackets, for example, [Fuel level]),
- constant numbers (const10, const-4.54 etc.),
- mathematical operation signs:
|^||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, in tooltips for charts, and during the retransmission of sensors.
Expressions allow you to create a great variety of sensors that meet any needs and tasks.
Example 1: Detecting speed by GPS coordinates
To detect speed by coordinates, you can create a sensor with the following parameter:
The traditional formula to calculate the speed of the movement is "distance divided by time". To calculate the distance, the Pythagorean theorem is used. The 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. The resulting value is the distance (in degrees). This value is divided by the time difference in two neighboring messages. As a result, it is the speed in degrees per second. To convert the value to kilometers per hour (or miles per hour), you should apply the conversion coefficient of degrees to kilometers (or miles) at different latitudes. The coefficient may vary depending on the geographical position. The example above shows the coefficient equal to 200000 which is used for Moscow.
To calculate the coefficient, the following formula is used:
where 111321 is the length of the parallel arc in 1° longitude at the equator, m;
55.75583 is the latitude of Moscow in decimal format.
If you want to calculate the coefficient for another location, insert its latitude in decimal format into the formula without changing other values.
If you have the ignition sensor, you can set the parameter 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.
Example 2: Relative engine hours sensor
To obtain data about real engine hours, create two sensors:
- relative engine hours sensor,
- engine hours coefficient sensor in accordance with engine revolutions.
First, create a sensor of Relative engine hours type. The parameter for the sensor is:
That is, 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:
- 1 minute work with the intensity of 2000 rpm corresponds to 90 seconds of engine work => coefficient 1.5
- 1 minute work with the intensity of 1500 rpm corresponds to 60 seconds of engine work => coefficient 1
- 1 minute work with the intensity of 1000 rpm corresponds to 40 seconds of engine work => coefficient 0.67
- 1 minute work with the intensity of 500 rpm corresponds to 20 seconds of engine work => coefficient 0.33
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:
- x=500 y=0.33
- x=1000 y=0.67
- x=1500 y=1
- x=2000 y=1.5
You can use such sensors in reports and counters, but not in online notifications, because they require the parameters from the previous message.
Example 3: Value availability check
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 the configuration of calculation tables. Textual data is displayed as it is.
The values of text-based sensors can be shown:
- in the additional information about the unit,
- on the Messages tab,
- in the track player,
- in the track hittest,
- in the Formatted value column of the Sensor tracing table.
Conversion of parameters
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.
Bitwise parameter control
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 param199 parameter, 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:
- Create a sensor in which the required parameter comes. For example, Sensor1.
- Create another sensor. For example, Sensor2.
- For the parameter of the second sensor, specify the formula [Sensor1]/const4294967296. In that way, a shift of 4 bytes to the right occurs.
Conversion of textual parameters
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:
Determination of the day number in a year
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,