¶ Concepts
The Tartabit IoT Bridge is an easy to use integration service that quickly connects LPWAN IoT devices to enterprise applications. This section provides conceptual information about the platform and how to go about building your solution quickly.
¶ Components
Applications are built by developing triggers that enable endpoints to communicate to applications via services.
- Endpoints are optional, but generally represent LPWAN devices that are recognized by the platform. Endpoints can generate events, and be the target of actions. Endpoints hold the device specific configuration settings, whereas services hold the common parameters for groups of devices.
- Services are the primary anchor for LPWAN devices, and hold configuration settings for all endpoints associated with the service. Common device parameters include port numbers, security configuration, and communication timeout parameters.
- Triggers are the heart of the system. Triggers process events and execute actions to bi-directionally map data between devices and enterprise applications. Triggers are scripts written in JavaScript that can manipulate the raw event data and convert data between different formats.
- Services are also used to control access to enterprise applications. Services hold information like security credentials to enable access to the application.
- Enterprise applications are the systems you need to communicate with, from databases, and messaging systems, to other IoT platforms.
¶ Service
Your first step is usually to start by creating a service. Services are used to configure connections to enterprise applications or to devices. An example would be a service to connect to InfluxDB, such a service requires the hostname of the InfluxDB server, the authentication credentials, as well as the database to use. Similarly, a service like the HTTP service can be used to receive information from device clouds and requires configuring the webhook secret to uniquely identify the traffic from your device cloud.
¶ Endpoint
Endpoints are used to identify the devices in the field. These endpoints serve as anchors to provide stateful functionality to the service. There are two types of endpoints that you may encounter:
- Auto-generated endpoints - Auto-generated endpoints are defined automatically by your services to represent devices that have been discovered on the network. You cannot create, export, or import these endpoints, but you can edit them to update references such as tags.
- User-defined endpoints - User defined endpoints are defined by the user, and are typically encountered when the device requires some specific configuration in order to connect to its associated service. An example would be LWM2M devices, where a unique endpoint, identity, and pre-shared key must be defined for communication to be possible.
¶ Trigger
Triggers are the work-horse of the platform. Triggers are configured to execute when events that match its defined filters are received. The trigger executes a script that can decode and manipulate the data from the event, and then call functions to trigger actions that send the data to other services. Typically workflow can be defined as either "device to cloud" or "cloud to device", depending on the use case.
¶ Events
All triggers begin with an event. When events are generated, they are routed to the relevant triggers enabling the trigger execution to begin. Events contain meta-data from within the IoT Bridge, as well as any relevant data that relates to the event. For example a "data change" event would contain a timestamp, device identifier, and the value that has changed.
¶ Actions
Actions are the mechanism for triggers to send data to a service. Actions can be used to send data to send to or query data from an enterprise application. Actions can also affect devices, by initiating a firmware update, or changing a setpoint.
¶ Dataflow
Below is a diagram that shows how data moves from devices to applications in the IoT Bridge.
- A: Devices send data that is converted to an event.
- B: Events are filtered and processed by triggers.
- C: Triggers decode and process the data from the devices.
- D: Triggers receive data that has been enriched depending on your configuration, as an example, if the event includes location data, it will be reverse geo-coded and the address will be included in the event.
- E: Triggers encode the data to be send to the enterprise application, this can include transforming units, building custom JSON payloads, or other transformations that need to be performed prior to sending.
- F: Triggers call functions to send the encoded messages to enterprise applications.
¶ Managing identifiers
One of the more complex decisions to make in any IoT solution is how to identify and track the asset that you are trying to connect. You can choose to track an asset by one of its network identifiers (IMEI, ICCID, MAC address), or by something unique to your product like a serial number of VIN of a vehicle. There are pros and cons to each approach, typically the telematics device doing the tracking can be replaced in the event of a maintenance problem, but the asset itself remains the same, so in these cases, tracking by a product ID makes sense. Sometimes the device is essential to the operation, so tracking by the IMEI or ICCID makes more sense. You need to consider these options when configuring your application.
¶ How to get started
It can be a daunting task to integrate LPWA devices to the cloud, and we've found there are important decisions that need to be made so that your journey can be as short and reliable as possible. Below you will find a list of key questions you need to be able to answer to be successful. Some of the questions that you must answer may pose "chicken and egg" scenarios, as a first decision on one part of the solution, like selecting the hardware, may dictate which communication protocls you can use for the devices. Similarly, selecting a specific protocol, like LWM2M, may affect which device you can use if you want a simple and seamless experience.
¶ What is more important, the protocol or the device?
Selecting the correct communication protocol can make a huge difference in the success of your overall solution. While many devices and services support MQTT, MQTT is far from ideal for battery powered devices, or communication strategies that rely on low data consumption. And while LWM2M may be feature rich and LPWA friendly, it also involves additional complexities on the device and can be overkill for some scenarios.
¶ Event counters & billing
The Tartabit IoT Bridge measures the number of events that are generated within your account and all sub-accounts. The standard contract allocates your account a number of events per day that can be executed before execution will cease. Please refer to the documentation for the specific services that you are using for details about what is considered a billable event.
In the event that your account is suspended for exceeding your allocated daily events, your account will automatically un-suspend at midnight UTC the next day and processing will resume as normal.