Skip to content

Tag relay

Tag relay shares live tag data between two Profinity instances. One instance runs as a sender and publishes the tag collections it is set to export, either as periodic full snapshots or as On Change deltas between full snapshots. Another instance runs as a receiver and ingests that data as remote, read-only tags. The tags sit under a prefix that identifies where they came from.

It supports a fleet or head-office view spanning multiple sites, vehicles, or installations. Tag relay requires the Data Relay licensed feature on both the sending and receiving instance. Licensing shows whether it is licensed and available on a given instance.

Tag relay has no field-level filtering. A sender exports every tag that belongs to its selected collections, so create a collection that contains only the tags a receiver should see.

At each site, a local Tags to Collections to Rules to Actions and Alerts pipeline runs on its own; Tag Relay lifts that up to a central fleet instance with its own fleet-wide collections, rules, and alerts spanning every site

Each site runs its own tag pipeline, and relay adds a shared view at the central instance

Tag relay works only between Profinity instances, and it does not use Sparkplug, a Message Queuing Telemetry Transport (MQTT) payload format for industrial data. If the other end is a third-party Sparkplug B source, such as an edge gateway or a third-party Supervisory Control and Data Acquisition (SCADA) platform, use the MQTT Subscriber instead. Refer to that page for the reverse comparison.

How it works

Site instances run a Tag Relay Sender publishing live tags over HTTPS with a JSON Web Token (JWT) or over MQTT; a central instance runs a Tag Relay Receiver, showing each site's tags under its own prefix, for example SiteA/System1/Battery/PackVoltage

Sender and receiver roles, with per-site tag prefixes on the receiving instance

A Profinity instance with a Tag Relay Sender component exports the member tags of the collections selected in the sender. In Snapshot mode it sends a complete snapshot at the interval set on the Tag Relay Sender, under Snapshot / change interval (seconds). In On change mode it sends a complete snapshot on connect and reconnect, and again every Resync interval (seconds) (default 300 seconds), and sends only value changes between those snapshots. Full snapshots include tag metadata such as units.

The receiver holds the latest accepted values for each mirrored tag. A rejected snapshot leaves the previous values in place, as the Tag Relay Sender troubleshooting describes. Tags outside the selected collections are never sent.

A Tag Relay Receiver component connects to one or more senders. It mounts each sender's tags under a prefix that identifies that site, for example SiteA/…. A single receiving instance can then ingest many senders without their tag trees colliding. A sender is reached over HTTPS with a JSON Web Token (JWT) or over MQTT, and the choice is made per sender.

Relayed tags on the receiver are read-only, so the receiving instance cannot write back to a site through relay. Local tags, collections, rules, and alerts on the receiver can reference relayed tags the same way they reference any other tag.

Collision rules

The receiver checks a whole snapshot against its live tag tree before it changes anything. A single collision rejects the entire snapshot, so nothing is partially applied. A snapshot is rejected whole, leaving every tag as it was, when any item in it meets one of these conditions:

  • The path is already occupied by a tag that did not come from relay, such as a local device tag, a script register or a derived tag.
  • A tag that came from relay already exists as a leaf where the snapshot needs a branch, or as a branch where the snapshot needs a leaf.
  • The snapshot itself asks for both a branch and a leaf at the same path.

A relayed leaf that already exists where the snapshot carries a leaf is not a collision, and its sample is updated. A path occupied by a tag that did not come from relay always causes the whole snapshot to be rejected.

Troubleshooting a sender that stops updating

What you see Cause What to do
The tags from one sender stop updating. Over HTTPS, the sender receives a 409 Conflict response carrying the reason. Over MQTT, the receiver writes a warning to the Profinity log and discards the snapshot. A path in that sender's latest snapshot clashes with a tag already on the receiver, so the receiver rejects the whole snapshot. Remove the local tag that occupies the path, or change the Receiver tag path prefix setting. The receiver then accepts the next snapshot from that sender.
The sender receives 400 Bad Request. The snapshot is malformed, or its version is not 2.3. A Profinity 2.3 Tag Relay Sender sets version itself, so this applies to a snapshot from another publisher or release. Set version to "2.3" in each snapshot.

For the settings of each role, refer to Tag Relay Sender and Tag Relay Receiver. Refer to Roles and permissions for the permissions involved. Refer to Tag layer for the rest of the tag pipeline.