The basic function of the gateway is to transform C-Bus data points into BACnet objects. Before we describe the different gateway operation modes, let's say something about the basic philosophy of gateway, which is common to both modes.
The C-Bus driver contains an infinite loop that proceeds through all the points defined in the database, one by one, deciding at each point what needs to be done. What to do depends primarily on the configuration of the point and there are basically three possibilities:
the point is in IDLE mode, in which case nothing is done. This is for example a point that is not mapped to BACnet or an unsubscribed point in PASSTHROUGH gateway mode (see below).
the point is in POLLING mode. For such a point, the driver periodically asks the controller for the value of the point and all changes are immediately updated on the BACnet side.
the point is in the REFRESH mode. In this mode, the point is subscribed during the first loop run to publish information about its value changes on the C-Bus . In subsequent loop passes the C-Bus driver does nothing for these points, the controller sends the point value changes automatically (push). All changes are then immediately updated on the BACnet side. This point mode is default for all active points.
Since version 2.0.48 the gateway has the possibility to work in two global modes, which significantly affect the behaviour of the main loop of the C-Bus driver.
PREEMPT is the original mode before version 2.0.48. In this mode, information about C-Bus objects is collected permanently and BACnet objects are updated immediately. Each data point is either in POLLING or REFRESH mode, only points that are not mapped to BACnet are in IDLE mode. This mode is not very efficient because the gateway collects information that may never be processed at the BACnet central.
PASTHROUGH is a new mode in which the C-Bus driver only collects information about points to which the BACnet client has made a subscribe for CoV (change of value) reporting. You can read more about BACnet CoV for example here. Thus, if no BACnet client is connected to the gateway, all points are in IDLE mode and the C-Bus driver temporarily puts into REFRESH mode only the points that have received a subscribe request from the BACnet central station.
It would seem that the PASSTHROUGH mode is much more efficient in terms of gateway resources and that it significantly reduces the traffic on the C-Bus and the CPU load on the controller. Theoretically this is true, but in practice we discovered that most BACnet central stations do not behave very rationally and immediately perform subscribe for CoV reporting on all points that the gateway offers, even on points that are not handled internally on the central station at all. The building management central is then continuously fed with information that is immediately discarded. In contrast to the Niagara Framework from Tridium, the issue of subscribing only the necessary information is not part of the BACnet specification.
So if your BACnet client uses SubscribeCoV service on all the objects offered by the gateway, stay with the PREEMPT mode, in which there are certain possibilities to optimize the C-Bus traffic. This will be discussed in another blog.
If your BACnet client selectively subscribes only to the objects it currently needs, change the mode to PASSTHROUGH.