Triggers and Actions

With the Gateway and the Location Engine, there is a new very exciting feature available in the Web Panel called 'Triggers'.

When a Gateway detects or loses sight of a particular beacon, it will send the event back to the Location Engine, which will then trigger a given action.

Creating a new trigger

To create a new trigger, go to the Triggers menu and click on the 'Add trigger' button.

First give your trigger a name that helps you identify what the trigger is for.

Then select the type of trigger you want to create. Currently there are two types of triggers available:

Beacon detected means that the specified beacon was first discovered by the Gateway in the chosen proximity. 

Beacon lost is triggered for the first time when beacon matching the description of the trigger was observed before and is not observed in the cool down time window (30 seconds). It also takes into account the throttle time.
(Throttle = Minimal number of seconds between two subsequent firings of the new Trigger).

For the executor there are three available options: Cloud, Gateway or Proximity SDK. 

  • If Cloud is selected, then the Location engine will be the one in charge of triggering the action, as soon as the Location engine receives the data matching the trigger description.
  • If Gateway is selected then the Gateway will be the one to execute the trigger within the Local network, once it has detected/lost the selected beacon.
  • Finally, if Proximity SDK is selected, then the mobile app built with the Proximity SDK will be in charge of executing the trigger, when the app detects the specified beacon. To learn more about the Proximity SDK, please visit this blog post.


Next comes the TrackingId, this refers to the unique identifier of the beacon that will trigger the action. All beacons have a sticker with their unique identifier. When you start typing, you will see a list of available beacons with ids that match what you are typing. Select the beacon you would like to use.


Then comes proximity. You can select one from three proximity values or unknown:

'Source Id' is used to identify which Gateway will be in charge of monitoring for the specific beacon. Please visit our tutorial to learn how to setup your Gateway.

The alternative to the above mentioned would be to use the device profile to create your trigger, you can select either iBeacon or Eddystone.


Once your trigger is ready, save it. You can always edit it later if needed. Once saved this is what you will see:

NOTE After creation, the 'Test trigger' button will be disabled. It is necessary to wait a few minutes for the trigger to update in order to be able to test it.

Create an Action

Now that we have our trigger ready, we need to create an action for it. In this example, we will create an action that posts a message to our slack group when a Kontakter enters the office using 'If This Then That" (IFTTT).

Click on the 'Assign Actions tab' and then the 'Add an action' button.

First we have to give our action a name and choose the action type. Currently 'Send HTTP request' is the only action type available.

For the context of the action, we prepared an IFTTT Applet that sends a web request to the Maker Webhooks when the beacon is detected by the Gateway and then posts a message to Slack. Click here to learn how to building applets. When connecting to Maker Webhooks, under settings you will get your Key. 


Under documentation, you will get the URL you will need to copy and paste on the URL section of the context of your action.


Please note that the final URL you need to paste on the Panel, should include the name of your event and your Maker API key. In the example below, the event name is "beacondiscovered" and the API key is: cbfe0V8A10zXy4mvQMqZ0X.

Screenshot_2017-08-24_16.30.10.png Screenshot_2017-08-24_16.30.48.png

There are some additional parameters that you can pass to your request, as described in the following image:

Parameter values in the HTTP request action can be filled with static data, but they also accept three placeholders:

  • {{trackingId}}
  • {{sourceId}}
  • {{proximity}}
  • {{proximityUuid}}
  • {{major}}
  • {{minor}}
  • {{namespace}}
  • {{instanceId}}

These placeholder values are dynamically replaced in the HTTP requests with actual values for a Tracking ID, Source ID or a Trigger Proximity from a Trigger that has set off this Action.

We are passing three parameters to our applet, the trackingId which translates into the 'Unique Id' of the detected beacon, the sourceId which identifies the Gateway that discovered the beacon and then the proximity which indicates how close the beacon needs to be of the Gateway in order to trigger the action.

The Key for each parameter comes from the ingredients available in the IFTTT applet.


To test our newly created action all we need to do is wait for our Gateway to detect our beacon. Once the beacon is detected by the Gateway, the action will be triggered and the message will be posted to Slack.

We first tested our applet using curl, keeping our Gateway off, which is why there is no beacon or Gateway values. Once we were sure that the applet was working correctly, the Gateway was plugged to a power source, then beacons 'yMsz' & 'INK5' were detected and the http request was sent to Maker in order to post the message to Slack.

This is just a simple example, there are many different options available when using IFTTT. 

NOTE More parameters will be made available for the actions as development continues.

Visit our article to learn more about the Location Engine (beta).

- 2017-10-10 17:20:09 UTC
Was this article helpful?
2 out of 2 found this helpful



This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Review our cookies information for more details.