Defining Datapoint Connections (Release 3.0-3.2)

For SmartServer 3.3 and higher, see Setting up Datapoint Connections.

For SmartServer 2.9 or prior, see Defining Datapoint Connections (Release 2.9)

You can define connection templates that specify how datapoint outputs are connected to datapoint inputs. A connection template, which is made up two or more rules, specifies how an update from one or more datapoints is automatically routed to one or more datapoint inputs. You define connection templates in a connection requirements (CON) file. The file is a manually-generated CSV file defining one or more connection rules for datapoints. A connection rule comprises two or more lines in the CSV file. All lines in the connection file that apply to the same connection rule will have the same Template Name. Each connection template (Template Name) specifies one or more source datapoints and one or more destination datapoints.

This section consists of the following:

Overview

Each time a new CON file is added, the new rules (based on Template Name) are checked against the existing rules. A rule that is in the existing and new CON file is unchanged. Any new rule that is added, and any old rule that does not exist in the new CON file, is deleted. Therefore, in order to add, change, or delete connections, a new CON file with all the desired connections needs to be imported. To clear all connections (see Clear Connections in this section), import a connection file with the header and parameter name, but without any defined connection rules. 

Both connections and datapoint properties (DLA) files have presets and localization. These files are similar to each other, but not interchangeable. For example, if you want to create a connection file that limits which datapoint values are sent to the destination using presets, you cannot use a preset defined in the datapoint properties. You must create the preset in the CON file.  

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 (Modbus to LON). Peer-to-peer connections are between LON devices and only available in DMM.   

Point-to-Point connections can be used to convert data from different protocols, different datapoints types (scalar to structure, or structure to scalar) using the CON file map, or localization parameters. You can also specify that only certain values be sent to the destination datapoint by 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 datapoint updates. In order to get datapoint updates, you typically configure the datapoint properties for all the datapoints 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 Datapoint Browser widget as it received updates, or any other application that does on-demand GETs.

For LON devices, if the SmartServer is configured for DMM, the SmartServer can create either peer-to-peer or point-to-point connections.  Any connection rule in which only LON devices are used and there is no map, preset, or localization specified on the source or destination will cause the SmartServer to create a peer-to-peer connection. If map, preset, or localization is specified, then the SmartServer will use point-to-point. In this case for DMM, the SmartServer will automatically create a peer-to-peer binding between the source LON device and the SmartServer, and will update the destination datapoints if any source values change. This means that you do not need to add an event or polling for the source LON devices using the Datapoint Properties widget as the event update is automatically created by the SmartServer. For IMM only point-to-point connections are created.

For peer-to-peer connections (only supported in DMM), all connection information is configured in the LON edge devices, and any change to the source datapoint 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. 

Refer to the following table regarding supported datapoint connection types for various protocols:


LONModbusBACnetIOX
LON1,2111
Modbus1111
BACnet1111
IOX1111

1 = point-to-point
2 = LON peer-to-peer

Creating a Connection (CON) File

Requirements

A CON file contains the following embedded metadata tags anywhere in the file, and typically in the first line:
#filetype,con

CON files are CSV files categorized by the extension .con.csv, or .con.csv (not case sensitive). The #filetype tag is equal to con (not case sensitive) and is identified by its file name. A CON file can be imported with any of the mentioned file extensions, and must use CSV formatting. In order to be able to double-click the file and view it in Excel, you should use the .csv or .con.csv extension. The file will be most easily identified using .con.csv.

The following examples are provided:

  • Example formulas
  • Example CSV files

1. Example formula – the following formula can be added to a CON file first, by opening the file in Excel, and then by pasting the file formula.
    This example formula appears in Excel such as:

{"state":{"transform":"$ ? 1 : 0"},"value":"$"} 

The corresponding CSV file format for the above formula is to double all double quotes, and add double quotes at the beginning and end of the formula. This is handled automatically if you add the formula above using Excel. If you change the CON file using notepad you will need to add the CSV format as shown below. 

If you open the file in a text editor (i.e., notepad), you will see the following:

"{""state"":{"transform"":""$ ? 1 : 0""},""value"":""$""}" 

2. Example CSV files – already show converted formulas. Just copy the CSV file data to a text editor (i.e., notepad) and save it with a .csv extension (or ..con.csv). You can then view the CON file in Excel.

Connection (CON) File Parameters

A CON file contains the following columns (not case sensitive, and parameter columns can be in any order):

Parameter                      Description
Template Name

Connection unique identifier. All connection filters with the same template name define a connection template. There should be at least one source and at least one destination entry with the same Template Name.

Reference Type

Specifies the type of datapoint reference. Values may be Fixed or Relative (case insensitive). If Reference Type is not specified, it is assumed to be FixedIf a Device Name is specified then Reference Type is assumed to be Fixed. If a Device Name is not specified then Reference Type is assumed to be Relative.

Fixed datapoint means that you are specifying the device name.  Contexts, Target Type, Target Name, and Device Type can be blank.

Relative datapoint means that you are specifying a device type based on a context.  

Contexts

List of full context paths that the template applies to, with optional wildcards for any level of the context hierarchy. Context paths are separated with a semicolon.

If contexts are specified for a fixed datapoint reference, and the context does not match any of the contexts containing the device specified with the device name, the CMS will display a warning message.

If a connection template contains context-relative datapoints, then contexts should be defined for that template, otherwise no connections will be created. Only the first Contexts entry that is found for a template is used (others are ignored). The CMS will always export an empty value for the context for a specified context that does not match one of the contexts of the device specified by the device name.

Target TypeTarget Type is used when Reference Type is Relative. Valid values are: blank, none, campus, campus area, building, foor, floor area, or room (case insensitive; spaces and separators are ignored).
Target Name

Target Name filter is used with Target Type.

Example: The Target Type is room and you have the following room names: boiler, kitchen, office A, office B. If you specify office, then the connection rule only applies to office A and office B.

Device NameDatapoint XIF name. This parameter must be specified for a fixed datapoint. This parameter is ignored with warning for context-relative datapoints. The CMS will always export an empty value for a context-relative datapoint reference. 
Device Type

Device Type Name. This field is required for a context-relative datapoint reference. This field is optional for a fixed datapoint reference.

If the Device Type is specified for a fixed datapoint reference and the Device Type does not match the Device Type of the device specified with the Device Name, then the CMS will display a warning message. The CMS will always export an empty value for the type for a specified device type that does not match the device type of the device specified by the device name.

Datapoint Name

Datapoint XIF name.

Note: Each datapoint has a datapoint instance name and a datapoint XIF name. The datapoint XIF name is shown in the CMS Datapoint Browser widget details view and in the Datapoint Properties widget. This parameter specifies the datapoint XIF name.
DirectionSource or Destination. If the field is not specified, or is specified but empty, the direction will be source for non-writable datapoints and destination for writable datapoints.
Map

Mapping formula (JSON object) where $ is source value. Used for Source Map only. For destination mapping use Localization or Preset Map.  $ is source value and map formula.

Examples:

Scalar (temperature in Celsius to temperature in Fahrenheit):

{"transform": "$ * 1.8 + 32"}

Map formula to go from scalar to  structure datapoint (SNVT_count to SNVT_Switch which has two fields, state and value):   

{"state":{"transform":"$ ? 1 : 0"},"value":"$"} 

If doing a FAN IN connection, and the source datapoints have different map formulas, then you need to create separate rules for each source datapoint and include the same list of destination for each rule.

(optional parameter)

Presets

Presets that both the source and destination must contain in order for the data to be transferred.

Source and destination can have a different list of presets, but source value is only sent to destination if both source and destination have matching presets. All other values that do not have matching presets are not sent. To do destination mapping, do the map as part of the destination preset formula or use destination.

"onlyPreset" - should always be set to true, means only connections with matching source and destination presets are transferred to destination. 

(optional parameter)

Repeat Presets

If set to true, all subsequent source or destinations use the same localization.

(optional parameter)

Localization

Localization formula: For source $ is the source value, for destination $ is the connection value, and the localization formula value is what the CMS Datapoint Browser shows. 

Examples:

Source localization for scalar (SNVT_count to SNVT_temp_p in deg F):

Source localization: {"transform": "$ * 1.8 + 32"}

Destination formula to go from scalar to  structure datapoint (SNVT_count to SNVT_Switch):   

{"state":{"transform":"$ ? 1 : 0"},"value":"$"} 

{"value":{"transform": "$ + 10"}, "state":{"$ > 0 ? 1 : 0"}}

(optional parameter)

Repeat Localization

If set to true, all subsequent source or destinations use the same localization.

(optional parameter)

Note: CON presets and localization are independent of Datapoint Properties (or DLA file) presets and localization, and only apply to the connections. Datapoint Properties (or DLA) presets and localization do not apply to connections. Converting a temperature datapoint from degrees Celsius to degrees Fahrenheit is typically done through the Datapoint Properties (or DLA file) and not the CON file. 

Using Presets, Localization, and Map

Presets and localization can be applied to source and destinations datapoints. Leave the cell blank in the CON file for any rule not using preset, localization or map.

Map, presets and localization is typically only used if the datapoint type is different. That is, if both the source and destination datapoints are the same datapoint type, then in most cases you would not use map, preset, or localization for the connection rules.   

Map, preset and localization allow you to create a connection that translates values from one datapoint type to another (e.g., SNVT_switch to SNVT_count), or to manipulate the source or destination values. For example, if the source and destination datapoints are SNVT_count, but the source has a range of -100 to 300 and the destination only allows a range of 0 to 100, you can use use map or localization to change the allowed destination range.

The following scenarios are supported:

Localization
(Source,
Destinations, or Both)

Presets
(Source,
Destinations,
or Both) 

Map
(Source only)

yesnono
noyesno
nonoyes
yesyesno
yesnoyes
noyesyes
yesyesyes

The order of the transformation for the source datapoint is IAP value → Localization → Presets → Map.

  • If the source localization is defined, the datapoint is transformed to a localized value. 
  • If the source presets is not NULL, the IAP value (or the local value) is transformed to a preset value.
  • If the map is defined, the last transformation value, which could be a preset value, a local value or an IAP value, is transformed according to the map rules.

The reverse transformation order for the destinations datapoint is Presets → Localization → IAP valuePresets (if defined) are specified using the local values. The localization rule must be specified to reverse transform the preset value to the IAP value.

The map is specified in source and will be applied to the source datapoint for all destinations. Only one map per connection rule ID is supported. Map should be left empty for destinations as it is not supported. Mapping for individual destinations is defined in presets or localization.  

If the datapoint value does not map to any of the presets, then the value is not sent if the onlyPreset property is set to trueOtherwise, the native value will be sent instead. If both transformation map and presets are defined on the source datapoint, then the transformation map is ignored. Only one preset can be defined in the datapoint source. If you have more than one source that has different presets, you have to split it into different connection objects. 

The CON file has an option to specify whether to skip sending datapoint values if the presetValue is not defined or the source presetValue does not map to any of the destination presets.

Most BACnet and Modbus datapoint types are scalars values (only one number like temperature). LON datapoints can be scalar or structured datapoints. Structured datapoints have fields in which each field represents a value (e.g., SNVT_switch has a state and value fields).

For structured destination datapoints you need to specify result for all fields. That is, if you have a five field destination, then the formulas you use must specify a destination value that has all five fields.

Understanding Connection Operations

Source value → Source Transform (by source map, preset, or localization) → Connection value  → Destination Transform (by destination preset or localization) → Destination value.

  1. There can be FAN INs (multiple sources) for one connection.
    1. If the source map, preset, and localization are the same for all source datapoints, then you can use one connection rule.
    2. If the source map, preset, or localization is different, then you need to specify the source in separate rules and duplicate the destination datapoints for both.
    3. If you have some source datapoints with the same map, preset, or localization, then those can be in one rule and the other source datapoints need to be in separate rules.

  2. There can be FAN OUTs (multiple destination) for one connection.

  3. There can be FAN INs and FAN OUTs for one connection.
    1. If the source map, preset, and localization are the same for all source datapoints, then you can use one connection rule.
    2. If the source map, preset, or localization is different, then you need to specify the source in separate rules and duplicate the destination datapoints for both.
    3. If you have some source datapoints with the same map, preset, or localization, then those can be in one rule and the other source datapoints need to be in separate rules.

Defining LON Connection Service Types

Service types for LON connections can be defined as described below:

  • 1:1 connection to the SmartServer – these bindings are added to the address table with the subnet/node of the destination.
    • The default service type is acknowledged data.
    • The timeout time of the associated channel is entered as the timing parameter for the TX timer. The number of retries is taken from the associated channel parameter retryCount. The smallest value from the timeout parameter of the associated channel, or 64ms, is used as the repeat timer.

  • 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.
    • The timeout time of the associated channel is entered as the timing parameter for the TX timer. The number of retries is taken from the associated channel parameter retryCount. The smallest value from the timeout parameter of the associated channel, or 64ms, is used as the repeat timer.

NOTE: Valid selections for the serviceType parameter in the connection section of the forward are as follows:

  • For 1:1 connections: acknowledged, repeated, or unacknowledged.
  • For 1:n connections: unacknowledgedrepeated.
  • 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.

Formula Examples

$ represents the input of a source or destination transform and specifies the complete datapoint value. For structured datapoints, like SNVT_switch, specify $.<field name> to access a datapoint field value.

For example:

  • To access the SNVT_switch state field, specify: $.state
  • To access the SNVT_switch value field, specify: $.value

You need to use a transform function in the formula any time the formula uses multiplication, division, addition, subtraction, if-then, math formula, or math function.

Math Functions

Math functions can be applied to datapoint values, such as limiting the range of the datapoint value.

These example formulas can be copied into an Excel cell.

FunctionFunction NameDescriptionFormula
min(x,y)Min 

Min is used to limit a maximum value

(e.g., to limit a scalar value high value to 100 or lower)

{"transform":"min($, 100)"}
max(x,y)Max

Max is used to limit a minimum value

(e.g., to positive numbers)

{"transform":"max($, 0)"}
sqrt(x)Square RootCalculates the square root of a value{"transform":"sqrt($.value)"}

Example formula to limit a datapoint value to a value between 10 and 100:

{"transform":"min(max($, 0),100)"}

Source Map Formulas

Destination map is configured by using preset map or localization.  

These example formulas can be copied into an Excel cell (always leave destination map blank). For the examples below, SNVT_switch is a structured datapoint having a value with two fields (i.e., state and value). 

Datapoint formatDatapoint typeDirectionFormulaNotes
Scalar to ScalarSNVT_count to SNVT_countSource{"$": "$"}Special case where value is not modified (see note 1).
Scalar to ScalarSNVT_count to SNVT_countSource{"transform":"$ * 2"}(see note 2)
Scalar to ScalarSNVT_count to SNVT_countSource{"$": {"transform":"$ * 100"}}(see note 2)
Scalar to StructuredSNVT_count to SNVT_switchSource{"state":{"transform":"$ ? 1 : 0"},"value":"$"}

Converting Scalar Datapoint to Structure Datapoint (SNVT_switch) (see note 2).

The destination state field translation requires logic so you need to use a transform formula  (see note 2).

The destination value field uses the complete value of the source datapoint so it does not need to use a transform formula. 

Scalar to StructuredSNVT_count to SNVT_switchSource{"state":{"transform":"$ ? 1 : 0"},"value":{"transform":"min(max($, 10), 100)"}}

Converting Scalar Datapoint to Structure Datapoint (SNVT_switch) and limits destination value between 10 - 100.

The destination state field translation requires logic so you need to use a transform formula  (see note 2).

The destination value field translation requires a math formula so you need to use a transform formula  (see note 2). 

Scalar to StructuredSNVT_count to SNVT_switchSource{"state":{"transform":"$ ? 1 : 0"},"value":{"transform":"$ * 5"}}Converting Scalar Datapoint to Structure Datapoint (SNVT_switch) (see note 2).
Scalar to StructuredSNVT_count to SNVT_switchSource{"state":{"transform":"$ > 5 ? 1 : 0"},"value":{"transform":"$ * 5"}}State: if source value > 5 then connection value = 1 else connection value = 0.
Structured to StructuredSNVT_switch to SNVT_switchSource{"$": "$"}Special case where no fields are modified (see note 1).
Structured to StructuredSNVT_switch to SNVT_switch

Source

{"state":{"transform":"$.state ? 1 : 0"},"value":{"transform":"$.value * 5"}}Special case using only one unmodified field (see note 1). 


Structured to ScalarSNVT_switch to SNVT_countSource{"$": "$.value"}Special case using only one field (see note 1).
Structured to ScalarSNVT_switch to SNVT countSource{"transform":"$.value * 2"}Uses multiplication, therefore you need to use transform (see note 2).
Note 1: This formula can only be used if the map formula has no multiplication, division, addition, subtraction, if-then, or math formula.  
Note 2: Transform function is required when map formula has multiplication, division, addition, subtraction, if-then, or math formula. 

Presets Formulas

These example formulas can be copied into an Excel cell.

Datapoint formatDatapoint typeDirectionFormula
ScalarSNVT_countSource
ScalarSNVT_countDestination{"$": {"enumeration":{"source": "$", "map": {"ON": 100,"MID": 50, "OFF": 0}}}}
Structured SNVT_switchSource{"$": {"transform": "$.value == 100 && $.state == 1 ? 'ON' : $.value == 50 && $.state == 1 ? 'MID' : $.value == 0 && $.state == 0 ? 'OFF' : ' ' "}}
StructuredSNVT_switchDestination{"$": {"value":{"enumeration":{"source": "$", "map": {"ON": 100,"MID": 50,"OFF": 0}}},"state":{"enumeration":{"source":"$","map":{"ON": 1,"MID": 1,"OFF": 0}}}},"onlyPreset": true}

Localization Formulas

These example formulas can be copied into an Excel cell.

Datapoint formatDatapoint typeDirectionFormula
ScalarSNVT_countSource{"transform": "$ * 1.8 + 32"}
ScalarSNVT_countDestination{"transform": "$ * 2"}
Structured SNVT_switchSource{"value":{"transform": "$.value + 10"},"state":{"transform": "$.state"}}
StructuredSNVT_switchDestination{"value":{"transform": "$.value * 2"},"state":{"transform": "$.state"}}
StructuredSNVT_switchDestination{"state":{"transform":"$ ? 1 : 0"},"value":{"transform":"min(max($, 10), 100)"}}

Connection (CON) File Examples

Using map, presets, and localization in datapoints is optional. A datapoint can have map only (Sources), presets only, localization only, have all three map, presets and localization, or neither. When both presets and localization are used, the presets map are typically configured based on the localization value. Therefore, when an update is received, the value needs to be localized first before mapping to a preset string. And, when a preset string is entered, the map value needs to be transformed using the revert transformation rule to get the native value. 

To use the example files shown below, copy the text to a text editor like notepad, then save as text, and finally change the extension to .con.csv. At this point, you can view the files using Excel.

Connection rules use a Fixed (specify Device Name) or Relative (Specify Device Type) Reference Type

The connection rules that specify Device Type require you to assign the device to a Context or Target Type (e.g., Floor or Room). Contexts are created and viewed using the Planning widget and devices are assigned to a context using the Device widget.

When creating connection rule for structured datapoints, you need to specify $ which means entire value, or specify the preset or transform for each field. That is, you cannot create a rule that specifies a transform for just a specific field. It is specified for either the entire value $ (which means all the fields), or you have to create separate transforms for each field.

The first example demonstrates a LON peer-to-peer connection, which is only available for LON devices (DMM mode only). All other examples show point-to-point connections ,which are used for all protocols including BACnet, Modbus, and LON connections.

Fixed versus Relative Reference Types 

The following CON file example shows a connection with the source datapoint using a fixed reference type, and two destination datapoints (one fixed and one relative reference type). For fixed reference type, the device name is specified. For relative reference type, you specify the context and device type.

#filetype,con
Template Name,Reference Type,Contexts,Target Type,Target Name,Device Name,Device Type,Datapoint Name,Direction,Map,Presets,Repeat Presets,Localization,Repeat Localization,Priority
C1,Fixed,,,,PulseGen1,,device/0/nvoCount,Source,,,,,,Normal
C1,Relative,Campus/San Francisco/Floor 2/Room 1,,,,teslaTempTester,device/0/nviCount[0],Destination,,,,"{""transform"": ""$ ""}",,
C1,Fixed,,,,PulseGen2,,device/0/nviCount,Destination,,,,"{""transform"": ""$ * 2""}",,

LON Peer-to-Peer Connection

Note: Used for DMM only. Source and destination datapoints are the same datapoint type.

The following CON file example (Device Name specified) shows peer-to-peer connection (source and destination devices are LON devices) the format without using map, presets, and localization.

#filetype,con
Template Name,Reference Type,Contexts,Target Type,Target Name,Device Name,Device Type,Datapoint Name,Direction
24,,,,,PulseGen1,,device/0/nvoSwitch2,Source
24,,,,,PulseGen2,,device/0/nviLamp2,Destination
25,,,,,PulseGen2,,device/0/nvoSwitch2,Source
25,,,,,PulseGen1,,device/0/nviLamp2,Destination

With Source Map

The following CON file example (Device Name Specified) shows the format for map, presets, and localization, when only map specified.

#filetype,con
Template Name,Reference Type,Contexts,Target Type,Target Name,Device Name,Device Type,Datapoint Name,Direction,Map,Presets,Repeat Presets,Localization,Repeat Localization
22,,,,,PulseGen1,,device/0/nvoPulseOut,Source,"{""state"":{""transform"":""$ ? 1 : 0""},""value"":""$""}",,,,
22,,,,,PulseGen1,,device/0/nviLamp1,Destination,,,,,
23,,,,,PulseGen2,,device/0/nvoPulseOut,Source,"{""state"":{""transform"":""$ > 0 ? 1 : 0""},""value"":""$""}",,,,
23,,,,,PulseGen1,,device/0/nviLamp2,Destination,,,,,

With Two Sources and One Destination (Different Source Mapping)

Note: Requires two source rules, one for each destination.

The following CON file example shows two sources that are connected to, and one destination, with each source having a different mapping transformation. In this case, you need to create multiple rules (i.e., separate rules for each mapping transformation), or specify the mapping rules in Presets column, where presets and the mapping rules are defined, similar to the following:

  • create a rule for sourceA/destA
  • create another rule for sourceB/destA
#filetype,con
Template Name,Reference Type,Contexts,Target Type,Target Name,Device Name,Device Type,Datapoint Name,Direction,Map
8,,,,,NcMultiSensor112.860,,Switch/0/nvoValue,Source,"{""value"": {""transform"":""sqrt($.value)""}, ""state"": {""transform"": ""$.state ? 0 : 1""}}"
8,,,,,NcMultiSensor112.860,,Switch/0/nviValueFb,Destination,,
9,,,,,NcMultiSensor112.860,,Switch/0/nvoValue,Source,"{""value"": {""transform"":""3.5*($.value%25)""}, ""state"": {""transform"": ""$.state ? 1 : 0""}}"
9,,,,,NcMultiSensor112.860,,Switch/1/nviValueFb,Destination,,

With Presets

The following CON file example shows the format for map, presets, and localization.

#filetype,con
Template Name,Reference Type,Contexts,Target Type,Target Name,Device Name,Device Type,Datapoint Name,Direction,Map,Presets,Repeat Presets,Localization,Repeat Localization
3,,,,,PulseGen1,,device/0/nvoLamp1,Source,,"{""$"": {""transform"": ""$.value == 100 && $.state == 1 ? 'ON' : $.value == 50 && $.state == 1 ? 'MID' : $.value == 0 && $.state == 0 ? 'OFF' : ' ' ""}}",,,
3,,,,,PulseGen2,,device/0/nviTemp,Destination,,"{""$"": {""enumeration"":{""source"": ""$"", ""map"": {""ON"": 100,""MID"": 50, ""OFF"": 0}}}}",,,
3,,,,,PulseGen2,,device/0/nviLamp1,Destination,,"{""$"": {""value"":{""enumeration"":{""source"": ""$"", ""map"": {""ON"": 100,""MID"": 50,""OFF"": 0}}},""state"":{""enumeration"":{""source"":""$"",""map"":{""ON"": 1,""MID"": 1,""OFF"": 0}}}},""onlyPreset"": true}",,,

With Localization

The following CON file example shows the format for map, presets, and localization.

#filetype,con
Template Name,Reference Type,Contexts,Target Type,Target Name,Device Name,Device Type,Datapoint Name,Direction,Map,Presets,Repeat Presets,Localization,Repeat Localization
3,,,,,PulseGen1,,device/0/nvoLamp1,Source,,,,,
3,,,,,PulseGen2,,device/0/nviLamp1,Destination,,,,"{""value"":{""transform"": ""$.value + 10""},""state"":{""transform"": ""$.state""}}",
4,,,,,PulseGen1,,device/0/nvoHVACTemp,Source,,,,,
4,,,,,PulseGen2,,device/0/nviTemp,Destination,,,,"{""transform"": ""$ * 1.8 + 32""}",
5,,,,,PulseGen1,,device/0/nvoCount,Source,,,,"{""transform"": ""$ * 2""}",
5,,,,,PulseGen2,,device/0/nviCount,Destination,,,,,

With Presets and Localization (One Source and Two Destinations)

The following CON file example shows the format for map, presets, and localization.

#filetype,con
Template Name,Reference Type,Contexts,Target Type,Target Name,Device Name,Device Type,Datapoint Name,Direction,Map,Presets,Repeat Presets,Localization,Repeat Localization
3,,,,,PulseGen1,,device/0/nvoLamp1,Source,,"{""$"": {""transform"": ""$.value == 100 && $.state == 1 ? 'ON' : $.value == 50 && $.state == 1 ? 'MID' : $.value == 0 && $.state == 0 ? 'OFF' : ' ' ""}}",,,
3,,,,,PulseGen2,,device/0/nviTemp,Destination,,"{""$"": {""enumeration"":{""source"": ""$"", ""map"": {""ON"": 100,""MID"": 50, ""OFF"": 0}}}}",,"{""transform"": ""$ * 2""}",
3,,,,,PulseGen2,,device/0/nviLamp1,Destination,,"{""$"": {""value"":{""enumeration"":{""source"": ""$"", ""map"": {""ON"": 90,""MID"": 50,""OFF"": 0}}},""state"":{""enumeration"":{""source"":""$"",""map"":{""ON"": 1,""MID"": 1,""OFF"": 0}}}},""onlyPreset"": true}",,"{""value"":{""transform"": ""$.value + 10""},""state"":{""transform"": ""$.state""}}",

Clear Connections

The following CON file example shows the format to clear all connections (using a connection file with no rules).

#filetype,con
Template Name,Reference Type,Contexts,Target Type,Target Name,Device Name,Device Type,Datapoint Name,Direction,Map,Presets,Repeat Presets,Localization,Repeat Localization