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 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

...

• 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)

...

BACnet protocol 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 within the whole network). This object contains other 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 Who-Is and Who-Has Request types.
Each object has properties, which can be mandatory or optional. Moreover, each producer of BACnet devices can implement other properties when necessary.
The messages in the BACnet protocol are related to the manipulation of objects and their properties. They are defined 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 items of 'Abstract Syntax & Notation' type. It means that any sequence (or "tree"), the meaning of which is defined by an implementer, can be 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:

...

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

...

Line protocol parameters specific for BACnet MS/TP

...

• Station type: BACnet/IP station must be configured on TCP/IP-UDP line. LonWorks station must be configured on the LonWorks 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 is related to the line configuration. On the LonWorks line, a membership to one or two domains can be configured. On BACnet station, 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. For TCP/IP-UDP line, it is a 16-bit number (or it is not set, see Note 2).

• Kotva
  destionation_network destionation_network

  Destination network: 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 if the KOM process communicates with the device that is 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, 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 behind a BACnet router)
  The KOM process communicated with the PXC22 device which was connected to a LON network via PXG80-N BACnet router. The KOM process communicated with a BACnet router over Ethernet, so the line is TCP/IP-UDP. The communication between the BACnet router and the PXC22 station was performed over a LON network.
  
  

  Kotva
  pozn2 pozn2

  Note 2: We tested a similar configuration. We used Delta Controls DSM-RTR (connected over Ethernet network) and a Klimasoft MBG device (a gateway to M-Bus) connected to Delta Controls via an MS/TP interface. The communication started only if the Destination network (value 50020) and Destination address (value 96) were configured and the Source network was not specified. However, in another configuration, the communication worked also with the 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 do not have to, see note about E-DDC3.1) set also the parameter Destination network. The Destination address parameter should be in the subnet.node format (if the destination device is on a LON network) or in the A.B.C.D format (if the destination device is on a BACnet/IP network).
  
  Note 1: On a BACnet/IP station you can configure the Destination address in the subnet.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 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. The default value is:
  • 1467 octets for TCP/IP-UDP line
  • 487 octets for SerialOverUDP Device Redundant or Serial lines (BACnet MS/TP)
  • 55 octets for LonWorks line
    
    The limitation depends on the size of packets 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 complying with the stations which are able to process only smaller messages. Currently, the reduction of Max APDU influences only the size and amount of ReadPropertyMultiple-Request messages. These messages are intended for a periodic reading of 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, by means of which the KOM process informs a partner how big 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. 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 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 when retrying to send the message.
• COM_ERR: The value of error counter for the station when the station switches to COM_ERR status. The situation when the station does not reply to a read/write request is considered as an error. A negative confirmation of a command (refusal of writing) is not an error. The default value is 5. See the parameters Timeout and retry.
• HARD_ERR: The value of the error counter for the station when the station switches to HARD_ERR status. The default value is 10. See the parameters Timeout and retry.
• Register-Foreign-Device, R-F-D Time to live: In this example, 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 of UDP broadcasts is disabled or the KOM process is placed in a different segment of the network than the BACnet router (so it does not receive any UDP broadcasts), you should check the option Register-Foreign-Device on the station. This will cause the KOM process to send the Register-Foreign-Device message to a BVLC router (BACnet Virtual Link Control) after the start. The message 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 Register-Foreign-Device. It defines the expiration of registration that stops the sending of UDP unicasts. That is why the KOM process must ask the BACnet router to re-register it before TTL expires. If there are more stations behind a BACnet router, just 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 Register-Foreign-Device message with 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 solutions (the communication over iLon Ethernet Adapter, the placing of the KOM process on the same segment in the network on which 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. Otherwise, Who-Is and Who-Has requests won't work (and thus addressing by object's name), as responses to these 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 MS/TP address line parameter). If the addresses of all Master stations are lower than the address of the KOM process, the token is given to the Master station with the lowest address. If no Master station has been configured, the KOM process supposes to be the only master and does not pass the token. You should get the information about the type of station from a producer or device documentation.
  
  Note: The current implementation of the BACnet protocol does not contain the automatic search 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:

...

• 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 is configured on the Time parameters tab of station. TheReadProperty-Request message is used for the request and the ReadProperty-Ack message is the response from the device. The periodic reading 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 ReadProperty-Request message is sent if the Subscribe/read checkbox is checked.
  • ReadPropertyMultiple - the functionality is similar to the previous parameter. Unlike ReadProperty, more object properties are sent in one request/response, so communication is much more effective. TheReadPropertyMultiple-Request message is used for the request and the ReadPropertyMultiple-Ack message is the response from the device.
    The ReadPropertyMultiple-Request message is sent if the Subscribe/read checkbox is checked.
  • WriteProperty - the WriteProperty-Request message is used for writing the values. The Application tag parameter must be specified as well. If Subscribe/read is checked, the written value is verified by reading from the station using the ReadProperty-Request message after writing.

  • Kotva
    subscribecov subscribecov

    SubscribeCOV - activation of reading of object value when they change. If the Subscribe/read checkbox is checked, after starting, the KOM process sends the 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 (ConfirmedCOVNotification-Request message) or the unconfirmed ones (UnconfirmedCOVNotification-Request). The confirmed notification requires an explicit confirmation from the KOM (the BACnet-SimpleACK-PDU message), so puts more load on the network. However, the probability that the notification will be lost is lower than in case of using unconfirmed notifications (if the device does not receive a confirmation, it repeats the message).
    
    Note 1: Besides the dynamic registration by the 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 be left unchecked.
    Note 2: The registration can be sent at regular intervals (e.g. because of a potential failure of the device power supply). You can set this interval on the station - the 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 than the present value) and Increment - a size of increment which causes the change to be sent (i.e. a dead band).
    The SubscribeCOVProperty-Request message is sent.
    
    Note: The Siemens PXC64-U device did not support the Increment parameter.

  • Kotva
    whois whois

    WhoIs - the identification message Who-Is-Request to detect the type of Device Object in a device. The I-Am-Request message is the response (it contains the 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 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 I-Have-Request message (it contains the fields deviceIdentifier, objectIdentifier, and objectName). 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 checked, you can use the information from the BACnet cache, which is much faster than detection from the communication.

  • Kotva
    readwritescheduler readwritescheduler

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

  • Kotva
    geteventinformation geteventinformation

    GetEventInformation: 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 acknowledgment of alarms that have been read by the GetEventInformation request. 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. On the other hand, the Delta Controls devices 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 instance number is queried dynamically from the communication. To avoid the overloading of communication lines when starting the KOM process, data is stored in a BACnet cache.
  • Object type + Instance: enter the type of object and an instance number. This is recommended for BACnet objects with 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: an object identification number 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 specified exactly, i.e. spaces in the beginning and at the end are not tolerated, and the upper and lower case letters must correspond to the object name that is stored in the BACnet device.
• Property type: type of property - only PropertyIdentifier is specified for Simple, and both PropertyIdentifier and Complex address must be specified for Complex. The complex type of property is necessary for the parsing of OEM-extended standard messages (items of 'Abstract Syntax & Notation' type). When sending the ReadProperty-Request, ReadPropertyMultiple-Request, SubscribeCOV-Request, and  SubscribeCOVProperty-Request messages, the Complex address is ignored.
• Property identifier: identifier of an object property. You can use the predefined properties or configure a numeric identifier of new property which was defined by the OEM 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 by the OEM manufacturer.
• Array index: some properties may be defined as 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 context tags which application type is unknown because it is the extension of messages defined by the OEM manufacturer. The exception is an output tag of text type that is considered to be 'AnyTree', if the application tag is unspecified, and it can be used to write any user-specified ASN sequence.
  
  Note: If 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 the 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. 3 in this sequence (again, it must be a sequence),
  2 - it is the second tag in order in this sequence (again, it must be a sequence),
  1 - it is the first tag in order in this sequence.
  The address in 'tree' starts from the propertyValue level (see the examples below). The easiest way to view the parsed message is to turn on debugging for a line and watch the debug info on the console or in the line log file.
  
  Example 1: Let's have a device that contains the object of type 2 (Analog Value) with instance number 1. 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 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 specify 3). Tick off the checkbox Subscribe/read 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 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 to the first found value after parsing of the message (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 checked, 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 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 check the Subscribe/read checkbox in one of them only.
  
  Note 1: If the I/O tag was created with a complex address 1, its value would remain Unknown, because this address matches the 1st element in propertyValue, which is a sequence, not a simple type.
  
  

  Kotva
  pozn2 pozn2

  Note 2: The I/O tag of Text type is able to contain not only simple value but also any ASN sequence. The values are written according to rules for 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, 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: the checkbox specifies whether the device 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 respective messages for reading/registration of value changes are sent for the configured Request types:
  ReadProperty: the ReadProperty-Request message
  ReadPropertyMultiple: the ReadPropertyMultiple-Request message
  SubscribeCOV: the SubscribeCOV-Request message 
  SubscribeCOVProperty: the SubscribeCOVProperty-Request message 
  ReadWriteScheduler: the ReadProperty-Request message

...

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

...

The times and values separated by a semicolon are read into the text value (see Note).
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 of 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 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.

...

Kotva
note_schedulersiemens note_schedulersiemens

Note: Another possibility to write weekly-schedule, besides the ReadWriteScheduler request, is 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 schedule for the whole week, if Array index is not set and the value contains 7 sequences for 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} { T0:0:0.0; u3; T1:2:0.0; u1; T2:0:0.0; u2; T5:30:10.0; u3}".

...

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

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

...

Kotva
events events

Information about events

...

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

...

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

...

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

Example: The following list of alarms and events was 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 === 

...

After acknowledging of alarm and a repeated reading of the list of alarms and events by the GetEventInformation request , you will see the alarm has been acknowledged, 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 low-limit state, i.e. it is an active acknowledged alarm.

To read the list of alarms, to show them in a browser, and to acknowledge the alarm, you must write the ESL scripts which will parse the text value of GetEventInformation request 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.

...

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) is saved to the cache file and is available for the next start of the KOM process.
There is one cache file for every station. It is 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 is reloaded from this file. If the file was not found, the Who-Has messages are generated 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 were changed when changing the configuration). Just delete the cache file in this station and save the station - within several seconds, the cache file will be created again and 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 checked in the configuration of the I/O tag, the cache is not searched and the Who-Has-Request message is sent to the communication. The obtained information is not written to the cache. It can be used for the objects that are generated and deleted dynamically, which would otherwise congest the cache.
• If Subscribe/read is not checked 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 response comes, the information is written into the cache.

...

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

...

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 longer packets. It can be seen in the web interface of iLON 10 - on the Status tab, the Missed Messages 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 a time plan of a scheduler contained more than 4 time-value pairs. When there were 4 pairs, the length of the LON message was 63 bytes. After adding another pair via PXM20, the reading of the scheduler failed.

...

Info
title Blogs
You can read blogs about BACnet protocol (for now, in Slovak language only): Communication - BACnet protocol  Communication - BACnet protocol, part 2 (SK) Communication - BACnet protocol, part 3 (SK)

Kotva
zmeny_upravy zmeny_upravy

Changes and modifications

...