This version sees the release of “Action Triggers” for Conctr. With action
triggers you can perform actions when conditions are met, such as triggering
alarms or sending your data elsewhere to integrate with external services.

New Features and Improvements

Action Triggers

Action triggers are a way for Conctr to react to events and integrate with
other services. Think IFTTT for your IoT data. Conctr allows you to create
rules, which monitor a condition and trigger actions. When a condition
is met the rule triggers and the action is executed.


Conditions define ways for Conctr to check when a rule should trigger, e.g.
once per day at 9am, or whenever data is ingested with a certain field above a
given threshold.

Available Conditions
  • Scheduling: define a once-off or recurring schedule for triggering a rule
  • Device inactivity: react to a device being inactive (failing to ingest data)
    for a given period of time
  • All data: do something with your incoming data after it is ingested
  • Data checking (transform): specify simple or elaborate checks on your
    incoming data using transforms (custom Javascript code)


Actions are “what gets done” when a rule is triggered (i.e. when a condition is
met). These can be used to implement custom application logic, alarms,
integrate with external services, etc. Actions will receive “event data”,
which is data relevant to why the rule was triggered, e.g. if the condition was
“all data” type then the action will be executed for each piece of incoming
data, and will receive that data as an argument.

Available Actions
  • HTTP: make a custom HTTP request
  • Lambda: execute a user-defined AWS Lambda function
  • MQTT: publish to Conctr’s internal MQTT topics
  • SES: send an email via AWS SES
  • SNS: publish to an AWS SNS topic
  • SQS: send a message to an AWS SQS queue


Rules are pairs of conditions and actions, e.g. if/when my device ingests
data then POST that data to an external service, or when it’s 9am
publish to an MQTT topic (to implement some application logic).

ID Version “latest”

In some situations where a Conctr ID is required (e.g.
[app_id]:[reference]:[version] for models) the version number can now be
replaced with the word “latest” to indicate that Conctr should use whatever
version is the latest at the time. This is valid for model IDs when ingesting
data, for transform IDs when ingesting data or specifying transforms for
actions or for data-checking conditions, and for action IDs when specifying
actions for rules.

New API Methods

Action Route
Create Action /admin/apps/:app_id/actions
Create Rule /admin/apps/:app_id/rules
Deactivate Action /admin/apps/:app_id/actions/:reference/deactivate
Deactivate Rule /admin/apps/:app_id/rules/:reference/deactivate
Execute Action /admin/apps/:app_id/actions/:reference/versions/:version/executions
Get Action /admin/apps/:app_id/actions/:reference/:version
Get Action Info /admin/actions/:type/info
Get Action Versions /admin/apps/:app_id/actions/:reference
Get All Action Infos /admin/actions/info
Get All Actions /admin/apps/:app_id/actions
Get Available Actions /admin/actions
Get Latest Actions /admin/apps/:app_id/actions/latest
Get Latest Rules /admin/apps/:app_id/rules/latest
Get Rule /admin/apps/:app_id/rules/:reference/:version
Get Rule Versions /admin/apps/:app_id/rules/:reference
Log To Application /data/apps/:app_id/appendLog
Search Next Current Change /data/apps/:app_id/devices/search/:_device_id/next
Update Action /admin/apps/:app_id/actions/:reference
Update Rule /admin/apps/:app_id/rules/:reference

For more information see the Conctr API docs