Page Comparison

THE DATAPOINTs WIDGET IS AVAILABLE WITH SMARTSERVER 2.5 AND HIGHER. FOR SMARTSERVER 3.3 AND PRIOR, THIS WIDGET IS CALLED THE DATAPOINT BROWSER WIDGET.

...

1. Go to the Edit Datapoint Properties → Info tab (default) and edit datapoint properties as described below.
   
   
   
   

   • Protocol – read-only field with LON, Modbus, BACnet, LoRaWAN, EnOcean, and IAP values

   • Device Type – read-only field with device type name

   • Datapoint XIF Name – read-only field with fully qualified name with block name, block index, and datapoint name
   • Initial Value – initial value for inputs only. If localization is defined, the value should be a local value. If this field is left blank, you will see yellow messages at the top of your dashboard. Click the Show button () to view the value for the selected datapoint as shown in the example below.
     
     
     
     
   • Tags – a list of tags as defined in Datapoint Tags, with each tag specified as <tag name>:<tag value>, allowing you to add tag datapoint values that are forwarded to a data analytics application. Click the Add Tag (Image Modified) button to add tags to datapoints. Key and Value fields appear allowing you to add tags. 
     

     Tags are available with SmartServer 3.6 and higher.
     
     

     
     
     With SmartServer 4.2 and higher, and for IDL-based drivers only (not LON), you can optionally add DBO device and datapoint tags to ev/data using the tag key prefix eit: , which indicates an event identification tag. This tag feature supports Haystack and Google DBO tags and should not be used with equal signs ( = ) or semicolons ( ; ).
     
     • Example:
       
       
       Datapoint Properties widget example
       KEY eit:DBO New Tag = VALUE some value
       KEY eit:DBO DP Name = VALUE Power B
       
       
       IAP/MQ example of ev/data message, which also shows a device eit: tag defined as:
       KEY eit:Device Name = VALUE some device name
       
       

2. Set the Visible option. The Visible option is related to the setting described in the Viewing / Hiding Datapoints in the Datapoints Widget section in Displaying Datapoint Properties.
   

   1. With this option enabled, the datapoint is visible on the Datapoints widget.
   2. With this option disabled, the datapoint is hidden on the Datapoints widget.
      
      
3. Set the Provision Initial Value option.
   
   1. With this option enabled, the initial value is written to the device when the device is provisioned.
   2. With this option disabled, writing the initial to the device is suppressed when the device is provisioned.
      
      
4. Click Update to save the edits.

...

1. Go to the Edit Datapoint Properties → Alarm Type Configuration tab.
   
   
   
   
2. Set the Alarmed Yes/No option to enable alarm monitoring for the datapoint. This feature is available with SmartServer release 2.7 or higher.
   
   
   
   
3. Set the other fields as described below:
   

   • Alarm Name – a text field where you can enter a name for the alarm type definition. If defined, this name appears in the Alarm Type list. Alarm Name must be unique across all alarm types and across all device types for handling alarm assignments.

   • High Warning and Low Warning – datapoint limits for triggering warnings, one for a high value warning and one for a low value warning.

   • High Error and Low Error – datapoint limits for triggering alarms, one for a high value alarm and one for a low value alarm. 

   • High Warning Preset and Low Warning Preset – datapoint presets for triggering warning alarms, one for a high-value warning alarm and one for a low-value warning alarm. This setting requires Alarmed to be Yes; this feature is available with SmartServer release 2.8 or higher.

   • High Error Preset and Low Error Preset – datapoint presets for triggering error alarms, one for a high-value error alarm and one for a low-value error alarm. This setting requires Alarmed to be Yes; this feature is available with SmartServer release 2.8 or higher.
     

     Refer to the table below for examples of alarm settings:

     Alarm	Indication
     High Error = 90	Indicates 90 and above
     High Warning = 75	Indicates 75 and above or values 75 - 89
     Low Warning = 25	Indicates  25 and below or values 11 - 25
     Low Error = 10	Indicates 10 and below

     
     Refer to the table below for Alarm State changes (i.e., yellow pop-up warning and alarm emails sent) based on datapoint value changes (assumes you are not clearing the active Alarms):

     Value	Error / Alarm Description	Event Description
     Value = 50	Starting value, no alarm	No alarm (non-alarm value)
     Value = 60	No alarm	No alarm (non-alarm value)
     Value = 77	High Warning Alarm	Alarm email sent
     Value = 100	High Error Alarm	Alarm email sent
     Value = 80	Stay in High Error Alarm	No change – High Error is more important than High Warning
     Value = 50	Stay in High Error Alarm	No change – High Error is more important than non alarm state
     Value = 20	Low Warning Alarm	Transitioning from High Error/Warning to a Low Error/Warning; changes Alarm state Alarm email sent
     Value = 5	Low Error Alarm	Low Error is more important than Low Warning Alarm email sent
     Value = 50	Low Alarm	No change – Low Error is more important than no alarm state
     Value = 75	High Warning Alarm	Change – Transitioning from Low Error/Warning to a High Error/Warning; changes Alarm state Alarm email sent
     Value = 100	High Error Alarm	Change – High Error is more important Alarm than High Warning Alarm email sent
     Value = 50	Stay in High Alarm	Still in High Error Alarm state
     Alarm considerations: You must manually clear an alarm using the Alarms and Events widget. You will not receive an alarm state change or email notification when the state changes from alarm to non-alarm. You will receive an alarm state change when the state changes from Warning to Error. When the alarm state changes from an Error to Warning at the same level (e.g., High Error to High Warning or Low Error to Low Warning), you will not receive an alarm state change or email notification. You must clear alarms in High Error or Low Error states prior to the value changing from Error to Warning in order to receive an alarm state change and email notification. Alarms in High Error or Low Error states should be investigated before the alarms are cleared.  When the alarm state changes from Low to High or High to Low, you will receive an alarm state change and email notification.

     
     
     

4. If the datapoint is structured, representing more than one value (multiple fields are separated by a comma), then the following format is used for an expression with n terms:

   Code Block
   { {<term 1>}, {<term _2>}, ... , {<term n>} }

   
   where each term has the following format:
   

   Code Block
   { "logical":<"always" | "never" | "and" | "or" | "xor" | "nand" | "nor">, "field":<field name (may be hierarchical, separated with ".")>, "comparison":"<" | "<=" | ">" | ">=" | "==" | "!="> "value":<scalar value> }

   For structured datapoints, perform the following steps:

   1. Set the Alarm Type Name and enable the Alarmed Yes option.
      
      
      
      
   2. Disable the Preset option. Changes to the settings appear on the Edit Datapoint Properties view.
      
      
      
      

   3. Set the Logical operator (i.e., always, never, and, or, xor, nand, nor).

      1. The always and never logical operators introduce clauses consisting of a series of terms similar to the following:
         

         Code Block
         { {<clause1>}, {<clause_2>}, ... , {<clause n>} }

         where each clause has the following format for an expression with n terms:

         Code Block
         { {<term 1>}, {<term _2>}, ... , {<term n>} }

         
         

      2. The always logical operator specifies that an alarm must always be generated if the clause is true and is the equivalent of or for all terms until the next always or never logical operator. It is the appropriate logical operator if only one term is specified and for the first term if more than one term is specified. The logical comparison is ignored for the first term, or if only one term is specified.

      3. The never logical operator specifies that an alarm should not be generated if the clause is true, which is the equivalent of and not for all terms until the next always or never logical operator.

      4. The xor logical operator specifies that (A xor B) is true when A and B are different. For example: if you have (value > 0) xor (state == 1), then this is true when [(value > 0) and (state != 1)] or when [(value <=0) and (state == 1)].

      5. The nand logical operator specifies that (A nand B) is not (A and B).

      6. The nor logical operator specifies that (A nor B) is not (A or B).
         
         

   4. Set the Field name (i.e., name, which may be hierarchical, separated with ".").
   5. Set the Comparison (i.e., < , <= , > , >= , == ).
   6. Set the Value (i.e., a scalar value).
   7. Use the Add button () to add settings as needed.
      
       
      

      
      

      Code Block
      title Example 1: shows an alarm for a SNVT_switch with an ON state and greater than 80% value
      [ {"logical":"always", "field": "state", "comparison":"==", "value":"ON"}, {"logical":"and", "field": "value", "comparison":">", "value":80} ]

      
      

      Code Block
      title Example 2: shows a combination of logical operators
      [ {"logical":"always", "field": "sensorEnable1", "comparison":"==", "value":"ON"}, {"logical":"and", "field": "temperature1", "comparison":">", "value":80}, {"logical":"always", "field": "sensorEnable2", "comparison":"==", "value":"ON"}, {"logical":"and", "field": "temperature2", "comparison":">", "value":90}, {"logical":"never", "field": "bypassSwitch1", "comparison":"==", "value":"ON"}, {"logical":"or", "field": "bypassSwitch2", "comparison":"==", "value":"ON"} ]

      
      

      Code Block
      title Results
      ((sensorEnable1 == "ON") and (temperature1 > 80)) or ((sensorEnable2 == "ON") and (temperature2 > 90)) and not ((bypassSwitch1 == "ON") or (bypassSwitch2 == "ON"))

      
      
      

5. Click Update to save the settings and return to the Datapoint Properties widget.

...

1. Go to the Edit Datapoint Properties → Preset Definitions tab.
   
   
   
   
2. Click the Create button ().
   
   
   
   
3. Enter the preset name and value. (Presets are based on the local values.)
   
   
4. Click Save.
   
   The preset definition appears on the Edit Datapoint Properties view.
   
   
   
   
5. Click Update to save the settings and return to the Datapoint Properties widget.
   
   
6. Refresh your browser window (Ctrl-F5 in many browsers) to display the updated preset definition.

...