There is a difference between “Driver change” and “Identification via iButton/RFID/Camera” rules. The first rule type is based on checking whether the hardware key field (the protocol field/data field) has been changed from the last time the platform received it. While the second rule is based on the hardware key change events that are carried in tracker data packets, meaning the alert will be triggered on every hardware key successful authorization event that is verified from the tracker side. This feature and driver lists are configured on the hardware (tracker) side. The platform waits, recognizes and indicates the event in the user interface in this case.
Description
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.
Settings
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.
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 "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.
Event reports
To view the dates when the events were received, you can build the "Report on all events" report.
