Command disabled: backlink

Parameter is a required sensor property. Each sensor is based on a parameter coming in messages. If the configured unit already has messages, it is recommended to explore them and find available parameters.

Parameters can be of any names. These names are normally predefined in 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.

One parameter can be used to create as many different sensors as you want.

Some of supported parameters are reserved in the system as default:

speed | speed of motion |
---|---|

altitude | altitude above sea level (may be not supported by some devices) |

sats | satellites count |

course | course (direction of motion) |

lat | geographical latitude |

lon | geographical longitude |

time | time in message |

The system supports up to 32 digital inputs and outputs. They are adjusted in the following format:

inN | digital input parameter, N - input number |
---|---|

outN | digital output parameter, N - output number |

adcN | analog input parameter, N - input number |

For example, *adc8* is referred to as parameter which registers the values coming from the eighth analog input.

Normally, 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 something of them is not zero, it means that an input/output or several of them are active. To define, which of them exactly, hexadecimal number (which you see in message) must be converted into bit number.

For example, when ignition was activated, the message with parameter I/O = 10/0 was received. We need to retrieve bit (input in our case) number from the received value - 10. To achieve this, open the calculator in the HEX mode and key in 10. Then switch to the BIN mode and get the binary number - 10000 in our case. Now count in which position 1 appeared (count from right to left). In our example, this is the 5th position, so, the ignition is connected to digital input 5. This means that the required parameter is *in5*.

There is a possibility of bitwise parameter control. That means that not the whole parameter value can be analyzed but a certain bit. For this, indicate bit number after parameter name separating it with colon. For example, *param199:3* should be written to control the 3rd bit of the parameter named param199.

This feature is applicable when a device sends various data in one parameter: for example, the first bit shows alarm condition (on/off), the second bit indicates driver's door state (open/closed), the third - headlights, etc. Thus, using bitwise control it is possible to create several sensors on basis of one parameter.

Note that doubles are converted to integers, and only then the bit is retrieved.

Besides, **constN** parameter can be used to create a sensor which 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.

Such a sensor can be used both independently (for example, in charts to mark some critical line) or as a part of validation chain or in expressions.

Parameter for a sensor can be set in the form of expression. In those expression 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:

+ | addition |
---|---|

− | subtraction |

∗ | multiplication |

/ | division |

^ | exponentiation & rooting |

( ) | brackets of priority |

For example, *^const2* - square, *^const0.5* - take the square root .

*Note*:

Parameters from the previous message are not available in notifications.

Expressions allow creating a great variety of sensors which can satisfy any needs and assigned tasks.

It is possible to create a sensor to detect speed by coordinates. It will have the following parameter:

((lat-#lat)^const2+(lon-#lon)^const2)^const0.5/(time-#time)*const200000

*Explanation:*

The traditional formula to calculate the speed of movement is 'distance divided by time'. To calculate the distance, we apply Pythagorean theorem: squared difference of latitudes in neighboring messages plus squared difference of longitudes in neighboring messages, and then the square root is taken 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 more habitual kilometers per hour (or other metrics), 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 like this:

((lat-#lat)^const2+(lon-#lon)^const2)^const0.5/(time-#time)*const200000*[Ignition sensor name]

To get real engine hours in report, create two sensors:

- relative engine hours sensor,
- coefficient sensor which depends on engine revolutions.

First, create a sensor of *Relative engine hours* type. The parameter for the sensor will be:

(time-#time)*[Name of coefficient sensor]/const3600

The meaning: time difference in neighboring messages multiplied by the coefficient of intensity of work and divided by 3600. The division by 3600 is applied to convert seconds into hours.

Then, create the coefficient sensor which will define the intensity of work depending on engine revolutions. Dependency scheme can be like this:

- 500 rpm correspond to 90 seconds of engine work ⇒ coefficient 1,5
- 1000 rpm correspond to 60 seconds of engine work ⇒ coefficient 1
- 1500 rpm correspond to 40 seconds of engine work ⇒ coefficient 0.67
- 2000 rpm correspond to 1 minutes of engine work ⇒ coefficient 0.33

Let's assume that *param1* sends engine revolutions. Then the coefficient parameter will be like this:

(param1+#param1)/const2

The meaning: arithmetic average of engine revolutions between neighboring messages.

To convert revolutions into coefficient, adjust the calculation table for this sensor:

- x=500 y=1,5
- x=1000 y=1
- x=1500 y=0.67
- x=2000 y=0.33

Do not forget to set the relative engine hours sensor as the counter of engine hours (General tab).

Was this helpful?

Thank you!