BACnet communication protocol

Supported device types and versions
Communication line configuration
Communication station configuration
I/O tag configuration
Scheduler in Siemens Desigo devices
Scheduler in Delta Controls devices
Information about events
Information about alarms
Comment on the address cache
Comment on Delta Controls devices
Comment on E-DDC3.1 devices
Comment on Siemens Desigo devices
Comment on Klimasoft MBG-MSTP devices
Comment on iLON 10 Ethernet adapter
Comment on Easylon USB Interface+
Comment on BACnet MS/TP implementation
Comment on BBMD (BACnet Broadcast Management Devices) support
Tell commands
Literature
Changes and modifications
Document revisions

Kotva
typy_verzie typy_verzie

Supported device types and versions

...

The BACnet communication protocol (Building Automation and Control Networks) implements ANSI/ASHRAE 135-2001 standard.
This implementation was tested on with the following devices:

• Siemens
  • Desigo PXM20 (Control unit, LON interface, BACnet over LON)
  • Desigo PXC22 (Control station, LON interface, BACnet over LON)
  • Desigo PXC22-E.D (Control station, Ethernet interface, BACnet/IP)
  • Desigo PXG80-N (BACnet router, Ethernet interface, LON interface, BACnet/IP, BACnet over LON)
• Delta Controls
  • DSC-1212E (System controller, Ethernet interface, BACnet/IP)
  • DAC-633 (Application controller, MS/TP interface connected to DSC-1212E, which works as BACnet router)
  • DAC-633 (Application controller, MS/TP interface connected to the Moxa 5250 serial/ethernet converter and communicated directly as a BACnet MS/TP device in UDP mode)
  • DAC-1146 - (Application controller, MS/TP interface connected to DSC-1212E which works as BACnet router)
• Sauter
  • EYK220F001 (Automation station, Ethernet interface, BACnet/IP)
  • EYR203F001 (Universal controller connected to EYK220F001)
  • EYR207F001 (Universal controller connected to EYK220F001)
• York
  • BACnet MS/TP MicroGateway (Communication card for York coolers, RS485 interface, BACnet MS/TP)
• SE-Elektronic GmbH:
  • E-DDC3.1 (DDC automation station, Ethernet interface, BACnet/IP)
• Klimasoft
  • BACnet/Mbus converter MBG-MSTP: Converter from BACnet to Mbus protocol (RS485 interface, BACnet MS/TP)

...

• Communication in Ethernet (BACnet/IP) and LONTalk networks.
• Limited support of MS/TP network (master-slave token-passing on RS-485): without automatic searching of for Master stations.
• Support of BACnet router (the connection between BACnet/IP and LONTalk networks).
• Reading and writing of simple values (binary, integer, real, strings, date, time, etc..) and any ASN sequences.
• Support of the polling method of data reading (messages ReadProperty-Request and ReadPropertyMultiple-Request messages).
• Support of change method of data reading (an optional registration by SubscribeCOV-Request or SubscribeCOVProperty-Request and next following processing of ConfirmedCOVNotification-Request and UnconfirmedCOVNotification-Request).
• Writing the values by WriteProperty-Request.
• Dynamic change of I/O tag address by TELL command SETPTADDR (to read the values of Schedule objects).
• Work with objects of Schedule type (schedules).

BACnet protocol consider considers all the participants of the communication as the network devices. Each network device contains at least one (mostly just one) object Device (its Object Identifier must be unique in within the whole network). This object contains other object objects of defined types (Analog Input, Analog Output, Analog Value, Binary Input, Binary Output, Binary Value, Calendar, Command, Event, Group, File, etc.). The object detection - see a description of Request type Who-Is and Who-Has Request types.
Each object has the properties, which can be required and mandatory or optional. Moreover, each producer of BACnet devices can implement other properties when necessary.
The messages in the BACnet protocol relates are related to the manipulation with of objects and their properties. They are defined by with the help of ASN.1 (Abstract Syntax Notation version 1) and encoded by a simple version of BER (Basic Encoding Rules - encoding of ASN.1 messages).
The messages contain, besides fixed defined items, also the items of 'Abstract Syntax & Notation' type. It means that any sequence (or "tree"), the meaning of which meaning is defined by an implementatorimplementer, can be on the given in its place in the message. When using BER, it enables parsing of the message with the unknown items. BER defines two basic item types (tags): application and context.
The application tags are predefined:

• Null - empty value
• Boolean - yes/no
• Unsigned - positive integer
• Signed - integer
• Real - 4-byte real number
• Double- 8-byte real number
• Octet String - a sequence of character
• Character String - charset + text string
• Bit String - a sequence of bits
• Enumerated Value - enumerated value
• Date - date
• Time - time

• Kotva
  objectidentifier objectidentifier

  Object Identifier - identifier of the object (32-bit number, it consists of 10-bit number - Object Type and 22-bit number - Instance)

The context tags depend on the context (on the position in the message). Without knowing the context (a description of the message that is being parsed), you can it is possible to find out that on the particular position is the context tag No. 5 of with the length of 4 bytes is on the particular position, but you need an additional information whether the value is Unsigned, Signed, Real, Bitstring or other onea different type of value.
Besides the simple application and context tags, the properties may be also complex:

...

Example - a dump from trace file of a KOM process with the debug enabled:

  === ASN Body beg ===
  objectIdentifier (tag 0) OBJID 0 analog-input,10
  listOfResults (tag 1) SEQUENCE {
    propertyIdentifier (tag 2) ENUM 85 present-value
    propertyValue (tag 4) SEQUENCE {
     ENUM 1
    }
  }
  === ASN Body end ===
 

ExplanationInterpretation:
It is the Sequence of two tags: objectIdentifier is contextual a context tag with the number 0, of Object Identifier type. Its value is Object type=0 (analog input), Instance=10.
The tag listOfResults contains the contextual tag 1 which is is a context tag with number 1 and it is a Sequence of two tags. First The first one is propertyIdentifier. It is the contextual a context tag No. 2,  Enum type, value = 85 that correspond corresponds to "present-value". A second tag is contextual a context one, No.4. It the is a sequence that contains one Enumerated Value tag with the value=1 (application tag).
To parse this message, the D2000 KOM process must know ASN.1 definition of a message. Without it, the process can find out that the message contains the contextual context tag 2 (value=1 byte) but cannot know that it is Enumerated Value. It is not able to interpret this byte (it could be Enumerated Value, Unsigned or Signed number) and do does not know that the name of this contextual context tag is propertyIdentifier and the value 85 correspond corresponds to "present-value".

The properties of objects are mapped on to I/O tags in the D2000 configuration. Due to the existence of contextual context tags, you may specify an Application tag in the I/O tag. It determines the interpretation of the contextual context tag. The parameter Complex address defines "a path" in the parse "tree" to get the values from the sequence that is defined by implementatorthe implementer.

Kotva
komunikacna_linka komunikacna_linka

Communication line configuration

...

• Communication line category: TCP/IP-UDP, LonWorks, Serial, SerialOverUDP Device Redundant.
• TCP/IP-UDP parameters:
  • Host: IP address or of the network interface that is used for communication by the D2000 KOM process process. A symbolic name that can be translated to an IP address can be entered too.
    Note: a symbolic name ALL or * can be entered - in which case all available interfaces are used.
  • Port: UDP port number that is used for communication by the D2000 KOM process  process (according to standard 0xBAC0, i.e. 47808).

Note: The parameters of the backup server (Host and Port) are not used in this protocol.

Line protocol parameters

Line protocol parameters specific for BACnet MS/TP

Kotva
komunikacna_stanica komunikacna_stanica

Communication station configuration

...

The communication station corresponds to a device on the BACnet network with which the KOM process communicates.

• Station type: BACnet/IP station must be configured on TCP/IP-UDP line. LonWorks station must be configured on the LonWorks line line. MS/TP station must be configured on SerialOverUDP Device Redundant or Serial line.

• Kotva
  adresa adresa

  Address:
• BACnet/IP station: IP address of station (in the form A.B.C.D, e.g. 172.16.0.99)
• LonWorks station: address of LON subnet and LON node (in the form subnet.node, a subnet is an 8-bit number and a node is a 7-bit number)
• MS/TP station: number of the node on the line (0-254, address 255 is a broadcast)
• Port: (only for BACnet/IP): UDP port number on station (according to standard 0xBAC0, i.e. 47808)
• Domain: (only for LonWorks): 0 or 1, it relates with is related to the line configuration. On LonWorks line you can configure the LonWorks line, a membership to one or two domains can be configured. On the BACnet station, if you choose some domain, it the selection of domain means that the device belongs to this domain (it influences 'domain' bit in LON address).
• Source network: source network number (i.e. a network with KOM process). This parameter may not be set for the LonWorks line line. For TCP/IP-UDP line line, it is a 16-bit number (or it is not set, see Note 2).

• Kotva
  destionation_network destionation_network

  Destination networknetwoEditrk: a 16-bit number of a destination network (i.e. a network including the device which communicates with the KOM process).
  Set this for the LonWorks line  line if the KOM process communicates with the device that is placed after located behind a BACnet router. In that case, the Address of the station is the address of the BACnet router and the Destination address is the address of the destination device.
  For TCP/IP-UDP line line, use the Destination network is used in a similar way if there is a communication between different BACnet networks.
  
  Note 1: This configuration was tested as follows:
  • Line: TCP/IP-UDP
  • Station type: BACnet/IP
  • Address: 172.16.99.1 (address of a BACnet router PXG80-N)
  • Destination network: 1
  • Destination address: 1.1 (address of PXC22 on a LON network after behind a BACnet router)
  The KOM process communicated with the PXC22 device PXC22 which was connected to a LON network by BACnet router via PXG80-N BACnet router. The KOM process communicates communicated with a BACnet router over Ethernet, so the line is TCP/IP-UDP. The communication between the BACnet router and the PXC22 station PXC22 was done performed over a LON network.
  
  

  Kotva
  pozn2 pozn2

  Note 2: We tested the a similar configuration. We used Delta Controls DSM-RTR (connected over Ethernet network) and a Klimasoft MBG device (a gateway on to M-Bus) after it connected over connected to Delta Controls via an MS/TP interface. The communication started only if only the Destination network (value 50020) and Destination address (value 96) were configured and not the Source network was not specified. However, in other another configuration, the communication proceeded worked also with the parameter Source networkthe Source network parameter specified. We recommend you to try various settings of network parameters for the devices.

...

• Kotva
  destionation_address destionation_address

  Destination address: It is the address of the destination device if KOM communicates with it over the BACnet router. When setting this parameter, you can (but you may do not have to, see note about E-DDC3.1) set also the parameter Destination network. Parameter The Destination address should parameter should be in the form the subnet.node format (if the destination device is in on a LON network) or in the form A.B.C.D format (if the destination device is in on a BACnet/IP network).
  
  Note 1: On a BACnet/IP station you can configure the Destination address in the form subnet.node node format (e.g. 1.31). This configuration corresponds to the BACnet router, which communicates with the KOM process over BACnet/IP and is connected to the destination device over via a LONTalk network.
  
  Note 2: On BACnet/IP station you can configure the Destination address as a number from the interval 1-255. This configuration corresponds to the BACnet router, which communicates with the KOM process over BACnet/IP and is connected to the destination device by MS/TP bus (DAC-633).
  
  Note 3: On BACnet/IP station you can configure the Destination address as a bigger number (e.g. 2001), which works for E-DDC3.1.

• Kotva
  resubscribe resubscribe

  Resubscribe interval: Time in seconds. After it elapses, a station again gets a request to send changes of I/O tags. This parameter relates to the I/O tags with the Request type that is equal to SubscribeCOV or SubscribeCOVProperty.
• Max APDU: Maximum size of the message (APDU = Application Protocol Data Unit) that is sent by the KOM process. A The default value is:
  • 1467 octets for TCP/IP-UDP line line
  • 487 octets for SerialOverUDP Device Redundant or Serial lines (BACnet MS/TP)
  • 55 octets for LonWorks line (the
    
    The limitation depends on the size of packets which that may be transmitted over Ethernet and LonWorks. For LonWorks, the maximum value is 206. The value 55 is due to the limitation of the iLON 10 Ethernet adapter).
  
  The changing of the default value is important for testing and adjusting to complying with the stations which are able to process only smaller messages. For exampleCurrently, the reducing reduction of Max APDU influences only the size and amount of messages ReadPropertyMultiple-Request messages. These messages are intended for a periodic reading of the I/O tag value (see I/O tag configuration).
  
  Note: The setting of Max APDU does not affect the size of max-APDU-length-accepted in APDU BACnet-Confirmed-Request-PDU, with the help by means of which the KOM process informs a partner what how big message messages it is capable to process. This parameter is configured by the station protocol parameter Segment-Response.
  
  
• Priority: A priority of a message in the BACnet protocol. There are 4 priorities: Normal (default), Urgent, CriticalEquipment, and LifeSafety.
• Rpt_timer & reply: (only for LonWorks) The parameters Repeat timer (default value = 1) and Retry (default value =1 ) of LonTalk protocol.
• Tx_timer: (only for LonWorks) Parameter Tx_timer in LonTalk protocol. Default value = 3.
• Timeout and retry: A timeout in milliseconds to confirm the message. Default The default value according to the BACnet protocol is 3000 ms. After the timeout elapses, the message is sent retry-times. If any confirmation is not received, an error count will increase on for the station.
  
  Note: When testing the Siemens PXC64-U device (the communication over LonTalk), we had to set Retry=8, Timeout=300 (more retries with shorter timeout). Due to that, we had to increase the values COM_ERR=10, HARD_ERR=20 so that the station did not switch to an error state at when retrying to send the message.
• COM_ERR: The value of the error counter on for the station when the station switches to COM_ERR status. The situation when the station does not reply on call for reading or writing of value could be consider as to a read/write request is considered as an error. A negative confirmation of a command (refusal of recordingwriting) is not the an error. Default The default value = is 5. See the parameters Timeout and retry.
• HARD_ERR: The value of the error counter on for the station when the station switches to HARD_ERR status. Default The default value = is 10. See the parameters Timeout and retry.
• Register-Foreign-Device, R-F-D Time to live: In this example the station is placed on LONTalk network after BACnet router which communicates with , let's have a station located on a LONTalk network behind a BACnet router that communicates with the KOM process over Ethernet (e.g. Desigo PXG80-N). The BACnet router sends the broadcasts from LONTalk to Ethernet as UDP broadcasts. If distributing the distribution of UDP broadcasts is disabled or the KOM process is placed in other a different segment of the network than the BACnet router (so it does not receive any UDP broadcasts), you should mark off check the option Register-Foreign-Device on the station. This will cause, cause the KOM process will to send the message Register-Foreign-Device message to a BVLC router (BACnet Virtual Link Control) after the start. The message calls for the requests registration to the FDT table (Foreign Device Table) in the router. The router sends the broadcasts in the form of UDP unicast (whose distribution is not limited to one segment) to the devices that are registered in the FDT table. The TTL (time to live) - time in seconds (1-65535) is the parameter of message the Register-Foreign-Device message . It defines the expiration of registration that stops the sending of UDP unicasts. That is why the KOM process must ask BACNet the BACnet router to re-register it before TTL expires. If there are more stations after behind a BACnet router, just mark off check Register-Foreign-Device on one of them.
  
  Note 1: If the router does not support BBMD functionality (BACnet/IP Broadcast Management Device), it replies to the message Register-Foreign-Device message with the an error code and it does not send LonTalk broadcasts to the KOM process in the form of UDP unicasts. In that case, you must use other solution solutions (the communication over iLon Ethernet Adapter, the placing of the KOM process on the same segment in the network on which is the BACnet router is, etc.).
  Note 2: Router Desigo PXG80-N supports this functionality (tested). The control station Desigo PXC22-E.D does not support it probably (not tested yet).
  Note 3: In the case of Desigo devices, if the D2000 KOM process is on a different network segment than the Desigo device, this parameter must be checked at the station. Otherwie Otherwise, Who-Is and Who-Has queries requests won't work (and thus addressing by object's name), as responses to these queries requests are sent as UDP broadcasts which will not go through a router.
  
  
• Master: (only for MS/TP): The station is of Master type. The KOM process transmits a token to the Master station which has the next larger address than is the address of the KOM process (the parameter of line MS/TP address line parameter). If the addresses of all Master station stations are lower than addresses the address of the KOM process, the token is given to the Master station with the lowest address. If any no Master station has not been configured, the KOM process supposes to be the only master and does not give any pass the token. You should get the information about the type of station from a producer or device documentation.
  
  Note: The current version implementation of the BACnet protocol does not contain the automatic search of for the Master station. You can find more information in the section Comment on BACnet MS/TP implementation.

Example of station configuration on TCP/IP-UDP line line:

• Station type: BACnet/IP
• Adresa: 10.0.0.1
• Port: 47808
• Source network: 1

Example of station configuration on LonWorks line:

• Station type: LonWorks
• Address: 1.15
• Domain: 0

...

Station protocol parameters

Kotva
merany_bod merany_bod

I/O tag configuration

...

• Kotva
  requesttype requesttype

  Request type: Reading and writing of the object properties may be done in several ways:

  • Kotva
    readproperty readproperty

    ReadProperty - a periodical reading of object property as request-response. A polling period of polling is set configured on the tab Time parameters tab of station. The message The ReadProperty-Request represents the message is used for the request and the message the ReadProperty-Ack represents  message is the response from the device. The periodic reading loads burdens the network and is ineffective. That is why, if the device supports the sending of change data, we recommend you to use SubscribeCOV or SubscribeCOVProperty requests.
    The message The ReadProperty-Request message is sent if checkbox the Subscribe/read checkbox is ticked offchecked.
  • ReadPropertyMultiple - the functionality is similar to the previous parameter. Unlike ReadProperty, more object properties are sent in one request-/response, so the communication is much more effective. The message The ReadPropertyMultiple-Requestrepresents the message is used for the request and the message the ReadPropertyMultiple-Ack represents message is the response from the device.
    The message The ReadPropertyMultiple-Request message is sent if checkbox the Subscribe/read checkbox is ticked offchecked.
  • WriteProperty - the message the WriteProperty-Request writes message is used for writing the values. The parameter Application tag parameter must be specified as well. If Subscribe/read is marked offchecked, the recorded written value is reread verified by reading from the station using the message ReadProperty-Request message after writing.

  • Kotva
    subscribecov subscribecov

    SubscribeCOV - activation of reading of object value by when they change method. If the checkbox the Subscribe/read checkbox is ticked offchecked, after starting, the KOM process send sends the message SubscribeCOV-Request message which asks the device to send information about the change of object value. You can specify whether the device will send the confirmed notifications (message ConfirmedCOVNotification-Request message) or the unconfirmed ones (UnconfirmedCOVNotification-Request). The confirmed notification requires the an explicit confirmation from the KOM (the message BACnet-SimpleACK-PDU message), so it loads puts more load on the network. However, the probability that the notification will be lost is lower than if you would specify the unconfirmed notification in case of using unconfirmed notifications (if the device does not receive the a confirmation, it repeats the message).
    
    Note 1: Besides the dynamic registration by the message SubscribeCOV-Request message, some devices can support also a static one (it is saved in the configuration). So the registration is not required and the checkbox Subscribe/read may not be ticked offleft unchecked.
    Note 2: The registration can be sent in at regular intervals (e.g. because of the a potential failure of the device power supply). You can set this interval on the station - the parameter Resubscribe interval parameter.
    Note 3: SubscribeCOV-Request messages (and also SubscribeCOVProperty-Request messages, see the following point) are also sent after the connection with the station is re-established (after a failure or after switching from the StOFF state to the StOn).

  • Kotva
    subscribecovproperty subscribecovproperty

    SubscribeCOVProperty - the functionality is similar to SubscribeCOV. Moreover, you can specify the Property identifier (so you can monitor also the changes of other object properties as valuesthan the present value) and Increment - a size of increment which causes the change will to be sent (i.e. a dead zoneband).
    This message - The SubscribeCOVProperty-Request message is sent.
    
    Note: The device Siemens PXC64-U device did not support the parameter Increment parameter.

  • Kotva
    whois whois

    WhoIs - the identification message Who-Is-Request to detect the type of Device Object in a device. The message The I-Am-Request message is the response (it contains the fields iAmDeviceIdentifier, maxAPDULengthAccepted, segmentationSupported, and vendorID fields). If the I/O tag is TxtI, this information is extracted to the value of the I/O tag in a text form. After you identify the Device Object, you can configure the I/O tag for reading the property object-list of this Device Object. If the device implements this property, it returns the list of identifiers of all objects which it contains. Then you can detect query the properties of these objects (object-name, location, description, present-value ..)
    
    Note: For Siemens PXC64-U you must set the Array index and then read the property object-list. Array index=0 defines the number of array elements, Array index=1 up to N enables the access to the individual elements.

  • Kotva
    whohas whohas

    WhoHas - the identification message Who-Has-Request to detect the object name from the object identifier or vice versa. The response is the message the I-Have-Request message (it contains the fields : deviceIdentifier, objectIdentifier, and objectName). The message The Who-Has-Request message is sent only once when initialization of I/O tag (or after the TELL command SETPTADDR). It is intended for the transfer between names and identifiers of objects.
    The message Who-Has-Request will contain either name or identifier of the object depending on whether the Address type has been configured as Name or Object type+Instance in I/O tag.
    If Subscribe/read is ticked offchecked, you can use the information from 17280087the BACnet cache, which is much more faster than detection from the communication.

  • Kotva
    readwritescheduler readwritescheduler

    ReadWriteScheduler - the message the ReadProperty-RequestnaRequest message is used for the request, the message WriteProperty-Request message is used for write (it writes N pairs time-valuevalue pairs). Th The configuration is used for the reading and writing of objects of schedule type, see the article the Scheduler in Siemens Desigo devices paragraph.

  • Kotva
    geteventinformation geteventinformation

    GetEventInformation: a detection of objects that are in alarm or error state or they need to be acknowledged, see the section Information about events.

  • Kotva
    acknowledgealarm acknowledgealarm

    AcknowledgeAlarm: the acknowledgement acknowledgment of alarms that have been loaded read by the GetEventInformation request GetEventInformation. See the section Information about alarms. I/O tag must be the text output (TxtO).

• Kotva
  addresstype addresstype

  Address type: Each object in the BACnet protocol is addressed by an Object identifier. When designing the application in the Desigo system, the objects are represented by a name, but the object address is not accessible and can vary following the changes of application. As regards On the other hand, the Delta Controls devices , they contain the objects whose addresses are defined by the author of the application. For this reason, there are two ways how to define the address of I/O tag which corresponds to two Address type:
  • Name: enter the object name. A type of object and number of instance are found out instance number is queried dynamically from the communication. To avoid the overloading of communication lines when starting the KOM process, data are is stored in a 17280087 BACnet cache.
  • Object type + Instance: enter the type of object and an instance number of instance. This is recommended for BACnet objects with the constant addresses.
• Object type: type of objects, whose properties will be read/written. You can use the predefined types or write the number of a new type of object which has been defined by a producer. The type of object is a 10-bit number.
• Instance: a sequence an object identification number of object within the object type. Each object has a unique Object Identifier in the device, which is a pair [Object type, Instance].

• Kotva
  objectname objectname

  Object Name: name of the object, when Address type = Name, i.e. it means the I/O tag address [Object type, Instance], is detected dynamically from the communication. Object Name must be set without specified exactly, i.e. spaces in the beginning and at the end are not tolerated, and the uppercase upper and lower case letters must correspond to the object name that is stored in the BACnet device with which it communicates.
• Property type: type of property - set only only PropertyIdentifier is specified for Simple, and both PropertyIdentifier and Complex address must be specified for Complex. The complex type of property is necessary when for the parsing by implementer of extension of the of OEM-extended standard messages (items of 'Abstract Syntax & Notation' type). When sending the messages ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, and  SubscribeCOVProperty-RequestRequest messages, the Complex address is ignored.
• Property identifier: identifier of an object property. You can use the predefined properties or number configure a numeric identifier of new property which has was defined by the producerOEM manufacturer. The type of property identifier is Enumerated Value, the properties 0-511 are reserved for BACnet, the numbers from 512 to 4194303 can be used for by the device producersOEM manufacturer.
• Array index: some properties may be defined as value array. The arrays of values. In this case, a particular item of an array can be read or written.

• Kotva
  application_tag application_tag

  Application tag: it must be specified when writing the value (Request type=WriteProperty) and possibly for other types of requests , if the parsed response contains the context tags which application type is unknown because it is the extension of messages defined by implementerthe OEM manufacturer. The exception is an output tag of text tag type that is considered to be 'AnyTree', as regards if the unspecified application tag is unspecified, and is it can be used to write any user-specified ASN sequence.
  
  Note: If the the value is Invalid, it is not written as the defined Application tag, but as Application tag "Null".

• Kotva
  complex_address complex_address

  Complex address: address of a tag in a 'tree' in connection with the extension of messages that have been defined by implementerthe OEM manufacturer.
  Example of address: [1].[3].2.1
  Description:
  [1] - context tag No.1 (it is assumed that it is the sequence),
  [3] - it is the context tag No. 2 3 in this sequence (again, it must be the a sequence),
  2 - it is the second tag in order in this sequence (again, it must be the a sequence),
  1 - it is the first tag in order in this sequence.
  The address in 'tree' starts from the propertyValue level propertyValue (see the examples below). The easiest way to view the parsed message is to turn on debugging for a debug on the line and watch the debug info on the console or in the line log of linefile.
  
  Example 1: There is Let's have a device that contains the object of type 2 (Analog Value) with the instance number 1. It is assumed Let's assume that the device sends the object value as a triplet of numbers. The first number is the current value, the second one is a one-minute average and the third one is a ten-minute average. The log of the parsed message could be the following:

   === ASN Body beg ===
   objectIdentifier (tag 0) OBJID 2 analog-value,1
   listOfResults (tag 1) SEQUENCE {
    propertyIdentifier (tag 2) ENUM 85 present-value
    propertyValue (tag 4) SEQUENCE {
     REAL 1.40000E+00
     REAL 1.10000E+00
     REAL 1.30000E+00
    }
   }
   === ASN Body end ===
  

  If you wants want all three values, you must configure three I/O tags (Object type=analog_value, Instance=1, Property-identifier=present-value, Property-type=complex), which differ in the complex address (for the first I/O tag = specify 1, for the second one = specify 2, and for the third one = one specify 3). Tick off the checkbox Subscribe/read only in one configuration  in a configuration of one of these I/O tags only, because the response to one request is the message with three values. When sending the messages ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, SubscribeCOVProperty-Request, and WriteProperty-Request messages, the complex address is not used.
  
  Note: If you configure the I/O tag with Property-type=simple, its value would be set on to the first found value after parsing of the message (see in the previous example , it is 1.40000E+00).
  
  Example 2: Siemens Desigo PXC64-U contains I/O tag (Object type=schedule, Instance=6, Subscribe-read is ticked offchecked, Property-identifier=weekly-schedule, Property-type=complex, Array index=1, Complex address=1). A debugging has been started on the line. After the I/O tag is saved, the KOM process sends the request and writes the response:

   === ASN Body beg ===
   objectIdentifier (tag 0) OBJID 17 schedule,6
   propertyIdentifier (tag 1) ENUM 123 weekly-schedule
   propertyArrayIndex (tag 2) UNSIGNED 1
   propertyValue (tag 3) SEQUENCE {
    SEQUENCE {
     TIME 0:0:0.0
     UNSIGNED 2
     TIME 4:0:0.0
     UNSIGNED 3
     TIME 22:0:0.0
     UNSIGNED 1
    }
   }
   === ASN Body end ===
  

  In propertyValue, there is the sequence of 6 values (time and positive number alternately). If you want to access to the first time, you have to set Complex address=1.1, if to the first positive number, set Complex address=1.2. I.e. the first element - sequence - the second element in the order within it (UNSIGNED 2). If you need to access to more times and/or values at the same time, you must configure several I/O tags and tick off check the checkbox Subscribe/read only checkbox in one of them only.
  
  Note 1: The value of If the I/O tag remains Unknown, after creating and saving it with the was created with a complex address 1, its value would remain Unknown, because this address matches with 1. the 1st element in propertyValue, which is the a sequence but , not a simple typtype.
  
  

  Kotva
  pozn2 pozn2

  Note 2: The I/O tag of Text type are is able to cover contain not only simple value but also any ASN sequence. The values are written according to rules for record the writing of ASN sequence. If you set Complex address=1 and change the I/O tag to text input or text output in the previous example, its value will be a string " T0:0:0.0; u2; T4:0:0.0; u3; T22:0:0.0; u1; ". If Property-type=complex, but Complex address is not defined, a result is the value will be "0{ T0:0:0.0; u2; T4:0:0.0; u3; T22:0:0.0; u1; }".
• Increment: increment of value change in the object property which causes the reporting of a change (see SubscribeCOVProperty).
• Confirmed: if the checkbox is ticked, it  the checkbox specifies whether the device will should send the confirmed notifications (ConfirmedCOVNotification-Request) or unconfirmed one (UnconfirmedCOVNotification-Request) for the configured Request types SubscribeCOV and SubscribeCOVProperty.

• Kotva
  subscriberead subscriberead

  Subscribe/read: if the checkbox is ticked, the proper respective messages for reading/registration of value changes are sent for the configured Request types:
  ReadProperty: the message ReadProperty-Request message
  ReadPropertyMultiple: the message ReadPropertyMultiple-RequestRequest message
  SubscribeCOV: the message SubscribeCOV-RequestRequest message 
  SubscribeCOVProperty: the message SubscribeCOVProperty-Request message 
  ReadWriteScheduler: the message ReadProperty-RequestRequest message

• Period from: if the a nonzero value is set and the checkbox Subscribe/read checkbox is ticked, the messages Subscribe/read messages will not be sent in the interval Polling period, which has been configured on the station, but in the period defined period by this parameter (in seconds). In this way, you can configure various Polling polling periods for different objects on one station. Moreover, you can detect with the help of whether the station communicates, using one I/O tag with Request type ReadProperty and a small Period whether the station communicatesvalue of the Period parameter.
• Local time: if the checkbox is ticked, the recorded respectively read received/sent times and dates are considered to be in a local time. If not, otherwise they are in monotonous considered to be monotonic UTC time.
• Flags-to-flags: if the checkbox is ticked, it causes that besides of I/O tag value, its the user flags FA, FB, FC, FD are set to be set beside the I/O tag value, for the Request types SubscribeCOV and SubscribeCOVProperty Request types. The value of status-flags attribute (of BACnetStatusFlags type) is mapped to these flags, if they are it is sent. BACnetStatusFlags is a quaternion of bits (in-alarm, fault, overridden, out-of-service) that support provides extra information about the object value.
• Write priority: for the record writing of 'commandable' properties, you can specify the priority 1-16. 1 = top priority, 16 = the lowest priority, 0 = none priority.

...

Browsing of address space

When clicking on the "Browse" button in the Address tab of the I/O tag, Bacnet the BACnet Item Browser dialog box opens. In this dialog box, the user may browse the address space of a device and insert its items to the address dialog of the I/O tag.

The items can be filtered through the based on four basic criteria:

• Instance number
• Type
• Object name
• Object description

Note: In the case of Type, Object name, and Object description it is not necessary to enter the full text in the filter field. Notation The notation "*FILTERED EXPRESSION*" is supported. The symbol * represents any text before and after the expression.

Note: Using Ctrl+C it is possible to copy the content of Bacnet the BACnet Item Browser into the Windows clipboard. All rows will be copied unless a specific row is selected.

Note: In versions from 20th December 2018 and newer, the recycling of browser dialogue has dialog has been implemented. If the dialog is closed by the Cancel button or after selecting an object, it is actually only hidden and it is available for browsing by another I/O tag within the same station so that the tree structure of , containing the browsed objects, is preserved. Clicking on the close icon at the top right corner will cause the dialog to be really closed.

Kotva
anytree anytree

Record Writing of any ASN sequence
Any ASN sequence can be written with via the help of I/O tag - of text output type (TxtO) without setting of application tagwhich has the Application tag property undefined. The rules are the following:

• the element consists of the optional number of context tag, the letter defining the application tag, and the value
• the application tags are written as follows (usage with and without context tag):
  • Null: [tag] n, example: " n", " 3n",
  • Boolean: [tag] b [0|1|n|y|N|Y], example: "b0", " 3b1"
  • Unsigned: [tag] u value, example: "u 123", " 10 u123"
  • Signed: [tag] s value, example: "s-123", " 10s 5"
  • Real: [tag] r value, example: "r 1.23", " 10r-3.14"
  • Double: [tag] d value, example: "d 1.23", " 10 d -3.14"
  • Octet string: [tag] O string, every byte of string is written as hex number (byte 1 is 01, byte 26 is 1A), example: "O 1A33f0", " 10 Obb004E"
  • Character string [tag] C 'string', example: "C 'hello world' ", " 10C 'apostrophe '' in the string' "
    The string must enclosed in the apostrophes. If the apostrophe occurs inside the string, it must be double (see the second example). Empty string can be set as follows: " C; "
  • Bit string: [tag] B bits, example: "B 100101", " 23B00101"
  • Enumerated value: [tag] E value, example: "E 123", " 10 E123"
  • Date: [tag] D day.month.year[.day_of_week], example: "D 1.10.2005", " D3.4.2004.5" (Monday=1 .. Sunday=7)
  • Time: [tag] T hour:minute:sec[.ms], example: "T 5:12:33.133", " T10:00:00"
  • Object identifier: [tag] o type:instance or [tag] o objid, (type is a 10-bit number, instance is a 22-bit number, objid is a 32-bit number. The examples show a binary 2-component and a single record -component format of this application tag with type=3 (binary-input) and instance=2
    " o 3:2", " 3o3:2"," 3o 12582914"
• the sequence consists of the single individual elements separated by the blank spaces and/or semicolons, e.g. " 1b0 2u13 ; 3 B 1001;4E14"
• the sequence can contain the nested sequences
• the nested sequence begins with the an optional number of context tag number and an opening bracket character '{'. If any no context tag is not enteredspecified, 0 is used.
• at the end of a nested sequence there is a closing bracket character  '}'
• the an example of nested sequence: "1u2 2{ 1s-1; 2E0 }", two levels of nesting: " { 1{ u23 s34 } 2E56 3r7.89 }"

Note 1: If ASN sequence is a result of the reading of I/O tag from communication is an ASN sequence and the I/O tag is of Txt type, this ASN sequence is written into it (according to the above-mentioned rules) on conditions thatusing the following rules:

• a blank space is before each element is blank space and the element is followed by a semicolon (e.g. " 1E4; 2B111; 3u1;"),
• a blank space is not between the number of context tag and the letter specifying the application tag,
• a blank space is not blank space, between the letter specifying the application tag and the value is not the blank space,
• the a context tag is before every nested sequence (e.g. " 0{ 0o1:2; 1E4; }",
• format of the time is hh:mi:ss.mss, e.g. " T11:01:02.000; 1T12:00:00.000; ",
• format of the date is dd.mm.yyyy, e.g. " D25.01.2005; 3D01.01.2005;".

Note 2: The empty sequence may be recorded written by the a string " ", the string of length 0 (i.e. "") is ignored.

...

Note: If the Application tag is not set configured properly (for the binary value it is Enum), the Desigo station returns an error 'invalid-data-type' when trying attempting to record itwrite:

  error-class ENUM 2 property
  error-code ENUM 9 invalid-data-type	

The Siemens Desigo PXC64-U device requires to set the following parameters for settings of the Application tag:

• binary-value, binary-output: Enum
• multi-state-value, multi-state-output: Unsigned
• analog-value, analog-output: Real

Comment on input-output I/O tag: you can configure the I/O tag which is both input and output:
I/O tag of Ao type - Analog output:

• Request type: ReadProperty
• Object type: analog-value(2)
• Instance: 45
• Subscribe/read: Y
• Property type: Simple
• Property identifier: present-value(85)
• Application tag: Real (this is necessary for the record of valuewriting)

When writing the value, the message WriteProperty-Request message is used. As Subscribe/read is tickedchecked, the written value is rereadread after it's written. If the I/O tag would be configured with Request type WriteProperty, its behavior would differ only in by an absence of periodic value reading (when starting KOM process and during its running, the period is set configured on the station, tab in the Time parameters tab).

Comment on Siemens Desigo devices: I/O tags has a text name in the Desigo control system. The instance of the I/O tag may be detected found out from the file DOTS00.DAT file in the application  application configuration - it is placed located 24 bytes before the beginning of the name.

Kotva
schedulersiemens schedulersiemens

Scheduler in Siemens Desigo devices

...

D2000 supports the reading and writing of schedulers. A scheduler contains BACnet attributes weekly-schedule(123) and exception-schedule(38).
Weekly-schedule is the field an array of 7 items (one item for each day in of the week). Each item represents a sequence of time-value pairs that defines define the value changes of the scheduler in a given time. When reading and writing, you can configure also an Array index which enables to access to the items in an array and access individual items of a weekly-schedule(123) array. The array index is 1-7 for single individual days (1=Monday), the index 0 contains a size of the array (value 7 for the attribute the weekly-schedule(123) )attribute, value 0 up to N for the exception-schedule(38) attribute).
Exception-schedule is intended for the holidays that require a different regime mode as is configured for common days. Exception-schedule is the sequence of 0 up to N items. One An item always contains a date (or range of dates), several time-value pairs (as regards in a weekly-schedule), and a priority (1= top, 16= the lowest). The priority defines which of the items will be used if they overlap.

Reading of scheduler (the

...

weekly-schedule attribute)

• Value
after
• -by-value: a dynamic change of complex address (1.1, 1.2, 1.3, etc.) in a script enables us to read all values and times similarly as for other properties.
• All times and values for one day at the same time:
  • Value type: a text input (reading of scheduler) or text output (read/write)
  • Request type: ReadProperty (reading of scheduler), ReadWriteScheduler (read/write)
  • Subscribe/read: Y
  • Object type: schedule(17)
  • Instance: an instance number
of instance
• • (e.g. 6)
which
• • that is found
from
• • in a Desigo configuration or with the help of the WhoIs request.
  • Property type: Complex
  • Property identifier: weekly-schedule(123)
  • Array index: 1 up to 7, it depends on the
loaded
• • day being read
  • Application tag: if it is not defined, Unsigned
is
• • will be used (it is
necessary
• • used only
when
• • for writing
of value
• • )
  • Complex address: 1 (address of a sequence)

The times and values separated by a semicolon are

...

read into the text value (

...

see Note 2).
When

...

writing the value

...

to a scheduler you should realize that the value can be sent with various application tags (Unsigned, Signed)

...

, however, the device

...

expects a particular tag (the easiest way to find it, is

...

by reading the value while line logging is active). The application tag of value is defined by the

...

Application tag item in the configuration. The valid value of the Application tag can be Boolean, Unsigned, Signed, Real, and Double. If any other type is set, the Unsigned value is automatically sent. A value type can be changed dynamically - if the first character of a text value is B, U, S, R or D, it stands for (B)oolean, (U)nsigned, (S)igned, (R)eal or (D)ouble.

...

Writing to the scheduler (the

...

weekly-schedule attribute)

• You must configure Request type=ReadWriteScheduler and assign the a sequence of time-value pairs separated by semicolon into I/O tag of text output (type, e.g. "0:0:0; 1; 2:30:40.5; 2; 5:00:00;1".
• The text string with the length=0 is ignored so that the "empty sequence" will not be recorded written to the scheduler after saving the D2000 configuration or starting when the KOM process is started. For this reason, if the time plan of the scheduler must be deleted for the a particular day, the string of nonzero length (it contains neither time nor value: " ") must be assign written to the I/O tag.

Kotva
note_schedulersiemens note_schedulersiemens

Note: Another possibility to write weekly-schedule, besides the special ReadWriteScheduler request ReadWriteScheduler, to write weekly-schedule is recording writing of an ASN sequence, e.g. the sequence "{ T0:0:0 u1; T2:30:40.5 u2; T5:0:0 u1 }" corresponds to the value "0:0:0; 1; 2:30:40.5; 2; 5:00:00;1". The I/O tag configuration differs only in Request type=ReadProperty. You can also write the time frame schedule for the whole week, if Array index is not set and the value contains 7 sequences for the individual days, e.g. "{ T0:10:0 u3 T1:3:0 u1; } {T2:0:0.0 u2 T5:30:10.0; u3; } { T6:0:0.0 u2 T7:0:0.0 u3} { T20:0:0.33; u1} { T21:0:0.0; u1} { T22:0:0.0; u2} 0 { T0:0:0.0; u3; T1:2:0.0; u1; T2:0:0.0; u2; T5:30:10.0; u3}".

...

Writing to the scheduler (the

...

exception-schedule attribute)

The recording of writing to the exception-schedule is supported over via the recording writing of an ASN sequence.
Example: I/O tag configuration:

I/O tag type: text output (TxtO)

Request type: WriteProperty

Subscribe/read: Y

Object type: schedule(17)

Instance: 6

Property type: exception-schedule

Application tag: not defined (write the whole ASN sequence)

With Using the help of this string "0{ 0D2.10.2005 } 2{ T1:0:0; u1; T12:0:0; u3 } 3u10" you can write the time frame schedule for the day October 2, 2005. The scheduler has the value 1 from since 1:0:0, the value 3 from since 12:00:00. The priority of the exception-schedule is 10. When rereading of reading a value after writing (Subscribe/Read was configured) with the activated debug on the line, you can see the following log:

...

To set the exception-schedule for the range of dates, write the value "0{ 1{ D5.10.2005; D8.10.2005}} 2{ T1:0:0; u1; T7:0:0; u3; } 3u15". This value for the range of dates 5.10.2005-8.10.2005 sets the scheduler from 1:00:00 to the value 1 and from 7:00:00 to the value 3. The priority of the exception-schedule is 15. When rereading of value  When reading a value after writing (Subscribe/Read was configured) with the activated debug on the line, you can see the following log:

...

Several items of above mentioned types can be written to the  the exception-schedule by the using a string which contains jointed joined sequences, e.g. "0{ 0D2.10.2005 } 2{ T1:0:0; u1; T12:0:0; u3 } 3u10 0{ 0D3.10.2005 } 2{ T0:0:0; u2; T5:0:0; u3; T14:0:0; u1 } 3u11 0{ 1{ D5.10.2005; D8.10.2005}} 2{ T1:0:0; u1; T7:0:0; u3; } 3u15 "

...

We also tested the reading and writing to the scheduler in the Delta Controls DAC-1146 device. Only the BACnet attribute weekly-schedule(123) was tested. The weekly-schedule is an array with 7 items (one item for each day in the week). Each item is the sequence of time-value pairs that define the value changes of the scheduler in given at a specific time. In contrast of to Siemens Desigo devices, the schedulers are implemented with Boolean values True/False that are externally presented as Enum values 0/1. This is the example of scheduler Delta Controls:
"{ T0:10:0 E0 T1:3:0 E1; } {T2:0:0.0 E1 T5:30:10.0; E0; } { T6:0:0.0 E0 T7:0:0.0 E1} { T20:0:0.33; E0} { T21:0:0.0; E1} { T22:0:0.0; E0} 0{ T0:0:0.0; E0; T1:2:0.0; E1; }"
The writing has done and then as well as subsequent reading of E2 value E2can be performed, however the interpretation by , we don't know the DAC-1146 is unclear's interpretation of E2 :-) .

Kotva
events events

Information about events

...

The request GetEventInformation-Request is intended to call for ask the list of objects that are in the state the Offnormal or Fault states or whose change to Offnormal, Fault, or Normal has not been acknowledged from the device.
Example of I/O tag configuration:

• I/O tag type: text input (TxtI)
• Request type: GetEventInformation
• Subscribe/read: Y
• Object type: undefined
• Instance: undefined
• Property type: complex
• Application tag: undefined

The message GetEventInformation-Ack is a A reply to GetEventInformation-Request is the GetEventInformation-Ack message, which contains the list of objects and the list of properties for each object:

• objectIdentifier: identifier of object
• event-state: object status (0=normal, 1=fault, 2=offnormal, 3=high-limit, 4=low-limit, 5=life-safety-alarm)
• acknowledgedTransitions: 3 bits that define whether the last transition to the offnormal, fault, or normal status was acknowledged
• eventTimeStamps: the time stamps timestamps of the last transition to the offnormal, fault, and normal status
• notifyType: defines whether it is a notification of alarm (0) or event (1)
• eventEnable: 3 bits that defines define whether the events report to to-offnormal, to-fault, to-normal
• eventPriorities: 3 unsigned values defining the event prioritypriorities

At the end of the list, there is the moreEvents attribute moreEvents that is non zero if the list of events is incomplete (e.g. the exceeding of the maximum length of maximum the message, etc.). For In this reasoncase, you must reconfigure the I/O tag and set Object type and Instance on to the last object in the list. It causes the generation of a new message GetEventInformation-Ack message.

Example of response GetEventInformation-Ack response:

 === ASN Body beg ===
 listOfEventSummaries (tag 0) SEQUENCE 0 {
  objectIdentifier (tag 0) OBJID 0 analog-input,1
  event-state (tag 1) ENUM 3 high-limit
  acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
  eventTimeStamps (tag 3) SEQUENCE 3 {
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:28:49.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:59.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 13:25:56.0
   }
  }
  notifyType (tag 4) ENUM 0 alarm
  eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
  eventPriorities (tag 6) SEQUENCE 6 {
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 7
  }
  objectIdentifier (tag 0) OBJID 214,1
  event-state (tag 1) ENUM 2 offnormal
  acknowledgedTransitions (tag 2) BITSTRING 0,1,0 to-offnormal(0),to-fault(1),to-normal(2)
  eventTimeStamps (tag 3) SEQUENCE 3 {
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 12:52:11.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 18.11.2005 Fri
    time TIME 11:16:23.0
   }
   dateTime (tag 2) SEQUENCE 2 {
    date DATE 9.11.2005 Wed
    time TIME 12:23:58.0
   }
  }
  notifyType (tag 4) ENUM 0 alarm
  eventEnable (tag 5) BITSTRING 0,0,0 to-offnormal(0),to-fault(1),to-normal(2)
  eventPriorities (tag 6) SEQUENCE 6 {
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 3
   eventPriority UNSIGNED 7
  }
 }
 moreEvents (tag 1) BOOLEAN FALSE
 === ASN Body end ===    

...

You can acknowledge the events and alarms, whose list has been loaded received by the request GetEventInformation request. According to the BACnet protocol, the format of this request is (the record in ASN.1 syntax):

  *********************** Confirmed Alarm and Event Services ******************
  AcknowledgeAlarm-Request ::= SEQUENCE {
    acknowledgingProcessIdentifier [0] Unsigned32,
    eventObjectIdentifier [1] BACnetObjectIdentifier,
    eventStateAcknowledged [2] BACnetEventState,
    timeStamp [3] BACnetTimeStamp,
    acknowledgmentSource [4] CharacterString,
    timeOfAcknowledgment [5] BACnetTimeStamp
  }

The For a more detailed description of the parameters is stated in a , see the literature.
The acknowledgement acknowledgment is executed by the writing of the above-mentioned sequence to the text of the output I/O tag according to the record rules of writing of any ASN sequence.

Example: The loading of following list of alarms and events with the help of GetEventInformationwas read using the GetEventInformation request:

   ===  ASN Body beg ===
   listOfEventSummaries (tag 0) SEQUENCE 0 {
    objectIdentifier (tag 0) OBJID 0 analog-input,1
    event-state (tag 1) ENUM 4 low-limit
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:4:37.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 0 analog-input,2
    event-state (tag 1) ENUM 3 high-limit
    acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:41:59.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
    objectIdentifier (tag 0) OBJID 214,1
    event-state (tag 1) ENUM 2 offnormal
    acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
    eventTimeStamps (tag 3) SEQUENCE 3 {
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 11:54:23.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:20.0
     }
     dateTime (tag 2) SEQUENCE 2 {
      date DATE 25.11.2005 Fri
      time TIME 10:12:21.0
     }
    }
    notifyType (tag 4) ENUM 0 alarm
    eventEnable (tag 5) BITSTRING 0,0,0 to-offnormal(0),to-fault(1),to-normal(2)
    eventPriorities (tag 6) SEQUENCE 6 {
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 3
     eventPriority UNSIGNED 7
    }
   }
   moreEvents (tag 1) BOOLEAN FALSE   === ASN Body end === 

The first object is the first in list
objectIdentifier (tag 0) OBJID 0 analog-input,1
which is in has the status low-limit status 
event-state (tag 1) ENUM 4 low-limit
and contains has unacknowledged transition to the offnormal status (i.e. according to D2000 terminology it is an active alarm low-limit alarm which requires the acknowledgement):
acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
This transition occurred in time
dateTime (tag 2) SEQUENCE 2 {
date DATE 25.11.2005 Friri
time TIME 11:54:23.0
}
The alarm is acknowledged with the record of by writing a text value
0u1; 1o0:1 ; 2E2; 3{ 2{ D25.11.2005 T11:54:23} } 4C'D2000' 5{ 2{ D25.11.2005 T11:55:23 }}
and the individual items are as follows (see the definition of AcknowledgeAlarm-Request above):

• 0u1u1 - tag 0, unsigned value 1 - acknowledgingProcessIdentifier = identifier of process which acknowledges the alarm (it could can be optionalarbitrary)
• 1o0:1:1 - tag 1, the identifier of object of type 0, instance 1 - eventObjectIdentifier = the identifier of object which contains the alarm
• 2E2 - tag 2, enum value 2 - eventStateAcknowledged = the acknowledged value (BACnet standard defines the following events that can be acknowledged):
  normal (0),
  fault (1),
  offnormal (2),
  high-limit (3),
  low-limit (4),
  life-safety-alarm (5)
  in this case we acknowledge the transition to the offnormal status in this case status 
• 3{ 2{ D25.11.2005 T11:54:23} } - timeStamp = the sequence with of date and time which must be acknowledged (it must match to the received event date and time which has been loaded)
• 4C'D2000' - acknowledgmentSource = a source of alarm acknowledgement (obviously it is any it seems it's an arbitrary string)
• 5{ 2{ D25.11.2005 T11:55:23 }} - timeOfAcknowledgment = date and time when the alarm was acknowledged

After acknowledging of alarm and loading a repeated reading of the list of alarms and events by the request GetEventInformation request , you will see the alarm has been acknowledged.
This record:, as 
acknowledgedTransitions (tag 2) BITSTRING 0,1,1 to-offnormal(0),to-fault(1),to-normal(2)
will change to:
acknowledgedTransitions (tag 2) BITSTRING 1,1,1 to-offnormal(0),to-fault(1),to-normal(2)

If the object had been in a normal state, it would not have been listed in the list of alarms at all. In this example it is in a low-limit state, i.e. it is an active acknowledged alarm.

To load read the list of alarms, their record to show them in a browser, and acknowledgment of to acknowledge the alarm, you must write the service ESL scripts which will parse the text value of the GetEventInformation request GetEventInformation and compound it and compose a text value for AcknowledgeAlarm.

...

Note: in the specific case, when acknowledging the alarm, the DESIGO PXC 100E.D device required the day of the week to be specified within the date (eg D8.6.2020.1 for Monday). A default value of 255 (unspecified) of a day of the week, which is sent when the day is not specified, did not suit the device when acknowledging the alarm.

Kotva
cache cache

Comment on address caching

...

If the station has at least one I/O tag with Address Type = Name, the numerical address is detected If the station has at least one I/O tag with Address Type = Name, the numerical address is detected by Who-Has-Request from ObjectName when initializing these I/O tags. After getting the address, the data (the quadruplet ObjectName; Object Type; Instance; DeviceInstance) are is saved to the cache file and are is available for the next starting start of the KOM process.
For each station there exists There is one cache file for every station. It is placed located in an application directory, in a subdirectory Cache. Its name is Cache_station_name.txt, e.g. Cache_B.StationX1.txt.
When saving a BACnet station, the data are is reloaded from this file. If the file was not found, the Who-Has messages are generated to for all I/O tags that contain Address Type = Name in this station.
This behavior may be used after changing the configuration of the device which communicates with the KOM process (if the addresses of objects was were changed when changing the configuration). Just delete the cache file in this station and save it - the station - within several seconds, the cache file occurs will be created again and is it will be filled with the acquired data.

Note: the interaction of cache and I/O tags with Request type = WhoHas.

• If the parameter Subscribe/read is marked off checked in the configuration of the I/O tag, the cache is not searched and the Who-Has-Request Request message is sent to the communication. The obtained information is not written to the cache. It is important only can be used for the objects that generate are generated and vanish deleted dynamically, which would overflow otherwise congest the cache.
• If Subscribe/read is not marked offchecked in the configuration of the I/O tag, the cache is searched. If ObjectName or ObjectIdentifier was not found, the Who-Has-Request message is sent to the communication. If the respond response comes, the information is written into the cache.

...

The test configuration included a DSC-1212E device connected to the local Ethernet network Ethernet and a DAC-633 device connected to DSC-1212E over MS/TP interface (RS-485). D2000 KOM communicated directly with DSC-1212E, and with a DAC-633 over DSC-1212E (it which performed the function of a BACnet router).
We used the software ORCAview 3.30 Build 1481 software from which we detected obtained the following configuration information:

Kotva
dsc-1212e dsc-1212e

DSC-1212E

...

After logging on to the ORCAview and

...

finding a DSC-1212E device

...

, the object BACnet Settings 3200 (3200 is a software address of the particular device)

...

can be found in the right

...

pane of the Navigator window. Clicking on BACnet Settings 3200 opened

...

a dialog window

...

that contained several tabs. The first tab (Setup

...

) contained also the

...

UDP/IP port type. After

...

clicking it, its parameters are displayed

...

at the bottom of the window,

...

among others Network (during the testing, we saw a specific number 40032), IP Address, and UDP Port.
When communicating with DSC-1212E, in the D2000 configuration of the station

...

the Source network could be either set to the value of Network or

...

left empty. The

...

IP Address and UDP Port parameters must be used to

...

configure the

...

Address and Port parameters in the station configuration in D2000. A station type was BACnet/IP.

Note: On

...

the Advanced tab, in the BACnet Properties area, the parameter Local

...

Network Number was set

...

to 10032 (it was the same as the

...

Network port of

...

the Ethernet type on the Setup tab

...

). This port is used for

...

BACnet over Ethernet communication (without the use of IP protocol), which is not supported

...

by D2000 yet.

Kotva
dac-633 dac-633

DAC-633

...

After logging on to the ORCAview and

...

finding a DAC-633 device

...

, the object BACnet Settings 3202 (3202 is a software address of the particular device)

...

can be found in the right

...

pane of the Navigator window. Clicking on BACnet Settings 3202 opened

...

a dialog window

...

that contained several tabs. The tab (Setup

...

) contained also the

...

MS/TP port with the Status attribute

...

and its value Active,

...

and the attribute Status Reference

...

with a value BACnet Settings 3202 (NET1). After

...

clicking it, its parameters displayed

...

at the bottom of the window,

...

 among others Network and MAC Address.
When communicating with DAC-633

...

, the following station parameters had to be configured in D2000:

• Station type: BACnet/IP
• Address: the parameter IP Address in the configuration of DSC-1212E
• Port: the parameter UDP Port in in the configuration of DSC-1212E
• Source network: the parameter Network in the configuration of DSC-1212E
• Destination network: the parameter Network in  of the MS/TP port in the configuration of DAC-633
• Destination address: the parameter MAC Address in of the MS/TP port in the configuration of DAC-633

As D2000 communicates with DAC-633

...

via DSC-1212E, the parameters Address, Port, and Source network, which correspond to DSC-1212E, and Destination network and Destination address, which correspond to MS/TP network between DSC-1212E and DAC-633, must be set in the station configuration.

Both devices support the both polling and on-change method methods of reading of data (both ReadProperty and SubscribeCOV).
The parameters Object type and Instance parameters in the configuration of the I/O tag was were detected in ORCAview from the attributes Object and Description attributes (e.g. object 3200.AI12 is Analog Input, Instance 12; the object 3202.PG3 is Program, Instance 3). The parameter Address type parameter is Object type+Instance and Request type is SubscribeCOV, if it is not defined other parameter.
 unless declared otherwise:

Communicated I/O tagstag types:

• Analog-input
• Analog-output (Application tag: Real - possibility to writecan be written)
• Analog-value (Application tag: Real - possibility to writecan be written)
• Binary-input
• Binary-output (Application tag: Enum - possibility to writecan be written)
• Binary-value (Application tag: Enum - possibility to writecan be written)
• Calendar (Request type: ReadProperty, Property type: Complex, Property identifier: datelist(123), Application tag: Date, Complex address: 1,2,.. etc. - gradual sequential reading from of the array; possibility to write the whole calendar with using the help of ASN sequence but when the Complex address is not enteredspecified, e.g. "0D1.9.2006; 0D3.10.2006; 0D8.9.2006")
• Event-enrollment
• Schedule (Request type: ReadProperty or WriteProperty - possibility to writecan be written; Property identifier: weekly-schedule(123))
• Program (Request type: ReadProperty, Application tag: Boolean - possibility to write - stop and start  can be written - stops and starts the program)
• Multi-state-value (Application tag: Unsigned - possibility to writecan be written)
• Trend-log (the cyclic buffer of values that are saved with the configured intervalperiod)
  • Property identifier: 1074 - an array of trend time stamp timestamps in tens of milliseconds since a the time of data reset
  • Property identifier: 1076 - bit string array (attributes of values?)
  • Property identifier: 1077 - an array of trend values
  • Property identifier: 1105 - the time of resettingdata reset

Kotva
e-ddc3.1 e-ddc3.1

Comment on E-DDC3.1 devices

...

The communication was revived according to worked with the following configurationsettings:

• Line: TCP/IP-UDP
• Station type: BACnet/IP
• Address: 10.0.6.23 (IP address of E-DDC3.1)
• Port: 47808
• Source network: not definedspecified
• Destination network: not defined not specified
• Destination address: 2001 (this was acquired from manufacturer's BACnet OPC server - the parameter "Device ID" parameter)

We tested ReadProperty, SubscribeCOV, WriteProperty (in with the objects of Binary Output, Binary Value, Analog Value type).
The defined Communicated I/O tags tag types (the test configuration contained only these types):

• Analog-input
• Analog-value (Application tag: Real - possibility to writecan be written)
• Binary-input
• Binary-output (Application tag: Enum - possibility to writecan be written)
• Binary-value (Application tag: Enum - possibility to writecan be written)

The device with the original firmware (2.01.05) with the original firmware did not work with properly handle the Who-Is request. We had to upgrade this firmware to the version 2.01.16. Then everything, including WriteProperty, worked properly.

Kotva
desigo desigo

Comment on Siemens Desigo devices

...

Based on the document "DESIGO INSIGHT: Installation, setup, and communication - Engineering guide", the recommended address settings for LonWorks communication are:

• DomainID: 0x49
• SubnetID: 1
• NodeID:
  • 1..100 - range reserved for automation stations (PX) and system devices (BACnet routers)
  • 101..120 - operating devices and DESIGO INSIGHT management stations
  • 121..127 - temporary operating operator devices (e.g. the PXM20 operator unit) and tools (DTS)

...

The test configuration contained Moxa NPort 5150 (a converter from UDP to RS485) connected to the converter MBG-MSTP converter, which communicated with a heat meter Siemens UH50-A21R-SK06-G. Only analogue inputs was detected. The converter The analog inputs were read, the MBG-MSTP converter supported ReadProperty only ReadProperty.
The communication was revived according to worked with the following configurationsettings:

• Line: SerialOverUDP Device Redundant with the IP address and port of the Moxa NPort 5150
• The parameter parameters of BACnet protocol that which are configured on the line:
  MS/TP address: 6 (any address 1-254 that does not clash with other addresses on the RS485 bus)
  MS/TP N max_info_frames: 20. Default The default value is 5. If this parameter exceeds the number of I/O tags, it causes that all I/O tags are loaded to be read in one cycle (as regards the periodical loading), which is not interrupted because of sending a token. We recommend you not to increase the value of this parameter if other master devices are connected with RS485 and they , which could have problems if they do not receive any a token for a longer time.
  MS/TP usage_timeout: 99. According to a standard, the value must be under 100 ms. Default The default value of 20 ms caused the problems with communication (MBG-MSTP did not manage to react till within a specified timeout).
• Type stationStation type: MS-TP
• Address: 1 (according to the configuration of MBG-MSTP)
• I/O tag configuration:
  Request type: ReadProperty
  Object type: analog-input(0)
  Instance: according to the configuration of MBG-MSTP or a device which is behind it

Kotva
ilon10 ilon10

Comment on iLON 10 Ethernet adapter

...

When using the iLON 10 Ethernet adapter for communication you should realize that the communication processor of this device (Neuron 3120) has relatively short default buffers (network buffer is 66 bytes). Therefore it does not receive the longer packets. It can be seen in the web interface of iLON 10 - on the Status tab Status and , the parameter Missed Messages increases number increases when trying to read the value (e.g. always after saving the I/O tag if its parameter Subscribe/read is marked). This problem occurred during testing when schedule a time plan of a scheduler contained more than 4 pairs 4 time-valuevalue pairs. When there were 4 pairs, the length of the LON message was 63 bytes. After adding next another pair via PXM20, the loading reading of schedule the scheduler failed.

Warning! The NodeUtil utility Nodutil enables to increase the size of the received packet by increasing of both the network and application bufferbuffers. However, if you set improper values, you can damage the iLON 10 device (Neuron 3120 stopped communication with the user processor).
If you decide to preset reconfigure the size of buffers, just change it from 66 bytes to 88 (and reduce the number of buffers) because the KOM process informs, in its packets, that it is able to receive 50-byte ASDU (+ 3 bytes BACnet header 3 and 16 bytes and LON header 16 bytes).
The buffers of the PCLTA-10 ISA adapter (built on the Neuron 3150 communication chip Neuron 3150) had the long enough buffers (255 bytes).
After we bought the a new iLON 10, the configuration was successful with these parameters:

• configuration software: Echelon Node Utility Release 1.82
• size sizes and quantity quantities of buffers:

    DEVICE:0> (B)uffer configuration
    Node buffer configuration
    Type			Count	Size	Bytes
    Receive transaction	11	13	143
    Transmit transaction	2	28	56
    App buffer in		2	82	164
    App buffer out		2	82	164
    Net buffer in		5	82	410
    Net buffer out		2	82	164
    App buff out priority	1	82	82
    Net buff out priority	1	82	82
    ==> Total bytes = 1265

Kotva
easylon easylon

Comment on Easylon USB Interface+

...

The use of the Easylon USB Interface+ adapter on 64-bit Windows 10 (with 32-bit D2000) has been tested.
It was necessary to specify the device name EasyLVU11-3-Mip0 in the line configuration (the EasyLVU11-3-Vni0 device did not work). The OpenLDV 5.1 driver had to be installed on the computer.

Kotva
mstp mstp

Comment on BACnet MS/TP implementation

...

The implementation of BACnet MS/TP is not complete yet. It was tested only on basic in an elementary configuration (the D2000 KOM against a BACnet MS/TP MicroGateway produced by the York company). The communication works with both the Serial line (RS485/RS232 converter was used) and SerialOverUDP Device Redundant line (Moxa NPort series 5xxx was used).
MicroGateway (York company) implements the communication of an MS/TP Master type (i.e. it sends the frame the Poll for master frame to detect the existence of other Master stations). The D2000 KOM relies on a partner station and does not contain the implement a method of sending of this frame type. Also, it does not solve handle a failure of the station to which it sends a token.
The actual present implementation is applicable only for communication with one Master station. It can be applicable used for communication with one or more Slave stations (not tested). Also the time ratio could cause some problems in loaded systems, i.e. KOM could answer to the frames Poll for master or Token later than in required time, which may cause the collisions on the line. The time ratios may become worse when you activate the logs on the (not tested). Also, the time ratio could cause some problems in heavily loaded systems, i.e. KOM could answer the Poll for master or Token frames later than required, which might cause collisions on the line. The time ratios may become even worse when you activate the logs on the line.

Kotva
bbmd bbmd

Comment on BBMD (BACnet Broadcast Management Devices) support

The following feature concerning the conversion of text names to numeric addresses of measured points (Siemens Desigo devices) on the TCP/IP-UDP line has been added to the BACnet protocol (and is available in versions published after 17.01.2012): if the KOM process sends a Who-Has request and the I-Have response comes from another IP address, the KOM process searches for the station that sent the Who-Has request with the text name specified in the response (within the line). If such a station is found, the answer is matched to its challenge.
This feature is useful when communicating with multiple Siemens routers (behind which are, for example, BACnet/LON devices), one of which is configured as a BBMD (Bacnet Broadcast Management Device) and the other is not.
Model situation:
The KOM process communicates with two Desigo PXG80-N BACnet routers (Rtr1 and Rtr2). Behind each router is a LON network, for simplicity with a single Desigo PXM20 station (Des1 or Des2). Router Rtr2 is configured to forward BACnet broadcasts from the LON network to Rtr1.

• Rtr1 has an IP address of 10.0.0.1 and has BBMD functionality enabled. Behind Rtr1 is the LON network with network address 11 and a Desigo PXM20 device (Des1) with address 1.1
• Rtr2 has an IP address of 10.0.0.2 and has BBMD functionality turned off. Behind Rtr2 is the LON network with network address 12 and a Desigo PXM20 device (Des2) with address 2.2

Let's have one TCP/IP-UDP communication line and on it two BACnet/IP stations representing Des1 and Des2

• L.Bacnet line:  TCP/IP-UDP type
• Station B.Des1:
  Station type: BACnet/IP
  Address: 10.0.0.1 (address of Rtr1, behind which Des1 is located)
  Port: 47808 (standard BACnet port)
  Destination network: 11 (address of network behind Rtr1)
  Destination address: 1.1 (address of Des1 in a LON network)
  Register-Foreign-Device: enabled (for the KOM process to register as a broadcast recipient on Rtr1, which has active BBMD functionality)
• Station B.Des2:
  Station type: BACnet/IP
  Address: 10.0.0.2 (address of Rtr2, behind which Des2 is located)
  Port: 47808 (standard BACnet port)
  Destination network: 12 (address of network behind Rtr2)
  Destination address: 2.2 (address of Des2 in a LON network)
  Register-Foreign-Device: disabled (Rtr2 has inactive BBMD functionality)
• Any I/O tag M.Des2_test on B.Des2 station (e.g. of SubscribeCOV type) with Address type = Name

The KOM process sends a Who-Has request to the Des2 device to convert the text name configured in the M.Des2_test address. The IP address of Rtr2 (10.0.0.2) is used for sending.
Rtr2 forwards the request to the LON network to Des2 (according to the parameters Destination network = 12 and Destination address = 2.2 specified in the configuration of B.Des2 station ). An I-Have broadcast response arrives from the BACnet/LON device Des2. As the BACnet router Rtr2 is without BBMD support, it forwards the response (assuming it is configured to do so) to the BACnet router Rtr1, which has BBMD support enabled.
Rtr1 forwards the I-Have message as a UDP packet to the KOM process because the Register-Foreign-Device parameter of B.Des1 station is configured and thus the KOM process has registered as a broadcast message recipient at Rtr1. This way, the I-Have message gets to the KOM process with a different IP address than the original request. The functionality described above matches such a response with a request from the B.Des2 station based on the match of the text name of the object in the sent request.

At the same time, one configuration limitation results from the described procedure - all the described activities take place in the context of one line, so it is necessary that all stations that are within the scope of one BBMD device are located on one line.

Kotva
tell_cmd tell_cmd

Tell commands

...

ANSI/ASHRAE Standard 135-2001: BACnet - A Data Communication Protocol for Building Automation and Control Networks

ASN.1 Complete by Prof. John Larmouth

Info
title Blogs
You can read blogs about BACnet protocol: Communication - BACnet protocol  Communication - BACnet protocol, part 2 Communication - BACnet protocol, part 3

Kotva
zmeny_upravy zmeny_upravy

Changes and modifications

...

Kotva
revizie revizie

Document revisions

...

Ver. 1.0 - August 30, 2005 - first version

Ver. 1.1 - October 20, 2005 - support of schedulers, reading, and writing of ASN sequences

Ver. 1.2 - November 22, 2005 - support of

...

dynamic detection of I/O tag address from the object name, address cache in a file

Ver. 1.3 - June 14, 2006 - support of BACnet router (tested with PXG80-N)

Ver. 1.4 - April

...

02, 2008 -

...

partial support of BACnet MS/TP protocol (tested on BACnet MS/TP MICROGATEWAY on the cooler produced by York company)

Ver. 1.5 - June 25, 2010 - testing the cooperation with E-DDC3.1 from SE-Elektronic GmbH

Info
title Related pages:
Communication protocols

...