Skip to main content

Devices

Devices are the link between your external things and the data in your account. To allow anything to send or receive data from TagoIO, you need to create a device. The communication between external devices and TagoIO is done via HTTP or MQTT using JSON format. To enable this communication, a device must be created within the platform; this involves specifying the device type and configuring it to send and receive data correctly.

Devices are managed through your Admin interface, where users can access detailed information about each device, including its ID and other settings.

info

Our TagoIO API documentation offers comprehensive instructions on how to interface with devices, ensuring developers can effectively integrate their hardware with the platform.

Adding devices

Devices are connected to TagoIO using Connectors, which act as a bridge between TagoIO and external networks to transmit and receive data. To follow a step‑by‑step tutorial on how to add a device, see the Getting Started article.

Device type and data storage

Once you create a device, it will store all the data sent by your sensors. During the creation process, you will be prompted to select the type of data storage to be used. The right choice depends on one question: will you ever need to edit or delete individual data points? If not, choose Immutable. If yes, choose Mutable. If you need both in the same device, choose Hybrid.

There are three types of data storage you can choose from:

Device Optimized Data (Immutable database)

Best for sensor telemetry: readings that represent a moment in time and never change.

  • Stores up to 36 million data points per device.
  • Native data retention.
  • Highly optimized for short and long retention periods; query responses are faster, which means less latency for the devices and a cost reduction when running an Analysis.
  • Because the data is immutable, no one can change or delete individual sets of data – ideal for compliance.

Managed Data Optimized (Mutable database)

Best for data that changes over time, such as device settings, form entries, or values a script updates in place.

  • Allows you to edit or delete data.
  • No native data retention; you can utilize Analysis to delete data on a scheduled basis.
  • Limited to 50 k data registers.
  • Optimized for the storage and manipulation of configurable variables coming from sensors, web services, and forms.

Hybrid (Immutable + Mutable)

Best when the same device produces raw telemetry and values that need to be updated, such as an Analysis that regenerates an hourly average or an editable status flag. Before Hybrid, this required two separate devices: one immutable for the telemetry and one mutable for the editable values, which meant managing two tokens, splitting dashboards and Analysis code across both, and paying attention to two sets of limits. Hybrid removes that split.

A hybrid device stores both kinds of data in a single device:

  • An immutable side for high-frequency telemetry: time-partitioned, append-only, and subject to data retention (chunk_period + chunk_retention), with the same behavior as an immutable device.
  • A mutable side for a small set of variables that support update and delete and are never dropped by retention, with the same behavior as a mutable device.

A required per-device regular expression, mutable_variable_regex, routes each incoming datum at insert time: if the data's variable matches the regex, it is stored on the mutable side; otherwise it goes to the immutable side. Reads return both sides merged.

A practical pattern is to prefix the variables you'll need to edit. For example, set the regex to ^calc_ and name your Analysis outputs calc_hourly_average: raw sensor data stays on the immutable side, while computed results land on the mutable side, ready to be regenerated each hour.

The regex is an unanchored substring match: it matches anywhere in the variable name unless you anchor it with ^ or $.

RegexEffect
^calc_variables starting with calc_ → mutable side; others immutable
^status$only the exact variable status → mutable
tempany variable containing temp → mutable

The following regex constructs are rejected at create and edit time:

  • Lookahead / lookbehind: (?=, (?!, (?<=, (?<!
  • Backreferences: \1
  • POSIX classes: [[:alpha:]]
  • Unicode properties: \p{...} / \P{...}
  • Shorthand classes: \w \W \d \D \s \S \b \B. Use explicit ranges such as [0-9] or [a-z] instead.
  • Match-everything or match-nothing: patterns like .*, .+, ^.*$, ^$. A hybrid device must genuinely split variables between the two sides; to store everything in one place, use a mutable or immutable device instead.
info

The mutable_variable_regex can only be changed while the device is empty (0 data). On a device that already has data, the API rejects the change; empty the device first, then update the regex.

note

You can convert an existing immutable or mutable device to hybrid; like every conversion, the device must be disabled and empty first. Converting away from hybrid is not supported. Data import routes each CSV row by the regex, the Export button (full-device export) exports the mutable side, and the immutable side is backed up per chunk through Chunk Management. Emptying a hybrid device can target a single side by passing {"route": "mutable"} or {"route": "immutable"} to the empty endpoint.

Managing your device

  • General Information tab: shows the device’s name, network it uses to send data, and the connector used to decode the data.
  • Manage the Device Token and Serial number by generating or deleting them.
  • View usage‑history statistics for the specific device – useful for visibility and control over your Data Input and Output.
    This feature is unlocked once you activate the Control Tower add‑on.

Deactivating devices

  • In the right upper corner of your device page, a switch allows you to activate or deactivate the device. If deactivated, the system denies access to any command coming from the device.
  • You can hide a specific device from showing in the device selection option for your Widgets.
    Access the More tab on your device’s page to make your device visible or hidden.

Inspecting your connection

  • Use the Live Inspector tool by accessing its respective tab on your device’s page. It is useful for debugging parser scripts and monitoring traffic to and from your device.

Customizing payload parser

  • Run your own parser by activating the script console in the Payload Parser tab inside your device’s page.
  • You can also create your own connector if you need to use the same payload parser for several devices. Read more about creating a Connector.

Emulating data sending

Inside your device's page, find the Emulator tab where you can send data to your device as if it were sent by a real sensor.

Customizing behavior of your device

Set device parameters in the Configuration Parameters tab. These can be used to specify how to decode data or send downlink messages, filter your devices on Widgets, or interact with API and Analysis scripts.

Setting rate limits for your devices

  • When sending data to TagoIO, you will have a limit on the number of requests that can be made during a certain time period – see Rate Limits (Hard Limits).
  • You can set custom request rate limits for your device to protect it from malfunctioning and using too much Data Input or Output, or to avoid a single device from sending too many requests and reaching the hard limit for requests of your account, which would block other devices from sending or receiving data for a whole minute.
    This feature is unlocked once you activate the Control Tower add‑on.

Deleting devices

To delete a device, simply go to More on the device page and click on Delete Device. Once deleted, all data will also be excluded. There is no way to recover it once deleted. Be certain before proceeding.