BACnet – Brief Introduction to Basics Part 6

Objects data types and their use

For exploratory utilities and utilities, it is usually not necessary to address the data types, the values are interpreted according to the standard and displayed in human-readable form. However, if we map the BACnet property to the variables of the process station or visualization program, sometimes we have to decide which data type to select in the program, because editors can allow very flexible work with data types.

Analog values

The situation here is probably the simplest one. Present Value for Analog Input, Analog Output, and Analog Value objects is Real according to IEEE 754 standardization, 32-bit Single-precision floating-point format. Everything should work if we also use a variable of the standard Real type in the client program, see the example of reading the value in section 3.

Multistate values

Multistate values are integer variables that represent various possible states of a data point. We can find them in the objects Multistate Input, Multistate Output and Multistate Value. An example of a multi-state value is a three-stage fan coil fan, which can have four states:

  • Level 1
  • Level 2
  • Level 3
  • Off

According to the standard, the series should start with the number 1 (not zero) and continue to the highest state without spaces, ie eg 1, 2, 3, 4. The number and names of states and their numerical values are defined by the manufacturer – the author of the BACnet server. This information can also be available directly in the object in the form of the optional State_Text property, which is a field with state descriptions.

0601_multistate_list

Fig. Status texts for the Multistate Output object.

In the case shown in the figure, the data point can be in the Auto, Off or On state. The current value is 1, ie Auto – see the Present Value property.

If the State_Text property is not supported, you have no choice but to contact the manufacturer for documentation.

In the BACnet telegram, the value is transmitted as type uint, therefore in the client program the relevant variable must also be defined with type UINT, if the program in the BACnet client driver does not have automatic conversion to this type. Otherwise, the server will most likely return an error when trying to write the BACnet value. Helps explore the Wireshark statement for problems.

0602_multistate_merbon

Fig. Definition of a multistate variable in the Merbon IDE

Binary values

As the name suggests, these variables take on one of two possible states. BACnet allows you to mark each state with text, such as “On” and “Off”, using the optional Active_Text and Inactive_Text properties.

The Present_Value property is usually of type enum, an enumeration of (two) values. The BACnet standard allows two more types of binary value encoding: application-tagged and context-tagged. Most drivers automatically detect the type of encoding when loaded, so nothing needs to be done to read the values. Exceptionally, however, writing may not work. At this point, it means for us that if the Type: Enumerated value does not match when writing, we will try to select one of the other types in the Merbon IDE – BoolApl or BoolCtx.

0603_binary_typy

Fig. Select the value type for binary input, output, or value

Schedule

The weekly time program is one of the more complicated types, it is a structure with a variable length according to the number of transitions between states. The Schedule object contains both a weekly table (Weekly_Schedule) and an exception table for holidays, vacations, holidays, etc. (Exception_Schedule).

Again, Wireshark can help you troubleshoot reading or writing problems with time programs. A common problem where the schedule set in the visualization cannot be written to the device can be caused either by a limitation in the device’s internal memory (typically for room thermostats and similar simpler devices), or by incorrectly set or missing segmentation – pay attention to the Max APDU Length Accepted property. . This is a mandatory feature of every device. Indicates the maximum allowable data packet length that the device is capable of processing. If the device does not support segmentation and the Max APDU Length Accepted is too short, the schedule may be written only partially, chaotically, or not at all. It already depends on how well the BACnet is implemented in the device.

The minimum value of an APDU according to the standard is 50 bytes, which is not much: for example, an APDU with a length of 209 bytes can contain a maximum of about 11 changes – transitions between states of the weekly time program. The maximum APDU length for BACnet MS / TP (via RS485) or ZigBee is 480 bytes. It is therefore advisable to check in the Wireshark program listing how long the packet is being sent, whether this length complies with the Max APDU Length Accepted and whether the device has received the packet correctly.

All parts can be found HERE.