Skip to main content
Version: 3.0

What readers receive

A quality dashboard subscribes over MQTT and a reporting job calls the API. Today each must know that Line 4 sends °F and convert it itself. Once the topic has a meaning, both receive °C with the unit attached.

MQTT
value, unit, property
REST
POST /api/v1/uns/data/latest
Trust
How each value was served
Editions
Foundation, Enterprise, free trial

The problem​

Every reader of Line 4 carries its own copy of "this one is °F": the dashboard, the report script, the export to the quality system. Each converts a little differently, and the day the device is replaced by one that sends °C, every copy is wrong.

What you will get​

From the moment the meaning takes effect, MaestroHub converts once, on the way in. The topic's MQTT message carries the converted value, its unit and the meaning, and the REST API answers the same value with its unit and a trust mark. An unbound topic's messages stay exactly as they were.

Before you start​

What the device sends​

Line 4's gateway sends the number as it always did, in °F:

{ "path": "f4/ProductTemp", "value": 40.9 }

What an MQTT reader receives​

A subscriber to mHv1.0/<workspace>/trabzon/filling-hall/line-4/f4/ProductTemp receives the converted value, the unit, and the meaning's property id (provenance folded here for space):

{
  "value": 4.777777777777779,
  "timestamp": "2026-11-03T04:54:55.001Z",
  "unit": "°C",
  "property": "9351999f-847a-48d3-841d-f7c42f949912"
}
  • unit is the meaning's unit. For a topic that sends an object, units gives one per field instead.
  • property is the id of the property the value carries (Product temperature). For an object topic, properties gives one per field.
  • Both are absent on a topic without a meaning, so existing subscribers see the same bytes as before.

What the REST API answers​

curl -s -X POST "https://<your-host>/api/v1/uns/data/latest" \
  -H "Authorization: Bearer $TOKEN" \
  -H "X-Workspace-ID: <your-workspace-id>" \
  -H "Content-Type: application/json" \
  -d '{"topics": ["mHv1.0/<workspace>/trabzon/filling-hall/line-4/f4/ProductTemp"]}'

The answer, shortened:

{
  "records": {
    "mHv1.0/<workspace>/trabzon/filling-hall/line-4/f4/ProductTemp": {
      "value": 4.944444444444443,
      "timestamp": "2026-11-03T04:54:50.000Z"
    }
  },
  "denied": [],
  "semantics": {
    "mHv1.0/<workspace>/trabzon/filling-hall/line-4/f4/ProductTemp": {
      "unit": "°C",
      "trust": "translated"
    }
  }
}
  • topics takes up to 500 versioned topic names. Topics you may not read are listed in denied.
  • semantics is present only for topics with a meaning. trust says how the value was served:
    • translated: converted on the way in, under the meaning in force.
    • converted_before_binding: stored as the device sent it before the meaning existed, converted when read.
    • untranslated: could not be converted; served as sent, with Bad quality.
  • History reads (POST /api/v1/uns/data/range) mark each stretch of time the same way, so a chart can show where the meaning starts.

Check the result​

Subscribe with any MQTT client and compare the device's number with the one you receive: 40.9 °F is 4.9 °C. Then run the curl above: the same topic answers in °C with "trust": "translated".

Good to know​

  • Readers that already convert must be told the unit changed, or they convert twice. When you give the meaning, the page lists the pipelines, dashboards and apps that read the topic and asks you to confirm you have checked them.
  • Converted values carry floating-point tails (4.944444444444443). Round them where you show them.
  • Values stored before the meaning are never rewritten; reads convert them and mark them converted_before_binding.