Events, Triggers & Notification
An Event is a programmed response to some action, responding to things happening is a powerful feature of our system, from being notified, to controlling the object through GRPS/SMS commands, many options are supported and more on the way! You likely do not want to be notified about every action your object performs, so, this event trigger system allows you to define precisely the actions you care about, and send notifications only for those actions.
- You define an Event Trigger Definition
- Your device meets the conditions/filters/rules of the Trigger, and the system generates an Event.
- If the Definition is configured to send one, or your App is subscribed to the Trigger, the system sends any Notifications.
So yes, your app can subscribe to any active event trigger on your account, even if all other notification types are disabled.
Note: If you use the Trigger Definition to filter the Event from being created, you will receive no Event or Notification!
Without a notification, all events are still visible. So we encourage you to have as many event triggers as you like, generating as many events as you please, however the notifications themselves should not be over-done. We wouldn't want you to ignore them! [alert-fatigue is real]
How to configure an Event Trigger Definition
Navigate to the "Events" tab on the main page, and select "Add Trigger", as Events are created by things happening to objects, those particulars need to be set. You define the Name, the Type and the parameters first. An Event is created only if the state changes to these conditions. (This means, creating an overspeed trigger will not continually fire for a tracker travelling too fast, it will fire once when the speed is first seen above the filter).
Event config window:
Give your event a Name, this will be used in alerts, emails and other templates.
Set the type of action that should trigger this event. Many are dependant on the type of device you have, it's available sensors/inputs, and may or may not work depending on that. Basic ones like "geofencing" should work fine by using the Zone In and Zone Out actions. You then need to pick the objects this trigger should fire for. (We encourage you to select All of your objects per Trigger, rather than creating a Trigger per object/rule).
- If your event is route specific (route must be defined before trigger created), you can select it here. (For example if you are only interested in Speeding when driving a specific Route etc, the condition of the Trigger outside the selected Route will not create an Event at all. It is important to understand that the filters are designed to prevent excessive Events from being generated).
- If your event is zone specific, you can select it here, and specify it's requirement. However it can be used to filter any other Event Type, eg: I am only interested in overspeeding inside Victoria, send an alert to [email protected], then you can define different events for each region, apply it to all of your objects etc.
- The time period filter ensures that conditions must be set for an amount of time. For example, only create an Event when the "Stopped" condition is set for more than 10 minutes.
- Parameters and Sensors: This is used to customize the Parameters and Sensors - Event Types. For example, if you want to know when your vehicle is turned on, you could create a Sensor Type Event Trigger, and specify the Source as "Ignition" and then select the value "= 1" This will create an Event when the tracker transitions from anything else to 1. (Eg: The car turns on). You can add a few sensors at once combined into patters, for example: When the vehicle is moving > kmph and the ignition = 0, that would mean the car is being towed or is inside a truck being stolen etc. You can only select the sensors when you have changed the Type to Sensor, and the parameters when the type is set to Parameter. (Parameters are essentially raw Sensors, we encourage you to use the Sensors instead).
Other Event types:
- Low Battery - Most should use a Sensor instead, this Type is not supported on all hardware.
- Connection: Yes - This fires an Event when the hardware changes from having no Mobile signal to having a mobile signal.
- Connection: No - The opposite of "Connection: Yes".
- GPS: Yes - This fires an Event when the hardware changes from having no GPS signal to having a GPS signal.
- GPS: No - The opposite of "GPS: Yes".
- Stopped - This fires when the vehicle changes to the state "stopped". Eg, it is no longer Moving.
- Moving - Fire an Event when a tracker changes from not-moving to moving.
- Engine Idle - Fires an Event when the tracker changes state to "idle", eg, the engine is on, but it isn't moving.
- Overspeed - Fires an event when the tracker reports it's velocity has changed to be higher than the entered "Speed limit" in kmph. .Reset's when the speed is reported to be lower than that.
- Underspeed - Basically the opposite of Overspeed. Think the movie "Speed"
- Harsh Acceleration - Not all hardware supports this, we recommend using a Sensor and specifying the Sensor "Driver Behaviour" instead. If your hardware does not support this sensor, you will not be able to make this Trigger.
- Harsh braking - Not all hardware supports this, we recommend using a Sensor and specifying the Sensor "Driver Behaviour" instead. If your hardware does not support this sensor, you will not be able to make this Trigger.
- Harsh Cornering - Not all hardware supports this, we recommend using a Sensor and specifying the Sensor "Driver Behaviour" instead. If your hardware does not support this sensor, you will not be able to make this Trigger.
- Parameter - Trigger an event based on the raw parameters received from the hardware. Requires in-depth knowledge of the parameters values, meanings and magnitudes. You can read the current parameters from the Info tab of an Object, or in the History. It is recommended to use a Sensor instead of a raw Parameter. The actual parameters that the device sends are dependant on the hardware and it's configuration.
- Sensor - The premier Event Type, this allows you to construct a custom trigger based on many simultaneous parameters, depending on the hardware you have. Refer to the Sensors tab of your object to see the sensors and how they are defined. We recommend installing the Gator Defaults. You can always delete your sensors and reload the Gator defaults if you wish to reset them.
- Service - Subscribers can access Service Events, which are configured via the Service properties of Object Editing.
- Route In - Fires an Event when a tracker enters a defined Route. You must define the Route first, a bit like a Zone In trigger, but for a Route, instead of a Zone.
- Route Out - Fires an Event when a tracker leaves a defined Route.
- Zone In - Fires an Event when a Tracker enters a Defined Zone.
You must define the Zone first. If you create this trigger in the App then it will guide you through this process.
- Zone Out - Fires an Event when a Tracker leaves a Defined Zone.
This is commonly referred to as "Geofencing", you define a Fence (Zone)
and when the Tracker departs the fence (Zone) we call that a
"Zone Out" condition, and this Trigger would generate an Event for that condition.
You must define the Zone first. If you create this trigger in the App then it will guide you through this process.
Allows you to filter events from being created too often, for example if you drive to work and back every weekday on the same times, you can program those in, so only aberrant behaviour triggers the event.
It is advisable to use the duration filter, but not the day or time filters. If you have any issues generating Events with these filters, please remove them before contacting support.
- Duration from last event in minutes: - Ensures that even repeatedly recurring actions don't create too many events. A basic "only once every" type filter. Pretty handy for low-velocity over-speed rules, if you have an overspeed rule set to 50kmph, and drive through a city, you would generate a lot of Events.
- Week days: The Trigger is only active on the selected days. This is localised to your (the logged in users) timezone.
- Day Time: An extension of the week-days concept, the rule is only active during the selected localised times.
You want to know about this Event? Hey, nice. We can send you a notification!
Note: App notifications are enabled for All triggers and cannot be disabled without disabling the trigger itself. You can choose in the app which events you want to be notified about.
By default, we recommend using System Message to test your event in the browser, as email and sms are limited resources (costing us money, and are therefore restricted).
We highly recommend using in-app notifications, which are unlimited and can be customised per device.
We do not limit system or in-app messages, however be advised, system messages are only visible while
you are logged into the web interface, and if you accept the "show notifications" prompt, you don't need to
be actually looking
at the tab to see the alert after that though. So that's nice.
Emails are great, and while non-free, are relatively plentiful for subscribers (24 per day per subscription, grouped for the whole account, not per object).
SMS's are a lot more restricted, you can get 1 per day for free, and 12 per day per subscription grouped across all subscriptions, up to a monthly limit of 150/month/subscription. This is to prevent cost overruns and abuse. (You can configure it to send an SMS with whatever text you like to whatever number you like, so we can't have it send infinite texts).
Note: If your email/SMS allocation is consumed, you will not receive any more notifications via that method until the day resets. We advise you to not use SMS notifications for trivial events.
- System Message -
- Auto hide - Automatically closes a System Message in-browser after a short amount of time. Prevents the screen filling up.
- Sound Alert - Plays the selected audio alert in-browser when showing the System Message.
- Message to Email - Generates an Email Message to the entered recipients, uses the Email template (has no effect if it is not ticked)
- SMS to mobile - Generates an SMS Message to the entered recipients, uses the SMS template (Note, if your message is too long and requires more than two SMS messages to be sent it might be truncated, SMS quota's are counted by the amount required to send the message, not the number of Messages themselves.). Entering a number is not enough, the checkbox must be ticked to receive this.
- Email Template - Select from your previously created Email Templates to format the Email message. (has no effect if Email is not ticked)
- SMS Template - Select from your previously created SMS Templates to format the SMS message. (has no effect if SMS is not ticked)
- Object arrow color - changes the Arrow used on the map when this Event is created.
- Changes the color of the object in the Objects list when this Event is created.
This is a great feature, all users have unlimited GPRS commands, so you can send the command that immobilizes your object an unlimited number of times per day etc. If it exits your defined area of operations, that would make it easier to recover the vehicle automatically. You know where it is, and as soon as it slows down, it will stop altogether.
SMS commands, which require the SIM number to be programmed are limited with the same SMS group used for notifications, so are generally unacceptable for this purpose. Note: Subscribed devices with an M2M SIM cannot be controlled via SMS, so ensure you use GPRS for those!.
The commands are the same ones available in "Object Control" -> Templates, which you can include automatically with the drop-down menu (under the gear icon on that page) by selecting "Load Gator Defaults", we check your object list IMEI's against our database of makes and load the templates for each model you have. Those commands can be used in object control event actions!