General information of how triggers work & best practices for use

[leo]

The following post serves as general information about Pegasus triggers (or Automation) module.

Triggers are used primarily for advanced alerts that consists of multiple conditions and they can have multiple actions.
Triggers work based ONLY on a vehicle’s reported events.

This means i can’t set up a trigger to fire at a specific time (let me know at 5am if the vehicle’s still inside the fence), unless the vehicle reports at that time.

In other words triggers only fire when a vehicle’s device sends an event that meets the trigger’s conditions.

The way you could make this example work is if the device’s configuration is set up to report every 1 hour while the ignition is OFF for example, and you set up a trigger to fire at a specific schedule – as long as it meets the condition of time-window 5-6AM and a GPS Event, that’s the only things you need to fire the trigger.

 

There are some caveats and things to consider however:

Since triggers work based on a reported event, if that event never comes in for some reason:

• Network failure (loss of connectivity, or not enough data in the sim, or the vehicle is in an area with no cell network coverage)
• Hardware failure (loss of power causing the device to turn off)
• Software (the device is programmed to go into sleep mode)
• Other (sabotage)

the event would not come in on time and the trigger would not be fired (at least until it comes back online).

Although most of the cases described above are not common they could occur and it should be accounted for in any solution.

The good news is Syrus is flexible enough to be programmed locally for practically any situation, in other words you could program in the script configuration of the device these same conditions so that it does not have to depend on the event reaching the server on time.

This example using the Syrus script would work using the Time Window command, which sets a flag internally on the device to trigger whenever the device reaches a particular hour, and a Circular or Polygon Region command

Having the configuration locally on the device means you would not have to worry about the trigger’s actions not executing on time because the event did not reach the server, everything would work normally as expected on the hardware level and all the actions would occur locally whether the device is ONLINE or OFFLINE.

A few more things to note, triggers work based on the GPS time of the event received, so in the example where the device goes offline and it’s due to a network failure (let’s say it ran out of data yesterday) the device has a buffer which will store its events internally, until the device comes back online. Once the device comes back online, you could receive a barrage of events that all come in at the same time, and it means you would get alerts fired today that could’ve been generated yesterday when the device went offline.

• This topic was modified 5 years, 2 months ago by leo.

[Author]

Posts