Merging and splitting devices
When more than one connector reports the same real-world device, it can appear more than once in Xyte — one entry per connector.
Merging combines these duplicates into a single device with a primary instance and one or more secondary instances. Splitting reverses it. A merged device is counted once for licensing.
Video walkthrough
What can be merged
| Instances merged | Example |
|---|---|
| Physical + vendor cloud | A Crestron device discovered by the Xyte Edge Agent and also reported by the Crestron cloud connector |
| Physical + monitoring cloud | A Crestron device discovered by the Xyte Edge Agent and also monitored through Domotz |
| Vendor cloud + platform cloud | A Crestron room system reported by the Crestron cloud connector and represented by a related Zoom Rooms instance |
| Physical + vendor cloud + platform cloud + monitoring cloud | The same Crestron room system reported by the Crestron cloud connector, discovered by the Xyte Edge Agent, represented as a Zoom Rooms instance, and monitored as a Crestron device in Domotz |
How Xyte identifies a device
When a device is onboarded, Xyte gives it an identity based on either its cloud identifier (for devices from a cloud connector) or the combination of its MAC address and serial number. This identity keeps the same device from being registered twice under the same source.
When the same physical device is brought in through different sources — for example a cloud connector and the Edge Agent — each source creates its own record. Merging brings those records together, and you choose which ones represent the same device.
If you'd like help identifying or reconciling duplicates at scale, reach out to [email protected].
Rules
- Up to 4 devices per merge.
- All must belong to the same customer.
- They do not need to be in the same space already — when you merge, the secondary instances are moved into the primary's space. From then on the merged device moves between spaces as a unit.
- Each instance must come from a different source. A device discovered by the Edge Agent can be merged with one reported by a cloud connector, and two different cloud connectors can be merged together — but two devices imported by the same cloud connector cannot be merged with each other.
One physical device reported twice by a single connectorSome devices are discovered more than once by the same connector — most often a unit with two network interfaces, such as separate control and audio (for example Dante) connections, which the provider reports as two devices with different MAC addresses.
Because every instance in a merge group must come from a different source, these cannot currently be merged. If you do not want the second interface monitored, you can delete that device: it will be listed as excluded on the connector's devices page, will not be re-imported on the next sync, and will not count towards your device total. See Viewing C2C device status per connector.
How to merge
- Select the duplicate devices (2–4) in the device list.
- Choose Merge.
- Pick a primary instance — it provides the icon/name shown in list and tile views, and is the instance actions run against.
- Confirm.
How a merged device behaves
- Display & actions: shows the primary instance's name/icon (renameable); actions run on the primary instance.
- Incidents: surfaced from all instances together; offline tracking can be disabled per instance.
- Billing: counted as one device, whether its instances are physical or cloud representations.
- Location & child devices: all instances stay in one space and move together; child devices are listed per instance rather than combined.
What merging changes on each record
Merging does not rewrite your devices. It links them and puts one of them in front.
On the primary instance — nothing changes. It keeps its own name, model, identifiers, details, state and history.
On each secondary instance — exactly one thing changes: it is moved into the primary's space. Its name, model, cloud identifier, serial number, MAC address, details, state, telemetry and incident history are all untouched, and it keeps reporting through its own source exactly as before.
What you see — the merged device is presented as the primary: its name, its icon, its model, and its Overview dashboard. Each instance then appears as its own tab, with its own Overview, Details, State, Incidents and Notes.
This is worth understanding before you pick the primary, because the Overview you land on is the primary's. Every instance's data is still there, one tab away — but the dashboard shown first is the one belonging to the primary's model. If the instance with the richer data is not the primary, its readings live behind its tab rather than on the front page.
Splitting unlinks the instances again. Note that it does not move a secondary back to the space it came from — it stays where the merge put it, and you can move it yourself afterwards.
Use cases
No single connection sees the whole device. One knows it is up and answering on the network; another knows what the device says about itself — health, uptime, firmware, link speed, redundancy. Neither is the full story on its own.
That is what merging is for: bring the same physical device together from two or more sources, so their different depths add up to one complete picture, on one device your team opens once.
Whichever sources are involved, the same rule decides the primary: pick the instance whose Overview you want to see first. The primary's Overview becomes the front page and the other instances sit beside it as tabs. Nothing is lost either way — the front page simply follows the primary.
Edge Agent + a vendor cloudThe most common case.
A device is discovered on the network by the Xyte Edge Agent and is also reported by the vendor's own cloud — a Q-SYS camera in Q-SYS Reflect, for example, or a Poly bar in Poly Lens.
For many models the Edge Agent contributes reachability — is it up, how does it respond to a ping — while the vendor cloud contributes what the device reports about itself. Where that holds, the vendor cloud is usually the side you want in front.
Edge Agent is the richer sourceThe reverse also happens. For a network switch, a DSP or a PDU with a full Edge driver, the Edge Agent may read far more than the vendor's cloud does — port-level PoE, CPU and memory, temperature, fan state — while the cloud record carries little beyond presence.
Here the Edge instance is the richer side.
Two cloudsA room system can arrive from the vendor's connector and again from the platform it runs — a Crestron room reported by the Crestron connector and as a Zoom Rooms instance, or a device also monitored through Domotz.
Neither is obviously richer here; the two simply describe the device differently. Choose by which view your team works in day to day.
Merging and child devices
Merging works on one device at a time — it joins duplicate records of the same device. It does not act on that device's child devices, and there's no setting to make them follow the parent automatically — merging is always per device, by design.
So if you merge a parent that has child devices — a Q-SYS Core, a Logitech room system, or any parent with children (Dante endpoints, a DSP processor, and so on) — only the parent's own duplicate records are merged. The children are left as they are: each stays its own device, still listed under the parent in the hierarchy. A child isn't a duplicate of its parent, so there's nothing to merge it into.
You'd only merge a child if that same child was also brought in through another source. In that case you merge the child's records on their own, exactly like any other device.
Licensing: this never inflates your count. A child with no duplicate is a single device either way — merging only ever combines duplicates into one.
Merged device status
A merged device has one overall status, combined from its instances (symmetric — order doesn't matter).
Legend: 🟢 OK · 🟡 Warning · 🔴 Error · ⚫ Offline · ⚪ Never seen · 🟣 Connector disconnected
| A \ B | 🟢 OK |
🟡 Warn |
🔴 Error |
⚫ Offline |
⚪ Never |
🟣 Disconnected |
|---|---|---|---|---|---|---|
| 🟢 OK | 🟢 OK | 🟡 Warn | 🔴 Error | 🟡 Warn | 🟢 OK | 🟢 OK |
| 🟡 Warn | 🟡 Warn | 🟡 Warn | 🔴 Error | 🟡 Warn | 🟡 Warn | 🟡 Warn |
| 🔴 Error | 🔴 Error | 🔴 Error | 🔴 Error | 🔴 Error | 🔴 Error | 🔴 Error |
| ⚫ Offline | 🟡 Warn | 🟡 Warn | 🔴 Error | ⚫ Offline | ⚫ Offline | ⚫ Offline |
| ⚪ Never | 🟢 OK | 🟡 Warn | 🔴 Error | ⚫ Offline | ⚪ Never | 🟣 Disconnected |
| 🟣 Disconnected | 🟢 OK | 🟡 Warn | 🔴 Error | ⚫ Offline | 🟣 Disconnected | 🟣 Disconnected |
In short: Error always wins; among live statuses (OK / Warning / Device offline) a mismatch resolves to Warning; passive statuses (Never seen, Connector disconnected) defer to any live status, and Connector disconnected outranks Never seen when all instances are passive.
Splitting
Open the merged device → Split → confirm. It separates back into standalone devices.
Deleting a C2C connector, Edge Agent, or merged device
If you delete a C2C connector or Edge Agent and one of its devices is part of a merged device, the merge is split. Xyte warns you and shows the impact before you confirm.
If you delete the merged device itself, all instances in the merged device are deleted. To delete only one instance, split the merged device first, then delete the standalone device.
Audit log
Merge and split actions are recorded as audit events — for example "Merged devices: [device 1] and [device 2]" or "Split device [primary] into [primary] and [device 2]." To access this change history for your organization, contact [email protected].
Need to merge a lot of devices?
Merging is a manual process, one set at a time. If you have a large number of duplicate devices to merge, you don't have to do it all yourself — reach out to [email protected] and we'll be happy to help.
Updated 11 days ago
