Viconics VWG-50 (Classic ZigBee) BACnet Integration Manual User Manual
Page 29
29
Tips and Things You Need To Know
After the initial configuration of your device and if your BAS allows you to remove objects, we suggest that
you remove all objects not used by your application. This will prevent unnecessary polling of non-used
objects and to help speed up the network. This is mandatory on MS-TP integrations. A fully loaded VWG
can contain upwards of 800 objects for 30 controllers.
Be sure all controllers connected to a VWG are using the same PAN ID and Channel as the VWG.
The BACnet Data Link layer has two key parameters: the device object name and the device object ID.
The device object name must be unique from any other BACnet device object name on the BACnet
network (i.e. not just the main IP network or MS/TP sub-network). The device object ID must be unique
from any other BACnet device object ID on the entire BACnet network (i.e. not just the IP network or
MS/TP sub-network). The device object ID of the VWG can be set using the VWG configuration software
tool.
Room Temperature, Outdoor Temperature and Room Humidity need to be set Out Of Service if you want
to write to the objects. When Out Of Service is set to True, the local value will be derived from the BACnet
network instead of the value at the controller.
For VT7200 and VT7300, the System Mode MV xx exposed and usable index is limited by the currently
selected Sequence of Operation MV xx. A change in the Sequence Of Operation MV xx will set the active
system mode and also restrict the usable range that a local controller can accept.
For VT7300, Fan Mode MV xx. Controllers will not accept all possible index values. VT7300 fan mode
input is dependent on local Fan Configuration. Fan actual current value is read at FanStatus.
Device Name and Device ID properties are writable in Viconics’ device object. Both properties can be
renamed from any BACnet network management tool as long as the tool itself give access to write to
these properties.
All writable BACnet objects will have their Reliability flag raised to “Unreliable Other” if a VWG has not
been able to successfully get an acknowledgement of the wireless write command after the mandatory 5
wireless communication retries set at 15 seconds interval each. The next successful write event will lower
the “Unreliable Other” BACnet object flag when the wireless write success message is received by the
VWG.
The heartbeat delay object represents the total amount of time a single controller has not updated its
mandatory 3 minutes heartbeat update to the VWG. If the VWG does not receive a heartbeat update from
an individual controller, this object’s present value will increment from 0 to 3000 minutes by 3 minutes
increment every 3 minutes. As soon as the controller comes back online to the VWG and update its
mandatory heartbeat, this object present value will revert back to 0 minutes.
All objects ( with the exception of the Heartbeat Delay ) attached to a single wireless controller will have
their Reliability flag raised to “Unreliable Other” if a VWG has not received the mandatory 3 minutes
heartbeat update message from a wireless controller to the VWG. As soon as the wireless heartbeat of a
controller is received again, all objects will then have their Reliability flag lowered to normal again. This
scheme is used to display if any specific controllers are still online to the VWG. The VWG has a build in
protection in cases where the controllers are offline on the wireless side and read or write BACnet
requests are still coming in. If a controller wireless heartbeat has fails, the VWG will not issue any
wireless messages out to a controller until the wireless heartbeat of a controller is received again.
When the VWG boots up after a power failure or a restart, no BACnet request will be accepted either for
reads or writes for 5 minutes. This is done to insure the BACnet communication is authorized only when
all wireless controllers are re-joined to the VWG. This process can take up to 5 minutes including the
application boot-up. If any read or write BACnet commands are received within the 5 minute delay, a
“Device Busy” Device error class reply will be given to any incoming request.
The VWG will also return a “Device Busy” Device error class reply to any incoming BACnet request when
the VWG is too busy. This is done to prevent bogging down the VWG in “abnormal” BACnet read or write
request situations. I.E. when you send more BACnet read or write request than the wireless network can
handle with all wireless retries.