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, so you or an assistant can quickly find the right one by manufacturer, device model, or function.

Yggio ships around 500 translators, in two kinds:

• Hardware translators decode one sensor's payload. There are roughly 450 of them, from vendors including Milesight, Dragino, Elsys, Adeunis, Decentlab, Watteco and Sensative. These are the ones listed in the A-Z pages below.
• Logic translators are chained: they run on top of a hardware translator's output to calculate, raise alarms, analyse a trend or reshape data. Around 100 of them, and they are not in the A-Z pages - each kind has its own page, listed under Categories.

If your sensor is not among them, a translator can be written and uploaded without waiting for a release.

How this catalog is structured

The A-Z pages carry one entry per hardware translator, ordered by translator name. Each entry is deliberately short, and always in the same shape:

### <translator-name>
**<Official name>** · <Type>
**Manufacturer:** <vendor>
**Models:** <further models / SKUs>

<one- to three-sentence summary>

• translator-name - the id you attach to a device, and the heading to search for.
• Official name - the vendor's own name for the product.
• Type - what it is: the sensor kind and transport for a hardware decoder, or the logic category for a chained translator.
• Manufacturer - who makes the hardware, so the catalog can be browsed by vendor. Where the brand and the manufacturer differ you will see both, as in Seeed (SenseCAP) or Kerlink (Wanesy). Logic translators have no manufacturer.
• Models - present when one translator covers several models or a whole product family, listing those the official name does not already state.
• Summary - what the device measures, or what a logic translator computes and when you would use it, in plain words: temperature, CO2, water leak, people counting.

Logic translators are covered in more depth on their own pages, listed under Categories below. Their entries in the A-Z pages point there rather than repeating the detail.

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). These have their own page: Analytics translators.
• Calculation - arithmetic and unit transforms, calibrations, and per-period aggregation (e.g. consumption per day/week/month, dew point, unit conversions). These have their own page: Calculation translators. Coordinate projections are separate: Transform translators.
• Alarm - raise boolean alarms from thresholds on a decoded field (e.g. high/low temperature). These have their own page: Alarm translators.
• State/occupancy - derive a state or occupancy flag from decoded fields. These have their own page: State and occupancy translators.
• Data transfer - forward or copy fields between nodes. These have their own page: Data transfer translators.
• Utility - helpers, examples, and configuration translators. These have their own page: Utility 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 full data model, every canonical field with its type, unit and quantity, is published in this documentation. The Translator API covers the field-level reference and how to consume it.

Versions

A translator's version number says what changed, and therefore what it can break. The three parts are not interchangeable.

Change	Example	What it means
Patch	1.0.0 to 1.0.1	A bug fix or a security update. Same fields, same names, same meaning. Nothing downstream needs to know
Minor	1.0.0 to 1.1.0	New capability, possibly new fields, but the existing fields keep their names and meaning. Backward compatible
Major	1.0.0 to 2.0.0	The data model changed: fields renamed, retyped or removed. Anything reading the old names has to be repointed

Only a major version can break a consumer, so that is the one Yggio asks about. Change a version yourself and it shows the current data model beside the new one, with the fields being removed and added marked, and waits for you to confirm - see Changing a major version.

An upgrade policy decides how far a device follows new versions on its own, from none through patch and minor to all. A policy that permits major upgrades takes them without asking, which is why it should only be set where the result can be verified - see Versions and upgrade policies.

Nothing crosses a major boundary on its own. A device stays on the version it has until someone chooses to move it, and sees what changes before it does.