Device Coordination and Shared Targets

Device sharing lets data from other Edge-EMS Builder nodes participate in local calculations and strategies. Shared targets currently use a directional “local device → one target device” model, which can be combined into aggregation, bidirectional, or multilevel coordination.

Three configuration objects

Object	Purpose
Device information	Identifies a node by a unique device code, recording its network address and whether it is the local device
Sharing configuration	Selects local points and the sharing interval
Shared target	Specifies one receiving device and binds one or more sharing configurations

The local device initiates sharing; no slave-device list is required. Create multiple targets to send to multiple devices. When multiple nodes send to one aggregation node, configure the appropriate target on each sender.

Configuration order

1. Maintain device information on participating devices, confirming the local-device flag and unique device codes.
2. Create a sharing configuration on the sender, select points, and configure the CRON schedule.
3. Create a shared target pointing to the receiver and bind the configurations to send.
4. Check the shared points, source devices, and latest values on the receiver.

For bidirectional sharing, configure both ends separately. Multilevel aggregation can calculate local aggregate metrics from received data, then share those metrics upstream.

See Device coordination configuration for detailed steps and the shared target reference for field descriptions.

Data identity and calculation

Shared data carries its name, alias, and unit. The same dataKey may come from different devices, so specify the device code when querying. Do not concatenate cache keys manually.

-- Replace both demo_edge and demo_power with actual codes
local localPower = tonumber(${demo_power})
local remotePower = tonumber(${[demo_edge]demo_power})
if not localPower or not remotePower then return "__Null__" end
return localPower + remotePower

Historical queries, group mappings, and control logs should retain the same source identity.

Remote control

Trigger actions can send commands to remote writable points by device code. Specify the remote point’s actual data type; for example, use Collection for an acquisition point:

return {buildSlaveWriteMap("demo_edge", "Collection", "demo_setpoint", 10, nil, nil, false)}

Sending a request does not mean the device has executed it. Check permissions, device acknowledgments, execution-side logs, and point readback. See Device control logs.

Status and network recovery

Device status can participate in strategy decisions. When using remote values, also check communication status and data freshness. Device sharing requires network reachability between nodes: device codes identify devices, and IP addresses provide connectivity.

In supported Linux network environments, the local device can use an online device’s network when its own external network is unavailable, switching back when direct connectivity recovers. This includes sharing over the same network interface. This capability depends on site routing and permissions and should be verified on actual devices.

When replacing a receiving node, update the shared target’s target device code. If only the address changes, update that device’s information and check connectivity and bindings. For batches of similar devices, generate configuration with UDE or use the device sharing Skill.