Common pitfalls with GpsGate Scripting

If you've already read Script Expressions and started scripting but got stuck, this article should help.

---

1. What states do I want in my state machine?
2. How do I move between these states?
3. What should happen when moving between the states?
4. Have I written the above state diagram that solves my business case?
5. Have I updated all plugins?

Start coding if “yes”!

There is only one screen dump in this blog, see below. All the numbers you’ll find here, are found in that screen dump.

Testing your script with real data

Your “Exposed objects and test values” on your right, see “4” below, will be automatically updated when clicking on a user and its track points, see “2” below, with some exceptions described further down. Documentation is found in “1” by clicking on the respective object.

Change state

Test what happens when moving between different states. You can create suitable test data triggering these moves with the asset simulator to speed up the work. But remember that not all objects, in the test environment, are updated when clicking on a user and its track points, e.g. the session objects: user, asset, and driver. Those objects will always include the latest data sent to the server. At least you can be sure that what you have under “Exposed objects and test values”, (see “4”), is the input to your script.

Recreate the problem

Please export the event rule and relevant track points, matching your screen dumps, as well as a screen dump of the mapped variables in your device mapper, so that we can easily recreate the issue, in case we suspect a bug in our platform.

Managing state

When working with states, make sure to initialize them correctly. Here’s one example taken from another article.

Use the context.state text box to monitor the state while testing, (see “4” in screen dump). Make sure to empty this text box when testing the initialization.
Keep in mind that the script is run once for each track point.

Report arguments

• When working with the EV1000 Event Rule, you can use Report Arguments to dynamically populate values in the Event Rule Report. Here's how it works step-by-step:

  1. Setting Variables in the Event Rule:

  • Use context.setVariable("Variable1", value); within the Event Rule logic.
  • This assigns a value to a variable (Variable1) that can later be referenced in the report.

  2. Using Report Arguments in Notifications:

  • In the Notifications section of the Event Rule, select the type Report Argument.
  • For each Report Argument, you define:
    • A Header Name (e.g., Header Name) that describes what the value represents.
    • A Value (e.g., Variable1) that maps to the variable you set earlier using context.setVariable.

  3. Behavior in the Event Rule Report:

  • When the Event Rule transitions from true to false, it triggers the creation of a new row in the Event Rule Report.
  • The Report Arguments you defined are mapped to specific fields in the report:
    • The first Report Argument in your list will populate the [EventArgument] column.
    • The second Report Argument will populate [EventArgument01].
    • The third Report Argument will populate [EventArgument02], and so on.

  4. Key Details to Remember:

  • The variables you define (e.g., Variable1) must have their values set before the Event Rule transitions to false. Otherwise, the corresponding Event Argument fields will be empty.
  • This mechanism allows for flexible and dynamic reporting, as you can use custom variable values in your Event Rule Report.

We’re constantly building on our scripting capabilities. Therefore, please let us know if you would like to have a new feature. Be sure to explain how it would help your customers be more profitable.
Should you see unexpected behaviour of our platform, please state how the behaviour doesn’t match our documentation, (see “1”) and send one or several screen dumps to support@gpsgate.com including:

1. The problematic track point highlighted, (see “2”) and its data found in “Exposed objects and test values”, (see “4”).
2. The test output of the script, (see “3”)
3. The context. state text box if states are used, (see “4”).
4. Explanation of what you actually expected and why, see template below.

One way to explain your unexpected behaviour is this:

Hi David,
According to the documentation, the object context.state is supposed to “store data between evaluations” (see “1”).

Now, for the track point of X (see “2”), state.DriverOrVehicle returns “undefined” (see “3”), despite of what we see in the text box for the context.state,(see “4”), and despite of [...] shown in my other screen dumps (see “XY”).

I don’t see how the test output (see “3”) makes sense in my particular case. What more should I look at to make sure that everything is working as it should, and that the unexpected behaviour is not from the server, but from the script or even from the state diagram?

See attached screen dumps, relevant exported track data, state diagram and event rule.
Best Regards,
Script Developer

We can answer direct questions related to the features in GpsGate, but that does not mean we will develop a script for you, or troubleshoot complex customization you might have created. Only provide solutions to your customers that you understand and can control. We can also connect you to a GpsGate Solution Provider who might be able to help you with your customization needs, including scripting.