Hoppa till huvudinnehåll

Translators

A translator turns a device's raw payload (or an upstream translator's output) into the IoT platform's harmonized, canonical data model. This section is a lightweight catalog of most translators - grouped alphabetically by translator name - so you, or an assistant, can quickly find the right one by manufacturer, device model, or function.

Each entry is deliberately short:

### <translator-name>
**<Official name>** · <Type>
**Manufacturer:** <vendor>
**Models:** <further models / SKUs, only when they add something>

<one- to three-sentence summary>

The rule for adding entries: one ### per translator - official name, type, manufacturer, any extra models, and summary all under that single heading. Keep every entry in that shape so the catalog stays uniform as it grows.

  • translator-name - the id you attach to a device (the heading).
  • Official name - the vendor/product name.
  • Type - what it is (sensor kind + transport, or the logic category).
  • Manufacturer - who makes the hardware, so the catalog can be browsed by vendor. Use the manufacturer, not the brand, when they differ - Seeed (SenseCAP), Kerlink (Wanesy) (hardware translators only).
  • Models - only when the translator covers models the official name does not already name, such as a family or a multi-model decoder. Do not repeat the manufacturer inside it, and omit the line entirely when it would just restate the official name.
  • Summary - what the device measures or does, in plain words ("temperature", "CO2", "water leak", "people counting"), or what a logic translator computes and when to use it. Search matches on the heading and this text - and keywords in the frontmatter are per-file, so they cannot single out one translator in a multi-entry file. Name the measured quantities rather than restating the product name, and base them on what the translator actually decodes, not on what the model name suggests.

Full details live in the IoT platform​

This catalog is a summary index, kept intentionally light so it is quick to browse. The authoritative, complete definition of each translator - the full decoded output fields, their units and quantities (the complete data model / spec), the version, the match rules, and the full description - is available in the IoT platform itself: via the translator API (the platform's Swagger) and in the device/translator views. Use this page to discover which translator you need; use the IoT platform for the exact, up-to-date spec.

For the field-level reference and rules, see the Translator API.

Categories​

Hardware decoders​

Turn a device's raw uplink into canonical fields. Distinguished by transport:

  • LoRaWAN - the majority of sensors.
  • NB-IoT - cellular sensors (tagged (NB-IoT)).
  • Modbus - wired/gateway meters and controllers (tagged (Modbus)).
  • Cloud-to-cloud - devices whose data arrives via a vendor cloud, not a raw radio payload (tagged (Cloud-to-cloud)).
  • wM-Bus - wireless M-Bus meters (tagged (wM-Bus)).
  • Camera analytics - camera/ACAP apps that report counts or speeds.

Some hardware translators are family/model-detecting: one translator decodes a whole product range (its Models line lists the range).

Logic / chained translators​

These run on top of another translator - they read fields already decoded upstream (not raw payloads) and add derived values. They have no hardware model.

  • Analytics - higher-level KPIs and insights (e.g. energy-efficiency, rate of change, utilization, frame-loss quality).
  • Calculation - arithmetic and unit transforms, calibrations, and per-period aggregation (e.g. consumption per day/week/month, dew point, unit conversions).
  • Alarm - raise boolean alarms from thresholds on a decoded field (e.g. high/low temperature).
  • State/occupancy - derive a state or occupancy flag from decoded fields.
  • Data transfer - forward or copy fields between nodes.
  • Utility - helpers, examples, geofence/timer, and configuration translators.

The canonical data model (summary)​

Most translators emit the same harmonized, NGSI-LD-aligned flat data model, consolidated from ~2000 ad-hoc property names down to a shared vocabulary of canonical field names. That consistency is what lets one alarm, dashboard, report or downstream translator work across any device.

  • Names - lowerCamelCase, flat, no vendor jargon: e.g. temperature, relativeHumidity, batteryVoltage, batteryLevel, co2, location.
  • Units - SI symbols, declared per field: V, A, W, Hz, Pa, m, s, m/s, m^3, kWh, C, %. Counts, enums and flags are dimensionless ('') with a named quantity.
  • Typing - each field carries {type, unit, quantity}, so consumers know how to read and display it.
  • Temperature medium - carried in the field name: temperature (air/ambient), waterTemperature, soilTemperature, surfaceTemperature, externalTemperature, internalTemperature.
  • Indexed / multi-value - a bare primary then numbered extras (temperature, temperature2, …), or symmetric channels numbered from 1 (pulse1…pulse4).
  • Alarms - subject-first with an Alarm suffix, boolean (temperatureHighAlarm, tamperAlarm, leakageAlarm).
  • Status - subject-first boolean/enum (batteryLow, occupied, contact).
  • No deprecated aliases - canonical names only (e.g. relativeHumidity not humidity, batteryLevel not battery, location not lnglat).

The canonical vocabulary is the single source of truth in yggio-core-constants (src/translator-fields.ts); the Translator API documents the full field catalogue and the naming rules.