THE CONNECTIONS WIDGET IS AVAILABLE WITH SMARTSERVER THE CONNECTIONS WIDGET IS AVAILABLE WITH SMARTSERVER 3.3 AND HIGHER.

You can connect the outputs of one or more source datapoints to the inputs of one or more destination datapoints. You can use these connection to propagate changes from your source datapoints to your destination datapoints. For example, you can create a connection between a multiple light switches and occupancy sensors to multiple lighting controllers so that when you turn on any of the switches or trigger any of the motion detectors, the lights automatically turn on, and when you turn off any switch or leave the occupancy area, the lights turns off.   You can create connections containing a mixture of data point types. 

You can define connections in one of the following ways:

• Using the Connections widget. This method is the primary means for defining, creating, editing, and deleting connection templates and deploying connections, as well as importing and exporting connection files (a connection file is a CSV file defining one or more connection rules for datapoints). The Connections widget is available with SmartServer 3.3 and higher. See Creating Connections Using the CMS Connections Widget for more information.
  
  

• Manually creating a connection file and importing the file using the Connections widget. See Creating a Connection (CON) File Manually for more information on how to manually create the connection file. See the Exporting / Importing Connection Definitions section in Creating Connections Using the CMS Connections Widget for more information on how to import the file using the Connections widget.

If connections fail to work, see Troubleshooting Issues with Connections for next steps.

This section consists of the following:

Connections Overview

You can define connections with connection templates.  A connection template contains rules that specify how an update from one or more output datapoints is automatically propagated to one or more datapoint inputs. Each datapoint rule in a connection template can be a source or destination datapoint, and each datapoint in a connection template can be specified as fixed or context relative. Each connection template has a unique connection Template Name that you can use to reference the connection template in the SmartServer CMS user interface or IAP/REST API. You can include a datapoint in multiple connection templates. 

You can create a connection template with one or more source and destination datapoints and then deploy the connection template to your devices. Each connection template has a unique name. There is one rule or entry (connection rule) for each used datapoint in the connection template. If all the source and destination datapoints are the same datapoint type, then defining a connection template is relatively straight-forward. Source and/or destinations transforms may be needed in order to support different datapoint types (e.g., making a connection between a scalar datapoint to a structured datapoint), datapoints that have different localization (i.e., some values in Celsius and others in Fahrenheit), or to limit the datapoint values sent from the sources to the destinations. 

You can specify datapoints as fixed or relative datapoints. Fixed datapoints use the device name and datapoint instance names, and are used to specify a specific datapoint on a specific device. Relative datapoints use the device type and datapoints XIF names, and are used to create multiple connections based on context (/wiki/spaces/TEMP/pages/1479424Defining and Using Contexts) or device types.

The /wiki/spaces/TEMP/pages/1478027 Datapoints widget (called the Datapoint Browser widget for SmartServer 3.3 and prior releases) shows the datapoint instance names, but it can also show the datapoint XIF names when viewing Show detailed properties. The Datapoint Properties widget displays the datapoint XIF names.

...

Defining Connection Types 

If you have connections with at least one non-LON interface for source or destination, then you need to configure monitoring using either the CMS Datapoint Properties widget or a Node-RED IAP Input Node for the source datapoints in order for the connections to work.

The sections that follow do not apply if you have connections with at least one non-LON interface for source or destination, and if you do not have any LON devices or connections with only LON devices.

...

...

See Defining Datapoint Properties for more information on how to set up monitoring using the Datapoint Properties widget or Creating Sequence of Operations for more information about how to use Node-RED IAP Input Nodes.

Defining Connection Types (Connections with only LON Devices)

The following information regarding connection types is for connections only between LON devices.

There are two kinds of connections: point-to-point and LON peer-to-peer.

Point-to-point connections allow you to connect two datapoints from devices using different protocols (e.g., Modbus to LON). Point-to-point connections are used for any connections that include at least one non-LON device. Only point-to-point connections are only allowed in IMM.

Peer-to-peer connections are between LON devices only and only available in DMM. If you are using IMM, then peer-to-peer connections are created by IzoT CT or IzoT Net Server. The SmartServer does not create peer-to-peer connections in this mode.

For LON devices, if the SmartServer is configured for DMM, then the SmartServer can create either peer-to-peer or point-to-point connections depending on whether the datapoints are similar types or not, and whether the connection rule map, transform, presets or localization are specified. Specifying any map, transform, preset or localization for any rule in the connection template can make the connection a point-to-point connection. If you are using IMM, then you need to make sure all connection between LON devices are point-to-point connections. To guarantee that these LON connections are point-to-point, you can add a map formula "{"$":"$"}" to the connection template.

All protocols (i.e., Modbus, BACnet, IOX, LoRaWAN, EnOcean) use point-to-point connections. LON to the other protocol is always point-to-point, but can implement the following:

• IMM (point-to-point connection only) – only point-to-point connections can be used otherwise the connection will not work. If map is not being used, then you can use a map formula of "{"$":"$"}" to guarantee that the connection is point-to-point.
  
• DMM (peer-to-peer connection) – datapoint updates happen faster in this case. The datapoint types have to match, and the source datapoints must have the same formulas and settings as the destination datapoints.
  
• DMM (point-to-point connection) – datapoint types are a different. A map formula is specified, or at least one of the following are different between source and and destination: transform, presets, and localization.
  

...

All point-to-point connections require that you to set up monitoring, which can be polled or event-driven updates. Monitoring (polled and event-driven) updates are typically defined using the Datapoint Properties widget, but you can also enable monitoring in a Node-RED IAP input node, or an Internal Device.

Event-driven updates can be used for BACnet devices configured for COV, and in DMM for LON devices. 

Point-to-Point Between Edge Devices

Point-to-Point connections can be used to convert data from different protocols, different datapoints types (scalar to structure, or structure to scalar) using a connection definition map, or localization parameters. You can also specify only certain values to be sent to the destination datapoint using presets (e.g., ON or OFF). Connection rules that use map, presets, or localization are point-to-point connections. 

Point-to-point connections rely on the SmartServer receiving source datapoint updates. In order to get datapoint updates, you typically configure the datapoint properties for all the datapoints that you use for a connection using the Datapoint Properties widget (or DLA file), and set up monitoring (polling or event-driven). Updates will also occur and can be monitored on the /wiki/spaces/TEMP/pages/1478027 Datapoints widget (called the Datapoint Browser widget for SmartServer 3.3 and prior releases) as it receives updates, or any other application that does on-demand GETs.

Peer-to-Peer LON Connection (IMM only)

...

This section does not apply to non-LON interfaces.

If you are using IMM, then peer-to-peer connections are created by IzoT CT or IzoT Net Server. The SmartServer does not create peer-to-peer connections in this mode.

Peer-to-Peer LON Connection (DMM only)

...

This section does not apply to non-LON interfaces.

Peer-to-peer connections are used in DMM only when LON devices are used in the connection template and the connection template datapoints use the same datapoint type and none of map, transform, presets, or localization are specified. For peer-to-peer connections, all connection information is configured in the LON edge devices, and any change to the source datapoint value will be sent automatically to the destination devices without any interaction by the SmartServer. Peer-to-peer connections are processed faster than point-to-point connections since they only involve the SmartServer to create the connection, or if the connection is routed through the SmartServer. Peer-to-peer connections also allow you to reduce the EPS (events-per-second) bandwidth since you to not need to setup monitoring for the source datapoints. 

Peer-to-Peer LON Connection Service Types (DMM only)

...

This section does not apply to non-LON interfaces.

Service types for LON connections are described below:

• 1:1 connection to the SmartServer – these bindings are added to the edge device address table with the subnet/node of the destination.
  • The default service type is acknowledged data.
    
    
• 1:n connection (FAN OUTs) – a broadcast address table entry is used for these connections.
  • If all destinations are in the same subnet, a subnet broadcast address table entry is used. If not all destinations are in the same subnet, a domain-wide broadcast address table entry is used.
  • The default service type is unacknowledged, repeated.
    

...

NOTE: The following service types are used for connections:

...

• • unacknowledged,

...

• • repeated.
    
    

• PL repeating – a 1:1 connection to the local LON network interface of the SmartServer is set up for source data points of a binding that cannot reach destinations because the attenuation is too great. (This also includes the proxy chain back to the SmartServer if the device containing the source data point is located in a remote segment.) Network variable updates are sent by the LON network interface as domain-wide broadcast messages with the same content as the received message.
  • The default service type is unacknowledged, repeated. 
  • The timing parameter for the TX timer is 512ms, and the number of retries is three.
    

...