Auto-Link IoT Devices to Assets as Hardware Moves

Who it’s for

Teams with replaceable or rotating hardware — GPS trackers moved between vehicles, monitoring sensors swapped between machines, removable modules reassigned across production lines, soil probes redeployed across field zones — asking “how do I keep the asset graph in sync when a device physically changes its parent?”, “how do I avoid manually re-linking trackers every time they swap onto a different vehicle?” — when a device’s logical parent (the Equipment asset in this template — rename to whatever your fleet uses: Vehicle, Machine, Container, Site) changes over its lifetime and the device itself knows which parent it is currently attached to.

What it does

Reads the parent asset identifier from each device’s client-side attribute upload and maintains a single Contains relation from that asset to the device. The asset is created on demand the first time it is referenced, and the relation swaps automatically when the device moves — without any node-by-node delete-then-create dance, because Create Relation’s Remove current relations option does both steps atomically.

Scenario 1 — First registration. When a device that has never had a parent reports its first equipmentId, the chain creates the matching Equipment asset on demand and links them.

Scenario 2 — Device moves to another existing parent. When the device reports a different equipmentId that matches an asset already present in the tenant, the chain removes the old Contains relation and creates a new one to the existing asset — the asset itself is reused.

Scenario 3 — Device moves to a brand-new parent. When the reported equipmentId doesn’t match any existing asset, the chain creates the asset on demand and swaps the relation in the same step.

The chain extends the default ThingsBoard root chain with the parent-linking flow — a filter that scopes to attribute uploads carrying equipmentId, plus the create-relation action node that swaps the device’s Contains link to the matching parent asset:

• A Script filter — labelled Parent ID present? in this chain. Passes attribute uploads that carry the equipmentId key, drops the rest.
• A create relation action node — labelled Link to Parent in this chain. Creates a Contains relation from the parent asset to the device. The Asset name is resolved from $[equipmentId] — a templatization dynamic placeholder that references the equipmentId value from the message. If no matching asset exists, it’s auto-created with the Equipment profile. Any existing Contains relation on the device is dropped in the same step, so one node handles both removing the old relation and creating the new one.

How to set up

1. Click Install to open the install dialog. The dialog offers two paths:

   • Bind to a profile — enable Set as profile default rule chain and pick the target device profile. The imported chain becomes that profile’s default rule chain.
   • Install only — leave the toggle off. After install, either set it as the root — it already bundles the default routing plus the parent-linking flow — or extract the parent-linking flow into a nested rule chain and connect it to the Post attributes output of Message Type Switch.

2. The chain runs on the next attribute upload — find the post attributes API for your protocol in the Device APIs section on the APIs & SDKs page.

How to customize

Customizations on the Parent ID present? filter:

• To drop the filter entirely — when every attribute upload from your devices already carries the parent identifier, delete the Parent ID present? node and connect Message Type Switch → Post attributes directly to Link to Parent. Keep the filter only when devices send a mix of attribute uploads (firmware version, calibration data, etc.) and the relation update should run on the parent-identifier ones only.

Customizations on the Link to Parent create relation action node:

• To use a different attribute key for the parent identifier — change Asset name on the Link to Parent node (e.g. $[equipmentId] → $[vehicleId], $[machineSerial], $[siteCode]) and update the Parent ID present? filter body to match the new key.
• To link to a different asset profile — change Profile name on the Link to Parent node (default Equipment). Both the asset and its profile are created on demand if they don’t already exist, so you can pick any name that fits the parent category — no pre-creation required.
• To pick the asset profile dynamically per message — Profile name supports the same templatization as Asset name, so you can drive it from a message key (e.g. $[assetProfile]) or a metadata key (e.g. ${assetProfile}). Useful when one device fleet feeds multiple parent categories — e.g. trackers reporting assetProfile = "Vehicle" vs. "Container" create the parent under the correct profile automatically.
• To use a different relation type — change Relation type on the Link to Parent node from Contains to your own relation (e.g. Manages, OperatedBy). The chain still swaps relations of this same type when the device’s parent changes.
• To compose the asset name from multiple message fields — Asset name accepts mixed templates and plain text in one field, so most compositions go inline: $[region]-$[siteCode], Vehicle-$[vehicleId], or mixed sources like ${region}-$[siteCode]. Dot notation works for nested payload keys ($[location.region]).
• To compute the asset name in code — when inline templates aren’t enough (uppercase, strip a prefix, conditional logic), add a Script transformation between the filter and Link to Parent, stage the computed name into metadata, and reference it from Asset name as ${assetName}.
• To keep processing the message as the parent asset — enable Change originator to related entity on the Link to Parent node (under Advanced settings). The submitted message is then processed as a message from the Equipment asset.

See also

Need to mirror device telemetry onto the parent asset? Pair this chain with a propagation Calculated Field on the Equipment profile. It copies mission-critical values from the child device to the related parent automatically — no extra rule-chain wiring needed:

Sync GPS Position from Tracker to Vehicle or Container verified Dmytro Shvaika

A single propagation CF writes to one output type only — either timeseries OR attributes on the parent, never both. If some keys should land on the asset as timeseries and others as attributes, set up two propagation CFs (one per output type) using the same template.