Wialon provides a wide range of features within its standard functionality, but some tasks can only be solved with non-obvious methods. For example, using dynamic groups, which we are going to discuss in this article. This method allows sorting units into groups, controlling a chain of conditions using notifications, finding units that have not met certain conditions, and so on.
General logic of dynamic groups
The logic of this method is based on the following system features:
- notifications can monitor not only specific units but also groups of units;
- notifications allow adding or removing units from groups.
By combining these features, non-obvious behavior can be achieved:
- If you set up a notification to monitor an empty group, the notification will be enabled, but will not trigger because there are no units in the group.
- If you add units to this group, even without changing the notification settings, it will automatically start monitoring the added units.
- If you remove units from the group, the notification will automatically stop monitoring them.
With dynamic groups, it is possible to create unique logical schemes. Let's take a closer look at some of them.
Sorting by groups
The simplest approach when using dynamic groups is to sort units by groups. For example, all the vehicles in a fleet can be divided into those that are moving and idling, free and busy ones, those that are on the perimeter of the facility and outside of it, and so on. After sorting, the resulting groups can be used in Reports or Jobs, as well as displayed on the Monitoring tab.
To sort by one condition A, the following elements and settings will be required:
- The Alpha group that contains units the condition A has not yet been met for.
- The Beta group that contains units the condition A has been met for.
- Notification 1 which is configured to monitor the Alpha group and control condition A. If this condition is met, the units will be removed from the Alpha group and added to the Beta group.
- Notification 2 which is configured to monitor the Beta group and control the condition opposite to condition A. If this condition is met, the units will be removed from the Beta group and added back to the Alpha group.
Schematically, this approach can be represented as follows:
Let's consider a few examples.
Example 1. Report on units outside the country
Let's assume that a client's company has dispatchers who need to divide the vehicles into two groups. One group should include those vehicles that are currently inside the country, and the other one is for those vehicles that are outside the country. Such a division is necessary in order to be able to request a report on each group at any time.
To solve this problem, it is first necessary to create a geofence that corresponds to the borders of the country, as well as 2 unit groups, which can be named Inside the country and Outside the country. Then it is necessary to manually add units to the corresponding groups based on their current location.
Next, it is necessary to set up the first notification called Departure, which will monitor the Inside the country group. It will control the presence of units outside the geofence. As the action, you should select the Add or remove units from groups action, namely to remove units from the Inside the country group and add them to the Outside the country group.
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
The second notification will be called Return and monitor the Outside the country group. It will control the presence of units inside the geofence. As the action, you should select the Add or remove units from groups action, namely to remove units from the Outside the country group and add them to the Inside the country group. As can be easily noticed, settings of the second notification are opposite to the first.
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
Now the units will dynamically move to the correct groups. Dispatchers will be able to execute a report on either the Inside the country or Outside the country group at any time, depending on their needs.
Example 2. Distribution of access through the groups
Let’s suppose that a client's request is similar to example 1, but additionally, it is necessary to ensure that a specific dispatcher has access only to those units that are currently outside the country. The solution from the previous example will be taken as a basis, and only the missing settings will be considered below.
There are two ways to approach this solution. On the one hand, you can configure the notification so that it not only moves units between the groups but also changes access to these units. On the other hand, you can provide access to the units through the groups. Only the latter method is described below.
First, it is necessary to make sure that the dispatcher does not have access rights regarding the given units. Then it is necessary to provide the dispatcher with access rights only to access a specific group of units (in this example it is the Outside the country group).
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
Now, when leaving the geofence and triggering the notification, the units will be added to the Outside the country group, so the dispatcher will be able to see them. When entering the geofence, the opposite situation will occur: the notification will remove those units from the Outside the country group, so the dispatcher will not see them.
Controlling multiple conditions in notifications
In Wialon, there are 20 types of notifications that allow you to automatically perform different actions when a selected condition is met. There can be multiple actions (for example, you can simultaneously display an online notification in a pop-up window and change the icon of the unit), while formally only one condition can be controlled by one notification.
However, in 8 types of notifications, in addition to the main condition, you can include several additional conditions.
Notification type | Additional conditions |
---|
Sensor value | Geofence | Speed | Driver absence |
---|
Speed | ✓ |
|
| ✓ |
Geofence | ✓ |
| ✓ |
|
Interposition of units | ✓ |
| ✓ |
|
Address | ✓ |
| ✓ |
|
Off time | ✓ | ✓ |
|
|
Connection loss |
| ✓ |
|
|
Fuel filling |
| ✓ |
|
|
Fuel drain |
| ✓ |
|
|
It turns out that not all types of notifications can simultaneously control multiple conditions. If a client needs to combine non-standard conditions, it is necessary to use dynamic groups. With this approach, for example, you can receive a notification fuel drain only while the vehicle is on the move.
To control two conditions — A and B, the following elements and settings will be required:
- The Alpha group which contains units for which condition A has not yet been met.
- The Beta group which contains units for which condition A has already been met.
- Notification 1 which is configured to monitor the Alpha group and control condition A. If this condition is met, the units will be removed from the Alpha group and added to the Beta group.
- Notification 2 which is configured to monitor the Beta group and control the condition opposite to condition A. If this condition is met, the units will be removed from the Beta group and added back to the Alpha group.
- Key notification 3 which is configured to monitor the Beta group and control condition B. If this condition is met, the notification will perform the final action (for example, notify the client by email).
Schematically, this approach can be represented as follows:
If it is necessary to control more conditions, the number of groups and notifications can be increased, for example:
Example 3. Controlling units outside specific area
Let’s suppose a manager wants to receive information about violations of the temperature regime of refrigerator trucks that have left the base.
To solve this problem, it is first necessary to create a geofence that corresponds to the base, as well as two unit groups, which can be named At the base and On departure. Next, it is necessary to create two notifications to sort units by the created groups. You can do it similarly as the solution in the example 1. Below, only the settings for the last notification will be shown.
For temperature control, another notification called Abnormal temperature will be needed, which will monitor the On departure group. As an action, this notification will send emails to the manager.
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
As a result, the units will dynamically move into the appropriate groups, and temperature control will only occur outside the base.
Controlling conditions taking time into account
By combining the approaches described above, various logical schemes can be created. Of all the possible use cases, several are highlighted that takes time into account. Let's consider their settings using some examples.
Example 4. Notification triggering once a day
Let’s suppose a client wants to receive an SMS about the first press of the panic button for all vehicles in the fleet during the working day.
To solve this task for one unit, it is necessary to set the value 1 in the Max triggers field, and then specify a time limitation for this parameter from 00:00 to 23:59. If there are not a lot of units, you can create one notification for each of them. However, if there are quite many units, dynamic groups will have to be used, and we will be discussing it further in this example.
Schematically, the solution to this problem can be represented as follows:
Consequently, the following elements and settings will be required:
- A group named No alarm (the Alpha group in the above diagram) which contains all units whose drivers have not pressed the panic button today. At midnight, all units should be in this group, so they need to be placed there initially.
- A group named Alarm triggered (the Beta group in the diagram) which contains units whose drivers pressed the panic button today. This group should be empty at midnight.
A notification named Alarm! (notification 1 in the diagram) which is set to monitor the No alarm group and control the panic button press. If this condition is met, these units will be removed from the No alarm group and added to the Alarm triggered group, and the notification will send an SMS to the client.
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
A notification named Back to initial settings (notification 2 in the diagram) in this case will return all units from the Alarm triggered group to the No alarm group closer to midnight. For this, it must be set to monitor the Alarm triggered group, have a time limitation (for example, from 20:00 to 23:59), and control some conditions that will undoubtedly be met for all the units at the end of the working day. One such condition may be a speed of less than 300 km/h (in this case, the notification should trigger For all messages).
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
Now, all the units whose drivers pressed the panic button will move to the Alarm triggered group at the first trigger. The control of triggering the panic button is no longer carried out for this group. Consequently, the client will only receive an SMS about the first alarm for each unit. In the evening, all units will be returned to the initial group.
Example 5. Report on the units that have not started moving by a certain moment
Let’s assume an owner of a fleet wants to receive a daily list of vehicles that have not started moving by 8 am.
Schematically, the solution to this problem can be represented as follows:
Consequently, the following elements and settings will be required:
- A group named Did not start working before 8 am (the Alpha group in the above diagram) which will contain all units that have not yet started moving. It is assumed that at midnight, all units in the fleet should be in this group, so they need to be initially placed there.
- A group named Started working before 8 am (the Beta group in the diagram) which contains units that have already started moving. At midnight, this group should be empty.
A notification named Managed to start before 8 am (notification 1 in the diagram) which is set to monitor the Did not start working before 8 am group and control the appearance of speed (meaning, the start of work). If this condition is met, the units will be removed from the Did not start working before 8 am group and added to the Started working before 8 am group. Also, the time limitation of this notification should be set from 00:00 to 07:59.
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
A job named Latecomers list, which at 08:00 will send a report to the owner of the fleet about the units from the Did not start working before 8 am group. The group report may contain, for example, the Unit latest data table.
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
- A notification named Back to initial settings (notification 2 in the diagram) in this case will return all the units from the Started working before 8 am group to the Did not start working before 8 am group closer to midnight. This is done by analogy with the similarly named notification from example 4 above.
Now, all the units that have not started moving by 08:00 will remain in the Did not start working before 8 am group, and then the job will send a report about them to the owner of the fleet. If any unit starts moving before 8 am, it will be moved to the Started working before 8 am group, so it will not be included in the report about violations. In the evening, all the units will be returned to the initial group.
Example 6. Controlling long-term conditions (more than a day)
Let’s suppose a manager needs to receive an email if a unit stays in the factory area for more than 3 days (72 hours).
Usually, the duration of the controlled alarm state (in this case, being in a geofence) is set through the Min duration of alarm state field on the last page of the notification settings. The maximum value for this field is 24 hours (1440 minutes, 86400 seconds). In other words, it is not possible to control an alarm state lasting 72 hours without using dynamic groups.
Schematically, the solution to this problem can be represented as follows:
Consequently, the following elements and settings will be required:
- A geofence that corresponds to the factory area.
- A group named Inside <24 hours or outside (the Alpha group in the above diagram), which initially contains all units.
- A group named Inside >24 hours (the Beta group in the diagram) which will contain units that are inside the geofence for 24 hours or more.
- A group named Inside >48 hours (the Gamma group in the diagram) which will contain units that are inside the geofence for 48 hours or more.
A notification named Entry for 1 day (notification 1 in the diagram), which is configured to monitor the Inside <24 hours or outside group and control a unit being inside the geofence for more than 24 hours. If this condition is met, the units will be removed from the Inside <24 hours or outside group and added to the Inside >24 hours group. The notification should trigger Only when the state changed, and the Min duration of alarm state should be equal to 24 hours (1440 minutes, 86400 seconds).
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
A notification named Entry for 2 days (notification 2 in the diagram) which is configured to monitor the Inside >24 hours group and control a unit being inside the geofence for more than 48 hours. If this condition is met, the units will be removed from the Inside >24 hours group and added to the Inside >48 hours group. The notification should trigger For all messages, and the Min duration of alarm state should be equal to 24 hours (1440 minutes, 86400 seconds).
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
A notification named Back to initial settings (notification 3 in the diagram) will return all the units from the Inside >24 hours and Inside >48 hours groups to the Inside <24 hours or outside group if a unit leaves the geofence. The notification should trigger Only when the state changed.
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
A notification named Entry for 3 days (notification 4 in the diagram) which is configured to monitor the Inside >48 hours group and control a unit being inside the geofence for more than 72 hours. If this condition is met, the units will be removed from the Inside >48 hours group and added to the Inside <24 hours or outside group and an email will be sent to the manager. The notification should trigger For all messages, and the Min duration of alarm state should be set to 24 hours (1440 minutes, 86400 seconds).
There are no pictures in the gallery
Problem loading this gallery!
Source page for this gallery is either deleted or does not exist
Now, all the units that have been inside the geofence for one day will move from the Inside <24 hours or outside group to the Inside >24 hours group after one day, they will move to the Inside >48 hours group after another day, and after one more day, the notification will send an email to the manager and move the units back to the initial group. If at any point the units leave the geofence, they will return to the original Inside <24 hours or outside group.
Oleg Zharkovsky,Customer Service Engineer
2023-11-26