Skip to main content

Telemetry variables

Telemetry variables (in the UI: the Telemetry tab) define which data an asset of the template exposes: key, type, unit, history, list display, writability and mappings.

They are separate from IoT connectivity and Metadata: connectivity says how messages arrive; metadata is static information; telemetry variables say which live fields to read (and write) from those messages.

They stay empty until an asset is linked to a physical device (see Connecting a physical device).

If connectivity is MQTT, the profile (Generic, Seneca, Siemens Logo, Teltonika RutOS) changes which options you see on each field, how Spaces proposes keys from the payload, and how the write message is built. See MQTT profiles and telemetry fields.

Variable options​

For each field under Telemetry you can configure:

OptionEffect
KeyField identifier in the datastore and, by default, in the payload. You can change it when confirming discovery: the path in the message stays the identity on the wire.
LabelDisplay name in the UI
TypeBoolean, Number or String
Unite.g. °C, %, bar
Min / Max / StepConstraints for numeric values (and Slider widgets)
Save historyKeep points over time (Trend, charts, plan retention)
Show in listColumn on the asset list; formatting rules (operator, label, icon, color)
WritableAllows writes from asset detail and Button/Slider/Switch widgets
Write payload templateMQTT Generic and Teltonika only, and only if the field is writable. JSON published on MQTT for this field. See below.
Value mappingRaw value → label (and icon/color in list/widgets)
Path in message (path)Path in the JSON payload. Identifies the field on the wire even if you rename the key.

You can declare fields manually when creating/editing the template, or let them emerge from telemetry discovery.

Telemetry discovery​

If the device sends keys not yet declared on the template, Spaces proposes them in the Telemetry discovery panel (refreshed periodically), on the asset detail page or from the template.

For each pending field you can:

  1. See a sample value and where it sits in the message (path in the JSON).
  2. Set key (you can rename it from the proposed one), label, type, unit, history, show-in-list, writable.
  3. Use Suggest AI metadata for an automatic proposal (once per set).
  4. Confirm (adds the field to the template, hence to all assets of that type), Ignore, or Ignore all.

The confirmed key is the name you will use in dashboards, alarms and writes. The path in the message stays the discovered one: Spaces keeps reading (and, if needed, writing) the same JSON location even if you picked a more readable key.

On the template, under Telemetry, you can enable/disable automatic field detection. When off, unknown keys are ignored. Only Admins manage discovery.

tip

With nested or free-form JSON payloads, enable automatic detection: Spaces proposes field paths and you confirm them as telemetry variables.

Writable variables​

If a variable is writable, from the Parameters tab (or dedicated widgets) you can send a new value to the device through the IoT connectivity configured on the template.

For MQTT, the published message depends on the profile and, if present, on the field write template. The order is:

  1. The field write payload template, if filled (Generic and Teltonika).
  2. Otherwise, for the Generic profile, the template-level payload template.
  3. Otherwise the payload defined by the profile (Seneca, Siemens Logo).
  4. If there is no template at all, only the raw value is published (the key is already in the topic).

Placeholders accepted in templates:

PlaceholderReplacement
{{key}}Variable key (the confirmed one, not necessarily the name on the wire)
{{value}}Value as plain text
{{json_value}}JSON-encoded value (22.5, "auto", true)
{{random}}One random integer, the same for every occurrence in that message (useful as a cookie / correlation id)

MQTT profiles and telemetry fields​

The profile is chosen under IoT connectivity. Below is what changes on the fields.

Generic profile​

  • Under Telemetry, every writable field shows Write payload template.
  • If you leave it empty, the template-level payload (or the raw value) is used.
  • If you fill it, that field publishes its own JSON and ignores the template-level payload.
  • Discovery proposes keys as they appear in the JSON (objects, arrays, key/value tables).

Example of a field-level template:

{"cmd": "{{key}}", "val": {{json_value}}}

Seneca profile​

  • The Write payload template field does not appear: every write uses { "value": <value> }.
  • Remote commands (reboot, VPN, …) are not fields: they live on the asset's data-exchange page.
  • Discovery uses the names the device publishes (usually the Seneca payload name field).

Siemens Logo profile​

  • The Write payload template field does not appear: Spaces already publishes in the LOGO format, for example:
{"state": { "Nome_Tag": {"value": [1]}}}

Nome_Tag is the variable key ({{key}}); the written value goes into value[0].

  • During discovery Spaces:
    • ignores desc and name wrappers (they do not become fields to confirm);
    • proposes the tag name as the key (first path segment), even if the value sits at value[0].

Example. The LOGO publishes:

{
  "Nome_Tag": {
    "desc": "Tank temperature",
    "value": [22.5]
  }
}

Spaces proposes one pending field: key Nome_Tag, path ["Nome_Tag"]["value"][0], value 22.5. It does not propose desc. You can confirm the key as-is or rename it (e.g. temperature): on read Spaces still uses the path; on write it uses the confirmed key inside state.

Teltonika RutOS profile​

  • Under Telemetry, every writable field shows Write payload template (Teltonika Modbus/MQTT JSON).
  • There is no template-level write template: either you fill it on the field, or Spaces pre-fills it from discovery.
  • Named-record payloads (arrays of objects with name / key and a scalar reading data / value / v / state): each row becomes a field. If the row also has ip, server_id and full_addr, Spaces fills the write JSON, for example:
{"cookie":{{random}},"type":0,"host":"192.168.1.127","port":502,"server_id":1,"timeout":5,"function":6,"register_number":3,"value":{{value}}}

full_addr in Modbus notation 400003 becomes register 3. {{random}} is the request cookie; {{value}} is the value you send from the Parameters tab.

  • Standalone I/O objects (free format, not a collection row): discovery still creates the field but does not pre-fill the template. Enter it by hand on the field after making it writable.
  • Once the variable is confirmed, later messages do not overwrite the write template. If the Modbus address changes, update the JSON on the field.

:::note Discovery panel In the pending-fields panel the write template is not editable. For Teltonika it is still stored in the background and copied onto the variable when you confirm. You review and edit it under Telemetry after confirm, if the field is writable. :::

Next steps​