ARServerMQTT Dashboard
ENID

MQTT dashboard use case

Publish selected relay values to dashboards with context.

ARServer can publish selected IEC 61850 values to MQTT so dashboards, middleware, and historians can subscribe without speaking IEC 61850 directly.

Publish / subscribe route

Relay / IED → ARServer → MQTT Broker → Dashboard

MQTT output is useful when the consuming system is not a traditional HMI polling client. A broker allows dashboards, middleware, historian experiments, and scripts to subscribe to selected state topics.

Good MQTT payloads include context

  • Current value.
  • IEC 61850 source object or tag name.
  • Quality and communication state.
  • Device timestamp and local update time.
  • Readable status for stale or invalid values.

Topic design

Use predictable topic names, for example arserver/{ied}/{tag}/state. Avoid topic names that hide the IED identity or make dashboards depend on undocumented naming conventions.

Dashboard rule: never display a value without quality and timestamp context. A stale relay value can look normal unless the dashboard is designed to show state clearly.

When this use case fits

  • Engineering dashboards need live relay values.
  • Middleware needs selected SCADA points as JSON-like messages.
  • Historian or data experiments need a broker route.
  • Modbus polling is not the preferred integration model.
Learn IEC 61850 to MQTTUnderstand topic and payload design before publishing.MQTT TroubleshootingCheck broker, topic, payload, and stale behavior symptoms.