Depending on the tracker model, driver identification can be verified directly by the tracker, without involving the platform in the authorization process. The list of drivers is typically stored in the tracker's configurations and tables, and each time a driver authorizes themselves (e.g., by using iButton/RFID keys or face recognition via a smart camera), the tracker verifies their identity. The rule allows capturing these events, displaying them as Alerts in the user interface, generating reports, and notifying the user whenever such events occur. This feature enables users to leverage the tracker's unique functionality for identification, offering flexibility to choose between standard identification methods and configurable hardware verification methods.
This is particularly helpful in scenarios where multiple drivers share one vehicle, and the organization needs to monitor driving activities, such as when, for how long, and other related parameters a driver was operating the vehicle. Another use case arises when a tracker is configured to enable engine ignition only upon a successful driver identification event. In this scenario, platform users can receive notifications for these specific events, ensuring they stay informed about every authorized engine ON state. Additionally, some trackers support camera identification, making the authorization process more modern and convenient for drivers, especially in high-stress environments where minimal distraction during vehicle entry is essential.
As this rule is based on hardware configuration, there is not much to configure in the rule itself.
Bind zone to rule:
Enables geofence rule binding.
Fill out the section if the rule needs to work only inside/outside of the selected geofences.
Shows bound geofences on the map.
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.
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.
List of recipients for SMS notifications when the event occurs.
List of recipients for email notifications when the event occurs.
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 "Identification via RFID/iButton/Camera" alert has a 5-second reset timer, meaning the alert event will not occur more often than once every 5 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.
- In this rule type, users have the flexibility to select multiple trackers which they wish to receive notifications from. The only requirement is that the selected trackers must support Identification via RFID/iButton/Camera events and the feature must be integrated on the platform for given trackers. This means that users can choose multiple compatible trackers to receive notifications from, allowing them to monitor harsh driving events across various vehicles or devices in a convenient way.
- Whenever the platform identifies a hardware event of this type from a packet of tracker data with no valid coordinates in it, the platform counts the event as a valid one and displays it regardless of whether the event occurred within or outside the bound geofences. The logic of the Inside/Outside radio buttons is also ignored in this case. This behaviour is due to the fact that showing a controversial event once more is better than omitting it.
To view the dates when the events were received, you can build the "Report on all events" report.