Fleetrun
Hecterra
NimBus
Other apps
Wialon for Android/iOS
Logistics
Wialon Local
Wialon Hosting
Distance Tag
WiaTag
Configurator
Contents
Command Does Not Work
  • technical_consulting
  • commands
  • sms

Wialon not only receives data from trackers, but can also send commands to them. In this article, you will find conditions for executing commands, the description of peculiar properties of different channels for sending commands, as well as possible issues and their solutions.

Conditions for executing commands

To execute commands, you should consider several conditions at once related to the service, account, user, and unit. Let's look at these conditions one by one.

  1. The Commands service is enabled in the account.



  2. The user has the Send commands special right regarding the unit.



  3. The command is created in the same-name Commands tab in the unit properties.


    To create commands, the user must have the Create, edit, and delete commands special right regarding the unit.

  4. There are several additional conditions for executing commands over the SMS channel:
    • The SMS messages service is enabled in the account.

    • SMS must be available in the service, i.e., the counter on the top panel must be greater than zero.

      This counter is not displayed if the service uses a personal modem for sending SMS.

    • In the General tab in the unit properties, you must specify the Phone number in international format, to which the tracker will receive SMS.

Peculiarities of channels for sending commands

The channel (connection type) for sending the command is selected in its properties. Depending on the selected channel, you should consider the unit with the server connection state when executing the command.

The unit keeps an Internet connection with the server if messages with data or keep alive/heart beat packets come from it. To check the current connection status, you can use the Connection state column on the Monitoring panel.

Channel

Peculiarities

GPRS (TCP/UDP)

The unit must keep an Internet connection with the server.

Virtual

This channel is similar to TCP/UDP judging by the principle of sending, but the virtual command can be executed even when the unit is not connected to the server. At the moment of execution, the command is queued, and its actual sending will be done at the moment the unit goes online.

For each type of device, Wialon imposes a limit on the number of virtual commands in the queue, and when the queue is full, a new virtual command will push the oldest command out of the queue (it will not be sent).
SMSThe unit may not keep an Internet connection with the server.
AutoWhen sending, the program will choose the channel that is currently available. If more than one type is available, the channel that is higher in this table will be used.
If the communication channel selected for commands is currently available, the button for command execution opposite the unit on the Monitoring panel will become active.

Checking the command sending on the Wialon side

The fact of command execution is recorded in the unit Log. This information is also available for viewing:

  • in the Messages tab when requesting Sent commands;
  • in the Messages tab when requesting SMS messages;
  • in the report with the Sent commands table.

An entry about command execution in the log means that the command was executed on the Wialon side. Then it is sent over a TCP/UDP channel or transferred to the modem/SMPP gateway for sending.

If the command was not executed when pressing the corresponding button, you should check the compliance with the above-mentioned requirements. If all the requirements were met and the unit did not lose connection at the moment of command execution, you can send a detailed description of the problem (username, unit, command name and execution time) to support@gurtam.com for analysis by Wialon technical support specialists.

Possible issues and their solutions

If according to the Wialon log the command is executed, but there is no response from the tracker, the issue is most likely related to the operation of third-party systems. It’s possible that the tracker did not receive the command, the tracker did not perform the programmed actions on the command, or it did not send a response/file to the command to Wialon. The most common issues of this kind and possible actions to solve them are listed below.

IssuePossible causesOptions for action
SMS command is not delivered to the unit

Problems with the delivery of SMS messages and TCP/UDP commands are usually associated with problems at the level of telecom operator/Internet provider networks. Together with your provider, you should check the message delivery route, troubleshoot the network, or search for other delivery routes.

If you use the 500 SMS package, write to Wialon technical support at support@gurtam.com.
If you use your own SMPP gateway or modem, please contact your SMPP provider or GSM operator to analyze the situation.

The command is delivered but with incorrect text

Typically, this problem is related to the telecom operator encoding and is relevant mainly for SMS messages. Wialon uses the standard A5 (CCITT T.50)/ASCII (ANSI X3.4) encoding. The recipient's operator may use a different protocol and, as a result, decode the message incorrectly.

The user should contact the recipient's operator to correct the situation.

An alternative is to use your own SMPP gateway with the required encoding.
The command is delivered with the correct text, but the tracker did not execute/rejected the command

An incorrect command format is specified in SMS. You should double-check the syntax according to the device manual or contact the hardware manufacturer.

If standard Wialon commands are used (except Custom message), make sure that the correct parameters are specified in the command (for example, the number of the tracker input for activation). You can also contact Wialon technical support at support@gurtam.com, providing the detailed problem description.

An SMS command is received from a sender's number that is not added to the allowed list.

Add the allowed number in the tracker settings.

The command is received from an IP not allowed to the tracker.

Add the allowed IP in the tracker settings. IP in Wialon Hosting depends on the service data center, and you can see it in the General tab in the properties of any unit.

The Password for executing commands is not entered in the unit settings (or it does not match the password in the tracker).

Double-check the password for executing commands. It is recommended to use the Latin alphabet for the password, because the tracker may decode other languages incorrectly.

The tracker is defective.

A hardware or software failure at the tracker level should be analyzed with the engineer maintaining this tracker.

The command is delivered, executed by the tracker, but the Wialon system receives no response

For some types of devices, there is an additional hardware protocol setting, where you should activate the corresponding flag or configure settings for receiving and displaying messages from the tracker.

When configuring the device, find and activate the corresponding option in the General tab. The configuration button is located to the right of the device type entry field and is active if the device itself provides the configuration option.

The command came from a virtual number that cannot act as an SMS recipient.

Wialon Hosting uses a virtual number 79037676122. You can contact Wialon technical support at support@gurtam.com and clarify whether it’s possible to switch your service to another available sender phone number in order to receive SMS responses from trackers to this number.
If, due to the peculiarities of SMS delivery routes to a certain country, you cannot set a different sender’s number for sending SMS, the most convenient solution would be to connect your own SMPP gateway for your Hosting service with the ability to receive SMS from trackers. To connect your SMPP gateway to the Hosting service, contact your manager (or Wialon technical support for technical advice).


Sergey Novikov,Technical Consulting Engineer

How to Choose a Parameter for a Sensor
  • technical_consulting
  • sensor_parameters
  • sensor_types

If you know the device type, its configuration, and how it was installed, you may know which parameter to choose for the sensor in Wialon. But if you have just started working with Wialon and have doubts, this article can help you select a parameter based on how other users usually do it.

General recommendations

  1. You can find the list of parameters and their description on the page of a specific device on gurtam.com in the Hardware section. To do this, enter the desired device model in the Search hardware line. You can also select one of the categories of hardware types and find the desired model on the list. Then, on the hardware page, go to the Parameters tab (an example of such a page for WiaTag).

    If there is no parameter description on the hardware page, please contact hardware specialists via hw@gurtam.com.
  2. In most cases, you can understand the value of a parameter by its English name. For example, the fuel_lvl parameter will most likely display the fuel level value, the total_mileage parameter — mileage sensor values, and so on. Parameter names received from CAN bus usually begin with the prefix can.

  3. Parameters sent by the device can be described in the hardware documentation. As a rule, documentation is available on the manufacturer's website.

  4. There is a list of virtual parameters defined in the system by default and suitable for almost any type of hardware:
    • speed — speed of movement;
    • altitude — height above sea level;
    • sats — number of satellites;
    • course — direction of movement;
    • lat — latitude;
    • lon — longitude;
    • time — UNIX time of the message;
    • regtime — time of the message registration on the server.

The method for searching and checking the selected parameter depends on the type of sensor in which it is used. Below, we’ll cover a few examples for the most commonly used types of sensors.

Engine ignition sensor

Engine ignition sensor is a digital sensor that indicates whether the engine is running or not. When the value of a digital sensor is zero, it is considered off, and when the value is non-zero, the sensor is considered on.

Engine ignition sensor does not indicate the ACC position of the ignition key, in which the engine is not running, but additional hardware is already available for use.

One of the digital inputs can be used as a parameter for the Engine ignition sensor (the I/O format parameter at the end of messages). It describes the state of all digital inputs and outputs simultaneously, and you can use it to determine the state of a particular digital input inN (the logic for selecting the input number N is described in another article).

You can also try to create an engine ignition sensor based on the external voltage parameter (usually named pwr_ext). In this case, you need to create the Calculation table in the sensor properties. The user guide provides an example of such a table. When using this example, you only need to change the voltage threshold at which the ignition will be considered on.

Practical method for selecting and checking a parameter

  1. Turn off the engine and wait for a few messages from the tracker.
  2. Start the engine and wait for a few more messages.
  3. Compare the messages received in points 1 and 2. If there was an abrupt change of only one parameter, it is most likely that it will indicate the ignition status. If several parameters changed, you can select the desired one using the additional check described in the following point.
  4. Examine the messages with non-zero speed. It is assumed that the ignition is on when there is speed, as well as in several messages before and after the speed exists. At the same time, it is recommended to consider intervals with a duration of at least five minutes, since some trackers can change the mode of sending messages after the start and the end of the movement.
 Example

Messages with the following parameters are received from the unit:


Speedparam1param2param3
15526.00301000
25626.00401020
35726.00511015
4026.00611004
5026.0071476
6026.0080489
71026.00901001
81126.01011004

Let's assume that the unit ignition was off in the 5th and 6th messages (highlighted in red). In other messages, the ignition is on (highlighted in green).

param1 — the value was constantly increasing at all intervals, there are no abrupt changes, there is no connection with the speed or its absence. Hence, this parameter can’t be used for the ignition sensor.

param2 — changed at all three intervals, took on a zero value when there was speed in the messages, although the ignition should have been turned on at that moment. Hence, this parameter can’t be used for the ignition sensor.

param3 — at intervals when the ignition is supposed to be on, the parameter takes on a value of more than 1000, and at intervals when the ignition is off, the value abruptly drops to a level of less than 500. Hence, you can try to use this parameter in the ignition sensor by applying the calculation table.

Mileage sensors

Currently, Wialon has two sensors for tracking mileage:

  • Mileage sensor shows the entire mileage of the unit since the sensor was installed.
  • Relative odometer shows the mileage between the current and previous messages.

If the device sends parameters for both mentioned types of sensors at once, the odometer readings do not have to completely coincide with the difference that you get by subtracting the mileage sensor readings in two adjacent messages. This is due to the fact that the calculation algorithm for sensors may differ on the device side. In that case, it is advised to choose the sensor that shows more reliable results.

Both mileage sensors use kilometers (or miles) as measuring units. If the incoming parameter has other measuring units, you should apply a coefficient for converting to kilometers (or miles). For example, if the can_odo parameter displays the value in meters, then in the Parameter line in the sensor parameters, you will need to write the following formula to convert to kilometers: can_odo/const1000

Practical method for selecting and checking a parameter

You can use the Distance tool to check whether the parameter for Mileage sensor or Relative odometer is selected correctly. The parameter values and the distance measured between two messages most often do not completely coincide, but are comparable. This is due to the fact that the Distance tool mathematically calculates the distance between two points with the selected coordinates, and sensors usually calculate kilometers traveled based on the number of wheel rotations and its diameter.

You can use the parameter in the Mileage sensor if

  • its value does not change when the unit stands;
  • its value increases when the unit is moving;
  • the difference of its values in two adjacent messages is comparable with the value obtained by using the Distance tool.

You can use the parameter in the Relative odometer if

  • it is zero when the unit stands;
  • it has a positive value when the unit is moving;
  • it has approximately equal values when the unit is moving at the same speed;
  • its value is comparable with the value obtained by using the Distance tool.
 Example

Messages with the following parameters are received from the unit:

Create a Mileage sensor based on the mileage parameter, as it constantly increases while moving and does not drop to zero during a stop.

Create a Relative odometer based on the odo parameter, as it has different values while moving and drops to zero during a stop. However, its value seems too high, so try using the odo/const1000 formula.

Measure the unit mileage between several pairs of messages using the Distance tool by placing the measured segments on top of the track.

Compare the obtained results:

Mileage sensorDifference with the previous by the mileage sensorRelative odometerThe Distance tool
16801.54 km1.00 km
26802.52 km6802.52 - 6801.54 = 0.98 km1.00 km1.000 km
36803.51 km6803.51 - 6802.52 = 0.99 km1.00 km1.020 km
46804.00 km6804.00 - 6803.51 = 0.49 km0.50 km0.500 km
56804.20 km6804.20 - 6804.00 = 0.20 km0.50 km0.160 km
66804.20 km6804.20 - 6804.20 = 0.00 km0.00 km-

The values are approximately equal, therefore, we can assume that the parameters for both sensors are selected correctly.
Please note that different sensors may have different accuracy. In this case, in the Mileage counter and Trip Detector, it’s recommended to use the sensor that sends readings closest to the expected ones.

Fuel sensors

Currently, Wialon has several types of fuel sensors:

  • Absolute fuel consumption sensor (AbsFCS) shows the fuel consumption for the entire period of unit operation. Therefore, to obtain data on the fuel consumption for a specific period, you should use the following algorithm: calculate the difference in sensor readings at the end and the beginning of the considered interval.
  • Instant fuel consumption sensor (InsFCS) shows the amount of consumed fuel since the previous measurement (message). Therefore, to obtain data on the fuel consumption for a specific period, you should use the following algorithm: calculate the sum of the sensor readings in all messages in the considered interval.
  • Impulse fuel consumption sensor (ImpFCS) — the operating principle of this sensor is similar to Instant fuel consumption sensor.
  • Fuel level sensor (FLS) is designed to calculate the amount of fuel in the tank. You can use it to calculate fuel consumption, as well as control fuel thefts and fillings.
  • Fuel level impulse sensor (ImpFLS), like the previous sensor, is designed to calculate the amount of fuel in the tank. You can use it to calculate fuel consumption, as well as control fuel thefts and fillings. The difference from FLS is that the data from the previous message is used in the calculation, and the difference in the impulse values of two adjacent messages is divided by the time difference between them. This type of sensor is almost never used in practice – instead, most users prefer a traditional FLS.

If the device sends parameters for several of the mentioned types of sensors at once, their readings, as well as the calculation results for them, may differ. This is due to the difference in measuring methods, and the peculiarities of working with fuel. In that case, it is advised to choose the sensor that shows more reliable results.

Fuel information can be contained in parameters with the following names: fuel_lvl, fuel_used, cons_total, can_fuel, rs485_lls, adc1, adc2, etc.

You should select the sensor type based on how the parameter value changes. Let’s consider the different behavior of parameters below.

AbsFCS

You can use the parameter in the Absolute fuel consumption sensor if

  • its value does not change when the engine is off;
  • its value increases when the engine is running;
  • its value increases faster when driving or operating under a load than when stopped or with no load.

InsFCS and ImpFCS

You can use the parameter in the Instant fuel consumption sensor or Impulse fuel consumption sensor if

  • it is zero when the engine is off;
  • it has a positive value when the engine is running;
  • it has approximately equal values when the unit is moving at the same speed or operating under the same load.

FLS

You can use the parameter in the Fuel level sensor if

  • its value does not change when the engine is off;
  • its value gradually decreases when the engine is running;
  • its value decreases faster when driving or operating under a load than when stopped or with no load;
  • its value fluctuates around the actual value during engine operation and movement;
  • its value increases sharply during fuel filling.

In contrast to fuel consumption sensors, the parameter from FLS may behave not the way described above, because fuel theft may happen during a stop or movement, the unit may move at an angle, the temperature may change significantly during the day, fuel may contain impurities, etc. Find more information about fuel control issues and their solutions in the MiscellaneousFuel section.

Below is an example of the FLS parameter changing chart, which covers the trip and filling intervals.

In some cases, the FLS parameter behaves in the opposite way: when the engine is running, its value increases, and when filling, it decreases. This difference will be neutralized after the tank is calibrated and its results are entered into the Calculation table.

Ekaterina Grib,Technical Consulting Engineer

How to Choose the Number of Digital Input/Output (I/O)
  • technical_consulting
  • sensor_parameters

Digital input and digital output are electrical contacts (connector pins) that are energized by the voltage of only two levels: one of them corresponds to the on-state (1, or On), and the other one — to the off-state (0, or Off). Hence, digital inputs and outputs are used to connect tracker and devices or circuits that transmit only two possible states. For example, you can connect a door status sensor to the tracker's digital input so that the tracker can determine whether the door is open or not. And you can connect an anti-theft device to the tracker's digital output that will be controlled by the tracker and block the ignition.

I should note that if the client requires an exact numerical value, an analog connector is needed. Because if you, for example, use a digital input for FLS, you can only find out whether there is fuel in the tank or not.

The number of digital inputs and outputs on the tracker may be quite large (for example, Galileosky 7x may have from 6 to 10 digital inputs, depending on modification and configuration). Therefore, users often wonder to which digital input or output the installer connected the device a client is interested in. Follow the instructions below to get the answer.

Displaying digital inputs/outputs

At first, it should be noted that the state of digital inputs and outputs in Wialon is represented as two hexadecimal numbers (HEX) obtained from binary numbers (BIN), in which each bit corresponds to an input/output with the same number. The parameter with these values is named I/O (short for Inputs/Outputs) and contains two numbers separated by a slash: to the left, there is the value corresponding to the state of all inputs, and to the right — the state of the outputs.

Why was this implementation chosen? Let's look at an example.

Suppose that some vehicle attachments are connected to digital inputs 1, 3, 4 and 7 and outputs 1, 3, 6 and 8. Also, suppose that all the mentioned inputs and outputs are activated in the considered message. If separate parameters were used for each of them in the message, you would see the following:

in1=1, in2=0, in3=1, in4=1, in5=0, in6=0, in7=1, in8=0, out1=1, out2=0, out3=1, out4=0, out5=0, out6=1, out7=0, out8=1

In the current implementation in Wialon, you will see the following entry:

I/O=4D/A5

The obvious conciseness of the entry is a key advantage.

Defining the number of an activated digital input/output

If the number N of an input or output is known, the corresponding parameter will be inN, and the output parameter will be outN. For example, the fourth input is in4 and the output — out4.

However, if you don't know the number of an input or output to which the hardware is connected, you can use one of two methods: selection or a mathematical approach.

Selection

When connecting hardware, installers most often use the first inputs/outputs. So, if we talk about a device or circuit that transmits information to the tracker, you should check in1-in4, and if it's about a device or circuit that the tracker controls — out1-out4.

To find the needed input, you can create 4 sensors with the Custom digital sensor type based on these parameters (for example, the first sensor will have in1 in the Parameter field, the second — in2, and so on). Then go to the Messages panel, select the Data Messages type, and specify Sensor values ​​in the menu below. After that, query messages for the interval when the hardware was first turned off and then turned on to find the moment of transition from Off to On in one of the columns, each of which corresponds to the created sensor.

This is the fastest practical way to find the needed input (similarly, you can work with outputs, but in this case, you should use the parameters out1, out2, and so on). If it doesn't work, you can use a mathematical approach.

Mathematical approach

If you don't know the number of an input/output to which the hardware is connected, you can use the following instructions:

  1. Go to the Messages panel, select the Data Messages type, and specify Initial data in the menu below.
  2. Query messages for the interval when the hardware was first turned off and then turned on.
  3. After displaying the table with messages from the tracker, pay attention to the Parameters column and find the I/O parameter there (it's located at the very end of the line).

    Suppose that the message where the hardware was turned off has the I/O=102/0 parameter, meaning that digital outputs are deactivated (or not even connected), and some digital inputs are activated.

  4. Open the Calculator application (it is preinstalled on every computer, or you can find its analogs on the internet) and switch it to the Programming mode (or a similar one that allows you to convert values from one numeral system to another).
  5. Switch the calculator to a hexadecimal numeral system (HEX).
  6. Enter the value 102 found earlier.
  7. The application will automatically (or by pressing the enter key) show you the given number in different numeral systems. We need the binary format entry (BIN), which consists only of zeros and ones.



  8. Examine the resulting binary number. Note that the bit number is counted from right to left (as in the decimal system, where ones are to the right, tens are to the left of them, then hundreds, thousands, and so on): 0001 0000 0010
  9. Determine the bit numbers for a given number (bit numbering in Wialon starts from 1):

    Number121110987654321
    Value000100000010
  10. From this entry, we can conclude that in this message, inputs 2 and 9 are activated (i.e., in2=1, in9=1), and all other inputs are deactivated (i.e., their value is zero).
  11. Now find the message where the hardware was turned on. Suppose it contains the I/O=10A/0 parameter.
  12. Repeat steps 4-8 for the 10A value.



  13. Determine the bit numbers for a given number:

    Number121110987654321
    Value000100001010
  14. In this message, inputs 2, 4 and 9 are activated (i.e., in2=1, in4=1 and in9=1).
  15. Compare the results of steps 10 and 14. As you can see, they differ only in the state of the in4 parameter, which means the hardware in the given example was connected to input 4.

Using digital inputs/outputs

You can use the digital input or output parameter the same way as any other parameter.

When creating sensors for digital inputs/outputs, types from the Digital group are most suitable since they imply only two states (On and Off).

A unique use case, which is only available for digital inputs, is a notification with the Digital input type, for which you don't even need to create a sensor.

Oleg Zharkovsky,Wialon Trainer

Incorrect Mileage
  • technical_consulting
  • trips

Incorrect mileage can affect the calculation of average speed, average fuel consumption per kilometer, service intervals and, of course, the indicator of the distance traveled. Therefore, it is crucial to track and fix problems that arise both on the hardware and software side.

If you’re faced with the problem of incorrect mileage detection in a report, on a track, or in messages, the first thing you should do is to check what type of mileage counter is selected on the General tab in the unit properties:

  • GPS
  • GPS + ignition sensor
  • Mileage sensor
  • Relative odometer

After finding out which counter is used in your unit, choose the appropriate section of the article.

1. GPS

When using this type of counter, the mileage correctness can be affected by the unstable communication with satellites, data transmission failures, as well as the use of additional sensors. Let's consider these options in more detail.

a. Outliers of coordinates and incorrect message chronology

Outliers of coordinates may appear due to poor communication with satellites of the Global Navigation Satellite System (GNSS). To determine that outliers occurred, go to the Messages tab and upload data for the required unit for the problematic time interval. On the map, you will see a track that can be used to determine the fact of outliers: coordinates of messages are significantly spaced from the actual unit location.


In this example, a clear indication of problems with determining the unit location is the HDOP parameter – it has values >1.

Wialon has a limitation: no more than 1 message should come from a unit per 1 second. If the terminal transmits more than 1 message per 1 second, the chronology of messages may be disrupted and the track will look the same. The reason is incorrect arrangement of messages with positional data (coordinates) in the Wialon database. In such cases, you should reduce the frequency of sending messages with data in the terminal settings.

Possible solutions:

  • Use Message validity filtration;
  • Change the Trip Detector settings.

In the example above, we managed to get rid of outliers by using the ignition sensor in the trip detector, since they are detected in the interval when the ignition is switched off:



b. Using the mileage sensor

In some cases, the counter (the General tab in the unit properties) works based on GPS coordinates, but a separate mileage sensor is also created (the Sensors tab in the unit properties). In reports, for example, with the Trips table, the Mileage column will display the value based on GPS (total distance between coordinates), but the value of the Initial/Final mileage columns will be calculated using the following methods:

  • If the first/last message of the interval has the mileage sensor value, the system uses these values.
 Explanation

Let's agree that the unit actually traveled 2 km, and messages came in the following order:

  1. 10 km
  2. -- km
  3. -- km
  4. 15 km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 10 km (as in the message); in the Final mileage column, we get 15 km (as in the message).

В колонке Пробег получим 2 км (суммарное растояние между координатами без учета датчика пробега), в колонке Начальный пробег получим 10 км (как в сообщении), в колонке Конечный пробег получим 15 км (как в сообщении).

A similar example, but the value of the mileage sensor is available only in the last message:

  1. -- km
  2. -- km
  3. -- km
  4. 15 km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Final mileage column, we get 15 km (as in the message).

And one more example, where the mileage sensor value is only available in the first message:

  1. 10 km
  2. -- km
  3. -- km
  4. -- km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 10 km (as in the message).

  • If there is no mileage sensor value in the first message of the interval, the system looks for the first available message with the mileage sensor value for this interval, and then the mileage before the start of the trip, calculated from GPS coordinates, is subtracted from it.
 Explanation

Let's agree that the unit actually traveled 2 km, and messages came in the following order:

  1. -- km
  2. -- km
  3. -- km
  4. 15 km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 15 km – the value calculated from GPS coordinates or 15 km - 2 km = 13 km; in the Final mileage column, we get 15 km (as in the message).

  • If there is no mileage sensor value in the last message of the interval, the system looks for the last available message with the mileage value for this interval, and then the mileage at the end of the trip, calculated from GPS coordinates, is added to it.
 Explanation

Let's agree that the unit actually traveled 2 km, and messages came in the following order:

  1. 10 km
  2. -- km
  3. -- km
  4. -- km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 10 km (as in the message); in the Final mileage column, we get 10 km + the value calculated from GPS coordinates or 10 km + 2 km = 12 km.

  • If there is no mileage sensor value in the first and last messages, the system looks for the first available sensor value, and then subtracts the mileage calculated from GPS coordinates from it to get the initial value, and to get the final value, on the contrary, adds the mileage calculated from GPS coordinates to the mileage sensor value.
 Explanation

Let's agree that the unit actually traveled 2 km, and messages came in the following order:

  1. -- km
  2. 10 km
  3. 15 km
  4. -- km

In the Mileage column, we get 2 km (the total distance between coordinates without considering the mileage sensor); in the Initial mileage column, we get 10 km – the value calculated from GPS coordinates before the first message of the interval; in the Final mileage column, we get 10 km + the value calculated from GPS coordinates before the last message of the interval.

In such a situation, if due to some failures the mileage sensor didn’t work and sent 0 km, negative mileage values may appear:


In this example, a mileage sensor was created for the unit based on the can_mileage parameter, which is absent in messages until 12/18/2019 4:38:54 PM:


After 4:38 PM onwards, the parameter always has the value 0, and the sensor, respectively, has the value 0 km.

Possible solutions:

  • Remove the mileage sensor and completely switch to the mileage using GPS coordinates;
  • Fix the problem on the hardware side or switch to a parameter with correct values.

In the example above, the solution was to remove the sensor and switch to GPS mileage only, since the parameter values were not read from the CAN bus.

2. GPS + ignition sensor

When using this type of counter, the mileage correctness can be affected by the unstable communication with satellites, data transmission failures, as well as the use of additional sensors. However, a significant difference from the GPS type and a fairly common cause of issues in this type of counter will be the use of an ignition sensor that doesn’t work correctly. Let's consider this option in more detail.

Incorrect value of the ignition sensor

The GPS + ignition sensor option is selected as the mileage counter. When building a track (via the Messages, Tracks or Reports tab), the mileage is 0 km, while the track itself is displayed on the map:



The track on the map is built according to coordinates from messages, while the mileage calculation algorithm takes into account not only coordinates and distance between messages, but also checks if the ignition is on.

In this example, a sensor with the Ignition type is not created for the unit, so the system ignores all messages and displays 0 km of mileage:


Possible solutions:

  • Switch the mileage counter to GPS;
  • Add a correctly working ignition sensor.


In the example above, the unit doesn’t send a parameter based on which the ignition state can be determined, therefore the problem is solved by switching to the GPS counter type.

3. Mileage sensor

The readings of any sensors, including mileage, can be exposed to external factors such as power shutdown, pickups, sensor malfunctions, errors of calibration and sensor/terminal configurations. Let's consider some examples of errors in more detail.

a. Resetting values of the mileage parameter

Some terminals stop transmitting mileage sensor readings for a short period of time (for example, due to power shutdown, pickups in the power supply circuit, other hardware issues). In such cases, the accumulated total mileage of the unit may differ from the last available sensor value:





In the example, the total mileage on the mileage counter is 26943 km, and on the mileage sensor – only 7069 km.

The reason is the reset of the mileage sensor parameter.


In such a situation, there occurs a reset to 0 km and then again an increase to 6452 km (in the example, such resets were repeated several times).

Possible solutions:

  • Use the Lower bound in the sensor settings;
  • Use Validation if the reset occurs under certain circumstances, and you can identify the dependence with other parameters (sensors).

In the example above, it is enough to apply the lower bound (0.01), since the reset occurs randomly and there is no dependence on other sensors.




Thus, by applying the lower bound, we managed to eliminate zero values (reset to 0 km) and avoid the incorrect mileage calculation.

b. Messages with the same timestamp (the With overflow option enabled)

Terminals may send messages too frequently. Wialon has a limitation: no more than 1 message should come from a unit per 1 second. When receiving data with a higher frequency, its chronology may be disrupted and a lower mileage value may end up in the database after a message with a larger value, an example is in the picture below:


In such situations, the counter overflows to the maximum possible value – 2147483648.

Possible solutions:

  • Disable the With overflow option in the sensor settings (if it was enabled).

In the example above, the With overflow option was enabled. Turning it off, we got a more correct mileage value:


с. Messages with the same timestamp (the With overflow option disabled)

Messages may come with the same timestamp, disrupting the chronology, for example:

In general, in the picture above, the mileage looks correct – 25.01 km, in contrast to the previous example, where the error was obvious. However, if we take from the messages the initial value of the mileage sensor in the interval – 9917.81 km and the final value – 9942.44 km, subtract the difference, then we get the mileage – 24.63 km.

The difference is 0.38 km on a relatively small section of the track. The inaccuracy will grow with the increasing amount of data (number of trips). The reason for this error is, of course, the disruption of message chronology. The system expects the sensor value to increase. In the example, we see a drop from 9931.03 km to 9930.85 km and a subsequent increase to 9931.29 km. The mileage between messages with the sensor value 9930.85 km and 9931.29 km is recalculated, i.e., an extra 0.44 km is added.

Possible solutions:

  • Switch the mileage counter to GPS;
  • Fix the problem on the hardware side;
  • Switch the mileage sensor to the Relative odometer type and apply validation.

In the example above, we managed to get more correct mileage values by switching the mileage sensor to the Relative odometer type with the added validation. The relative odometer sensor is based on a parameter represented as: mileage-#mileage. The validator is based on a parameter represented as: time-#time. The lower bound for the validator is 0, and the validation type is Not-null check. The mileage counter in the General tab is switched to Relative odometer.

After applying the validation, the mileage was 24.65 km. Messages with the same timestamp are excluded from the calculation.

If you have any questions on specific practical cases, you can contact technical support via email support@gurtam.com. Make sure to indicate in your email a brief description of the situation with screenshots, the exact unit name, the report template name for verification, the minimum time interval for verification (for example, not a month, but one day), and other essential details.

Pavel Chebotarev,Wialon Trainer

Issues When Changing Access Rights to Units
  • technical_consulting
  • access_rights

Users can have access rights to various items: units, groups of units, resources and accounts, routes, and other users. Depending on the available rights, the user can view and take some actions on a particular item.

Most often, full access to the unit (all rights) have only those users who configure it, while other users have limited rights sufficient to work with the unit. To avoid the incorrect changes of settings, it is important to assign to users only those rights that they really need.

Observed issue and the method of solving it

In everyday work, the rights to the unit are defined appropriately and do not change. However, there may be difficulties when changing rights, or sometimes rights can change without your participation, and the resulting settings may differ from what you expect. In this article, we'll consider standard issues of this kind. Choose one of the options below according to the situation you are experiencing.

1. After reducing the rights, the user still has more rights

A unit can belong to the group, towards which the user also has rights. In this case, the user will possess a wider list of rights of the two possible.

To correct the situation, try excluding the unit from the group or removing user rights to the group that the unit belongs to. After making these changes, set the desired rights towards the unit again.

A unit can belong to several groups at once, and in this case, it is recommended to check the user's rights towards all these groups. The list of groups that a unit belongs to is displayed on the Groups tab in the unit properties.

2. When removing all rights to a unit, an error is displayed and the changes are not applied

Most likely, this user is the creator of the unit. At the moment, it is impossible to remove from the creator all the rights to the item created by him or her. If you try to do this, an error will be displayed with the text "You cannot withdraw access rights from the creator of an object".

To correct the situation, you need to change the creator of this unit. To do this, you can transfer the unit to another account. The unit must be in the account of a user who directly uses this unit.

We’ve created a video on how to use the Switch account tool from the management interface (CMS):

3. When extending the rights, changes are not saved

Wialon uses the following hierarchy principle: it is impossible to give a user more rights to a certain item than the creator of this user has to the same item. If you extend the list of rights, but the changes are not saved, it may mean that the user's creator doesn't have enough rights to the unit.

To correct the situation, assign a wider list of rights towards the unit to users who are higher in the hierarchy. After that — to the user, who needed to extend the rights (that is, go through the entire branch of the account hierarchy from top to bottom).

You can check the service structure using the Service Hierarchy tool in the management interface (CMS).

4. Rights change even though you don't make changes

To change access rights to a unit, the user must have the Manage access to this object right towards that unit. Multiple users can have access to a unit simultaneously. Accordingly, several users can make changes. You can track changes using the Log, which you can view on the Messages tab or in a report using the same-name table.

To correct the situation, analyze the Log and disable the ability to change access rights for those users who should not do this.

5. Rights change even though no user is making changes

Most often, such changes may occur in a certain equal period or under certain conditions. In this case, the reason is the work of Jobs with the Change access to units type or Notifications with the action method Change access to units or Add or remove units from groups.

To correct the situation, check that jobs and notifications are configured correctly (if necessary, you can delete or stop them).

6. Rights change even though users, jobs and notifications don't do this

Wialon has the ability to change item settings (including changing rights) via API requests. Such requests are still executed on behalf of a specific user, at the same time, logging in and out of the system using an API request to some third-party application is logged. This information can be tracked in the user properties on the Log tab or in the management interface (CMS) on the Users tab in the Last visit column.

To correct the situation, analyze the operating logic of the third-party application. If the application uses a user token created specifically for working with a third-party application, then this user can change the list of rights and disable the Manage access to this object right, or change the flags of his or her token. If the application uses the token of the same user that is used to enter the monitoring interface, it is necessary to revise the application logic, getting rid of changing user rights towards units.

Changes to unit rights are logged in the Log (on the Messages tab or in a report using the same-name table). The Host column will contain the username if the changes were made manually or via an API request, or "job" or "notification" if the changes were made using this functionality.

Log entries can be deleted. In this case, information about changing rights will not be displayed. If you suspect that you’ve faced such a situation, please contact Wialon technical support via email support@gurtam.com.

Ekaterina Grib,Technical Consulting Engineer

10
  • 10
  • 25
  • 30
Thank you for your feedback!
Report a mistake
Text with the mistake Comment
Maximum 500 characters