ARServerGateway Concept
ENID

IEC 61850 to MQTT

Publish selected relay values as topic-based engineering data.

MQTT is useful when selected relay values need to reach dashboards, middleware, historians, or engineering monitoring tools through a broker.

Bridge workflow

Topic design must preserve context, not only value

IEC 61850 values often include quality, timestamp, object path, and communication state. MQTT consumers need that context so a dashboard does not display stale or invalid data as if it were live.

Recommended publishing flow

  1. Select useful relay points in ARServer.
  2. Validate that the selected points are readable.
  3. Choose a topic scheme that identifies gateway, IED, point, and state.
  4. Publish payloads that include value, quality, timestamp, and local update time.
  5. Test the broker and subscriber behavior before relying on the dashboard.

Example topic shape

A practical topic can follow a predictable pattern such as arserver/{ied}/{tag}/state. The payload should remain readable enough for debugging and consistent enough for applications.

Engineering rule: publish quality and timestamp together with the value. A naked value is not enough for operational judgement.

When MQTT helps

MQTT is useful for publish/subscribe distribution and data-platform integration. Modbus TCP is usually easier for traditional HMI/SCADA polling. ARServer can expose both from the same selected runtime cache.

MQTT basicsLearn broker, topic, payload, and subscriber concepts first.TroubleshootingCheck broker connection, topic route, and stale value symptoms.