Fix Mango Data Source Copy Device Name Not Renaming

Problem Details

You duplicate an existing data source in Mango (M2M2 or Mango Automation) to stand up a second, identical site inside the same instance. The copy operation succeeds, you rename the new data source, and the point list looks correct - but every point in the copy still reports the original site's identity. Watch lists, point hierarchies, event messages, reports and any export that keys off the point's device name all show the old name, so the two sites are indistinguishable downstream.

Renaming the data source after the copy does not correct it. The rename is accepted, the data source header updates, and the points remain stubbornly attached to the old label.

Root Cause: Device Name Is a Point Property, Not a Data Source Property

In Mango, each data point carries its own Device name field, stored on the point, independent of the data source that owns it. The two values are linked only once:

• When a point is created, the device name is defaulted to the name of the parent data source.
• After creation, the device name is a free-text attribute of the point. Editing the data source name does not propagate back into the points.

A data source copy clones the point definitions verbatim, including their stored device name strings. So the copy inherits the source site's device names, and the later data source rename has no mechanism to touch them.

The practical consequence: Device name + Point name is the pair that most of Mango's UI, watch lists and messaging uses to identify a tag. If you only fix the data source name, you have renamed the container and left the contents mislabeled.

Solution A - Correct Device Names on an Existing Copy

Use this when the duplicate already exists and you cannot redo the copy.

1. Open the data source that was created by the copy and confirm its name is the new site name. Fix it here if not.
2. Open the point list for that data source.
3. Edit the first point and locate the Device name field in the point details settings (the same panel that holds point name, data type and logging settings).
4. Set Device name to the new site identifier. Keep it identical across every point in the data source so watch lists and hierarchies group cleanly.
5. Save, then repeat for each remaining point in the copied data source.
6. Do not change the point names unless the new site genuinely uses different tag names - keeping point names identical across sites makes later view duplication and reporting far easier.

If the copied source has many points, verify the edit set before you start: sort or filter the point list by device name so you can see at a glance which points still carry the stale value, and re-check that filter after the edits to confirm zero remaining.

Solution B - Set the Names During the Copy (Mango Automation 2.0)

Mango Automation 2.0 improved the copy workflow compared with the older M2M2 releases. When you copy a data source in 2.0, the dialog lets you specify the new data source name and the device names before the copy is created. That eliminates the post-copy edit pass entirely.

1. Select the source data source and invoke Copy.
2. Enter the new data source name for the target site.
3. Enter the device name to apply to the copied points, rather than accepting the inherited value.
4. Create the copy, then adjust only the site-specific connection parameters (IP address, slave/unit ID, serial port, poll period) on the new data source.
5. Enable the new data source and confirm points go to a good quality state.

If you are still on an older M2M2 build, this pre-copy naming step is not available and you must fall back to Solution A. Upgrading is the cleaner long-term fix if you expect to replicate sites repeatedly.

Replicating the Graphical View and Watch List

Duplicating the data source is only part of standing up a second site. The presentation layer references points by ID, not by name, so it does not follow a copy automatically.

Procedure for the copied view:

1. Copy the existing graphical view and give it the new site name.
2. Open the copy in edit mode. Each component still binds to the original site's point IDs.
3. Work component by component and reassign the point reference to the matching point in the new data source. Filtering the point selector by the new device name is the fastest way to do this - which is exactly why consistent device names matter.
4. Update any static text, titles or background labels that name the old site.
5. Save and compare both views side by side with live data to confirm no component is still pointing at the original site.

Where you expect to replicate many sites, a data-driven dashboard is a better structural answer than N copies of a static view. Mango's DGLux dashboards let you build one layout and drive it from the point tree, so adding a site becomes a data operation rather than a drawing operation. Static graphical views require a fresh re-point pass for every new site, and that effort scales linearly.

Verification Checklist

1. Data source: New data source name is unique and matches the site convention. Connection parameters point to the new device, not the original.
2. Device names: Filter the full point list by the old device name. The result must contain only the original site's points - the expected original count, nothing more.
3. Point count parity: New data source point count equals the original's. A partial copy shows up here.
4. Live data: Both data sources are enabled and polling; new points show current timestamps and good quality, not stale or unreliable states.
5. Independence test: Disable the new data source briefly. Only the new site's points and view should go stale. If the original site's display reacts, a binding is crossed.
6. Events: Trigger or simulate an alarm on the new site and confirm the event message names the new device, not the original.
7. Watch list / hierarchy: The new points group under the new device name, with no orphans left under the old one.

Preventive Practice

• Set the device name deliberately at point creation instead of accepting the data source default. Once it is explicit and correct, later data source renames are harmless.
• Keep point names identical across replicated sites and let the device name carry the site identity. This makes copied views, reports and exports predictable.
• Rename the data source before creating points in a new source, so the inherited default is already correct.
• Record a short site-commissioning checklist covering data source name, device names, connection parameters, view re-pointing and the independence test above. Copy errors are silent, so verification has to be procedural.

Frequently Asked Questions