The first thing to do when configuring an Action is to define which action you want it to take. Each type of action is described in the section below. Currently, we offer 9 options.

1. Push Notification

This action can notify you on your account via browser or via the mobile app. You can set the title and the content of the notification.

The notification is only sent to the account where it was created. 

If you need to notify different accounts, check our documentation on notification using analysis. If you want to send a notification to a RunUser, see the next option.

2. Push Notifications to Run Users

This action can notify a Run User that belongs to your Run.

The structure is the same as the option above, with the exception that in this option you must specify which RunUser you want to send the notification to.

3. Send Email

An e-mail will be sent when a condition is met. To create this action you must set the type as Send Email, enter the email recipients, and a subject.

You can set multiple recipients in the Send to field by separating them with a ;

You can use variables of the payload that triggered your action inside of the title and message. To understand more, check the end of this article.

To avoid sending e-mails continuously when a trigger condition is met, you may want to define a reset trigger condition. Check Trigger Unlock to avoid issues with your logic and even your account.

E-mails can also be sent directly from scripts in the Analysis. For such action, you can use the e-mail service. Check the terms of use, and your plan before using the e-mail service.

TagoIO has the capability to handle a high rate of emails per certain period of time. However, to scale it up smoothly and protect your account, notify us in advance in case you need to send more than 50,000 / day.

4. Send SMS

An SMS will be sent when a condition is met. To create this action, select Send SMS and enter the recipient's phone numbers. 

Don`'t forget to use the country code on each phone number. If there is no country code, the system will assume the USA code (+1).

You can set multiple phone numbers in the field by separating them with a ;

You can use variables of the payload that triggered your action inside of the title and message. To understand more, check the end of this article.

To prevent the system from sending multiple SMS continuously when a trigger condition is met, you can define a reset trigger condition. Check Trigger unlocks to avoid issues with your logic and even with your account (high number of SMS, for example).

SMS can also be sent directly from scripts in the Analysis. For such action, you can use the SMS service.

Some costs may occur when using the SMS service, which varies based on the country of operation. Check the pricing, terms of use, and your plan before using the SMS service.

5. Run Analysis Script

Actions have the power to initiate scripts that run in the Analysis. This is a very powerful feature, as you can define exactly when your code will run.

Learn more about Running Analysis via Action.

6. Publish to MQTT

This action can publish to an MQTT topic defined by the developer. This means that every time your trigger criteria are met, TagoIO will publish data to that predefined MQTT topic, this is very useful if you need to forward data to devices and/or applications. 

7. Post data to HTTP End-Point

This action can post data directly to an endpoint defined by you. When the action is initiated, it will POST the JSON data received (as defined by the variable in the Trigger) to the configured HTTP endpoint address. 

You can use payload fields in the HTTP endpoint, like the example above but with a variable (https://myapi.io/endpoint/$VALUE$), or even in the HTTP Headers like in the example below:

In the Message Variables section in this article, you can see all variables available.

The TagoIO-Retries header is managed by the TagoIO API and sent in every Post request for this Action type, and indicates the number of attempts to post the data to your endpoint.

It will try to post the data 10 times, and if it’s unsuccessful (any response from your endpoint other than HTTP 20X status codes) it will require a fallback device to be configured to store the data in TagoIO so you can retrieve it later without losing your data in case your endpoint fails to receive it.

To set up a fallback device, enable it in the bottom part of the HTTP Post action settings and put the token for the device you intend to hold the data.

After 10 unsuccessful attempts, the data will be sent to the fallback device with some information added to the metadata in the _http_* properties (original values in metadata will be kept), like shown below:

8. Insert to Device's data storage

This option is only available if your Action is of the type MQTT Topic.  This action will insert the data directly into the device's data storage.

9. Insert data Into TagoCore

This option is only available if your Action is of the type Trigger by Variable.  This action will insert the data directly into a TagoCore's device, which is specified by the device token.

---

10. Message Variables

In some action types, the message body can be as simple as a text like Hi, your car is over the speed limit or you can specify fields in the message to personalize it with real-time data from your  devices.

You can use most of the payload fields from our API:

For example, a personalized message like this

• Hi, your device reached $VALUE$ $UNIT$ at the coordinates $LOCATION$ at $TIME$.

This would result in the message being:

• Hi, your device reached 73 mph at the coordinates 43.05334,-86.45340. 

And a message like this

• $TIME$: Warning, device with ID $DEVICE$ is $VARIABLE$° $UNIT$.

Would result in the following message:

• 2021-01-02T22:51:48.005Z: Warning, device with ID 547e353d7dbf3af122c0257d is 90° F.