Description
This rule provides information about the loss of the tracker's connection with the platform. Loss of connection can occur due to tracker shutdown for hardware reasons (battery discharge, disconnection from the only power source, hardware failure, wiring problems, and similar reasons) or due to the loss of connection to the GSM (GPRS) channel, i.e., lack of connection to the SIM card internet service (poor coverage, insufficient funds, outages on the provider side).
Note that different models of trackers have different protocols, even within the same manufacturer, or even within different firmware versions or hardware solutions. This directly affects how the rule works. Each tracker protocol has its own connection timeout on the transport layer context. After that, the countdown of 10 minutes starts if this protocol does not have the property of explicitly indicating the "alive" status of the connection (keep-alive protocols).
Simply put, users can count approximately for each tracker model as 10 minutes of connection outage. After these 10 minutes, the tracker will go into red status, and you will be notified in the UI, by email, or SMS - depending on how you configure the rule in the notification section. The rule itself is very simple to configure but very useful.
For a business context, the rule allows you to stay alert for events of loss of tracker connection to the platform. This rule can also be used to cover other rules or even replace some events that are not available for a particular model. For example, you can combine several types of rules: GSM jamming + this rule. Thus, even if the device does not send a jamming notification for some reason, users can still learn about the termination of data transmission to the platform through this rule, which allows users to quickly respond to emergency situations related to GSM jamming, whether it is jamming by a driver, in case of carjacking or theft of vehicles, or when the tracker is physically disconnected in such situations.
Additionally, this rule allows users to collect statistics on places with poor coverage, identify faults on the equipment or provider side, which will optimize processes in business scenarios and reduce risks. Furthermore, this rule allows building a report on loss of connectivity events, where it is possible to analyze over a longer period, allowing taking a more global view of the situation.
Please note, the tracker switch-off or lost connection notifications do not always mean the tracker is hardwarely switched off. That means the platform does not know the exact reason, but the connection is certainly lost with the platform.
There is a difference between the "Tracker switch ON/OFF," "Tracker switched ON," and "Tracker switched OFF or lost connection" rules.
- "Tracker switch ON/OFF" encompasses the core essence of two hardware events that are tracked and provided to the platform. It is based on the hardware logic of paired ON or OFF events triggered by pressing the ON/OFF button.
- "Tracker switched ON" is a separate rule that captures events only when the device is turned on. It does not provide information about turning off.
- "Tracker switched OFF or lost connection" (currently reviewed rule) is a rule where the event is generated on the platform side. The tracker is either turned off or has lost connection with the platform for an unspecified reason, whether it's an unexpected or anticipated scenario. Usually, this event is associated with a connection timeout and, as a result, a red status of the tracker.
Settings
Offline time more than:
The parameter defines a timer that starts a countdown after the tracker gets the red status. That means the whole period of the tracker disconnection is calculated like this:
10 minutes for the default timeout + the value from the "Offline time more than" field = the resulting time period after which you get this rule notification. For example, if you specify the option as 7 minutes, the scenario will be as follows:
- Let's say the tracker lost its battery charge or internet connection at 10:10 AM.
- After the default timeout of 10 minutes, the tracker becomes red status at 10:20 AM. The custom countdown starts.
- At 10:27 AM, the user receives notification.
Bind zone to rule:
Enables geofence rule binding.
Geofence:
Fill out the section if the rule needs to work only inside/outside of the selected geofences.
Map button:
Shows bound geofences on the map.
Notifications
Emergency notification:
is used for important events. A message on the screen and the sound signal can only be disabled by clicking on the notification. Please note, some browsers can block notification sound until user activity is recorded on the page.
Push notifications:
Receive push notifications on the mobile app and web interface.
Add geofence name to the notification:
Adds names of the specified geofences to the notification text. This option is available only when the "Inside" geofence binding radio button is selected on the "Settings" tab.
SMS notifications:
List of recipients for SMS notifications when the event occurs.
Email notifications:
List of recipients for email notifications when the event occurs.
Schedule
Set a schedule for when the rule will run. If your schedule indicates that the event should not run some day or time period, it will not appear as a notification in the user interface, and notifications via SMS or email will not be sent. Additionally, you can choose a default template for quick scheduling.
The platform specifics:
- The "Tracker switched OFF or lost connection" alert has a 10-second reset timer, meaning the alert event will not occur more often than once every 10 seconds. If this type of event occurs in time the rule has been waiting for the reset, this event will be omitted by the platform, including the reports.
- This rule is a generic type and is not specific to any particular hardware, which means it can be applied to multiple trackers simultaneously. This allows for the selection of several trackers within a single rule.
Note, since different trackers have different transport-level timeouts, if you include multiple trackers of different models in the same rule, you will have a different period for notifications if they would have occurred at the same second for these models regardless of the fact you have only one parameter for offline period in the rule configuration. This comes from the fact that the notification formula is Tracker's timeout (~10 minutes) + Your custom offline timeout (in the rule) = The resulting timer countdown period before notification.
Event reports
To view the dates when the events were received, you can build the "Report on all events" report.
