Throughout the previous articles, the data received by the devices are either displayed in their raw form in Live View panels or displayed in Dashboards.
What about the case where the data need to be sent/captured by 3rd party applications?
insigh.io platform offers 3 different ways of accessing the device data as an external application / user.
channels/<data-channel-id>/messages/#
or channels/<data-channel-id>/messages/<device-id>
will receive all the raw measurements as soon as they are received by the insigh.io platform.
Setting up an MQTT integration, the service publishes every message received at a selected topic to a 3rd party MQTT broker. First thing of each MQTT integration is to setup the connection details of the remote MQTT broker. The connection details includes:
Setting up an HTTP integration, the service calls the provided HTTP API upon receiving every message. For instance, this could be an HTTP API that a remote system requires to store locally the device data. The connection details includes:
under construction
Regardless the selected communication protocol, each can optionally be altered before forwarded to a 3rd party system. This operation is done by setting up a Decoder.
Each decoder is a Javascript callback that is called for every message that passes the topic filter with:
arguments
:
deviceId
: the device ID as provided by the Device Info view.senmlMessage
: the raw SenML message as provided by the device.expected return
:
By default there are a couple of decoders ready to be used that cover very common cases of message decoding. (the list will be expanded in the future, as requested)
influx DB line
: translate into a line that when posted to an influx service will be immediately storedJSON
: convert the SenML message into a simple JSON string. Common case is its use in Telegraf.Custom
: an empty callback ready to be coded to user needsEach implementation can be tested on the fly the evaluating the expressing against an example of input message, returning the result in the Evaluated Output field.
Note: the registered decoders can be used across transfer protocols
The final step is to create a Rule. In the Rule setup, the user defines the incoming message filter, the outgoing path (if applicable), the transfer protocol that has been setup before and optionally a Decoder.
In Rule
: a string relating to the MQTT topic of the Data Channel or the Control Channel. It is accepted only if the channel id defined is accessible by user that create the rule! Supports regexes.
channels/bc7d700d-7b04-4576-ac52-c281558f9f99/messages/.*
: capture messages from published by any device on the data channel with id: bc7d700d-7b04-4576-ac52-c281558f9f99channels/bc7d700d-7b04-4576-ac52-c281558f9f99/messages/0d129ed0-0109-4ead-97da-43302a758eed
: capture messages published only by device with ID: 0d129ed0-0109-4ead-97da-43302a758eedOut Rule
: (applicable only for MQTT integrations) the MQTT topic of the remote MQTT broker where the message will be publishedDestination Broker
, HTTP Hook
: select the previously configured 3rd party system detailsDecoder
: select the active decoder to be run for each messageWhen the Rule it is marked as Active. Each rule can be paused or started by editing the rule and pressing Pause or Play button.