BACnet Troubleshooting

Below are common issues customers run across with BACnet. We recommend looking at the following issues to see if any help resolve an existing issue.

Discover Issues

When it comes to discovering issues, it can be several different things. Below, we'll go through some ways to check this.

1. VPN – Broadcast discover does not work over VPN. Only unicast (specifying specific IP in the Custom Broadcast Address field) discover works. The user could also manually add the connectors with their proper info.

2. Ping – Next would be to try and ping the device to see if there is a response from it. If no response is returned, then it’s not discoverable as it can't be found on the network, you would need to contact your IT department to help figure that out. If it does respond, then it could be a firewall issue. Follow the next step for that. Here is a website on how to be able to ping a device: How to Use the Ping Command .

3. Firewall/Rules – If the device did respond to the ping, then the user can try disabling the firewall to see if they could then discover their devices. If the user still can't discover the devices, then it is likely some other network issue and would require IT department assistance. If they are discoverable, then the user can leave the firewall off or create some rules that would allow BACnet packets to be transmitted over the network because they are being blocked with the firewall on. 

   1. To add Inbound and Outbound rules to allow BACnet traffic over the network, do the below:

      1. Open your firewall advanced security settings window

      2. Click on Inbound Rules to create a new rule

      3. Select Port for type of rule

      4. Then select UDP to apply the rule to that

      5. For the specific ports, enter the standard BACnet port of "47808"

      6. Then select to allow connection to apply for all types

      7. Then give it a name like "BACnet" or something you want so that you know what it’s for

      8. Then repeat for Outbound Rules

      9. After that, the user should be able to re-enable the firewall and BACnet ports should be open for traffic

4. Multiple BACnet Instances – In the BACnet world, you can't have multiple BACnet IP instances running at the same time on the same machine without multiple network interface cards (NIC) configured on the machine to handle that. This means that you can't have 2 FIN instances or FIN and some other BACnet client running on the same machine using BACnet IP. You would have to stop the other instance using BACnet IP and then try discovering.

5. Network Number – Can’t discover devices from a specific network (or not able to communicate with the devices from a specific network)? Chances are that the device network number is conflicting with a FIN network number. All the networks should be unique in a BACnet network. FIN uses 2 network numbers for the Client and Server (can be found in the BACnet Global Config window), no matter whether Server is enabled or not. Double check the network numbers on the devices with FIN and confirm there are no conflicts here.

   1. BACnet Server Network Number - by default in the UI it is 65531, but in the BBS Stack directory, it is 4. You can enable BACnet Server ext to change it, but once disabled it changes it to the same as the client in the directory. You would need to modify the file directly.
      The path to it is something like this but with your version: C:\Program Files (x86)\FIN Stack\FIN Stack v5.1.1.110\lib\java\ext\BBS_LIB\system.
      The file you want to open is bbs.conf (prefer an advanced notepad such as notepad++) and look towards the bottom for line 73 or 101. It should be the Dnet property and modify the one that isn’t the client network number.

6. Discover Settings – Sometimes it can be as simple as invalid discover settings. Below are various discover settings to check.

   1. If devices are on a different port other than the standard 47808, use the Custom Broadcast Address field to include the custom port because the default uses port 47808.

      1. Examples: 255.255.255.255:47809, 10.10.10.255:47809, 10.10.10.107:47809 etc.

   2. Make sure Start and End Instance Numbers are a valid range for the device(s) being discovered. Make sure it is between 0 (start) and 4194303 (end).
      Note: To send a global broadcast as an unconstrained “Who Is”, set both the Instance Number Start and End to -1. This will send a broadcast without the low/high instance limits. When the BBMD receives these global broadcast requests, it will then forward it to it’s peer BBMDs.

   3. Make sure the Network number is valid and within 0 and 65535.

7. BACnet Route – If connecting through VPN and if the network number is 0. The bacnetRoute tag will need to be added to the BACnet connector in order for it to communicate and for the connector to know where the device lives. The reason is because VPN does not support broadcast messages such as who-is and i-am. The bacnetRoute tag is a string type and its value is the router IP address and it goes on the connector. This tag adds router IP entry in router table in stack. Generally router table is updated automatically when I-Am-Router-To-Network or I-am BACnet request comes to FIN. In case we don't receive those requests then we can manually add router IP using bacnetRoute tag. At least one device from the device network should have the bacnetRoute tag. Below is a query that can be used to automatically add these.

   readAll(bacnetConn).findAll(conn => conn["uri"].toStr.contains("dnet=")).map(conn => conn.merge({bacnetRoute: conn->uri.uriHost})).unique("bacnetRoute").toRecList.map(conn => conn.diff({bacnetRoute: conn->bacnetRoute})).commit

8. Logs – To check the logs, go to Host -> Debug -> Log to see if there is an error that appears when trying to discover, then check below if it is listed and follow the steps on how to resolve it.

9. BACnet Extensions – Make sure related BACnet extensions are enabled such as FIN BACnet, BACnet, and BACnet Server (if used).

10. BACnet Server – Using FIN as a BACnet Server on a BBMD environment? Might need to register FIN as a Foreign Device to be able to discover it over the network.

    1. Using Niagara to discover the FIN devices in this type of scenario? Make sure to set the MAC address to 1 and MAC Address Style to MSTP/Other.

11. BBMD and FD – After FIN restarts BBMD/FD configurations will be lost and the user will need to reconfigure them again manually or with some script.

    1. Changing any BACnet Global Config properties will automatically re-initialize the BBS Stack.

12. Local Bind Address – Next thing would be to try changing the local bind address from the wildcard 0.0.0.0 (default) to the server IP hosting FIN in the BACnet Global Config settings window so that the FIN BACnet client knows who is doing the broadcasting. Without specifying this, it could mean that the FIN BACnet client could not bind to the local address due to another channel configured to use the same IP and port.

Network Diagnostic

1. Tracert - This is more of a network check. It is recommended to make sure all BACnet traffic is being routed to the same network IP rather than some other IP.

   1. Open the Command Prompt

   2. Type in tracert <ip of server> for example tracert 10.10.10.107

   3. When looking at the trace, it should have returned the same IP you have entered

   4. If it’s some other IP, then BACnet traffic is being routed differently that it was not configured properly. You would need the IT department to help route this properly. 

2. Netstat - This is just to check if multiple sources are using the same port 47808.

   1. Open the Command Prompt

   2. Type in netstat -a -b | find "47808"

Point Fault Issue

The user would need to know first if they are using COV or Polling. The user can find out if the point is in COV or Polling mode by looking at the Point Debug Info towards the bottom under the BACnet section and see if it is set to “isCov” or “isPolling”.

COV - There are a couple ways a point can be faulted when set up as COV. 

• If FIN gets no response from the device, fault status is returned (could mean that device is faulted, or getting overwhelmed with a lot of requests and unable to respond)

• If the device itself sends a fault status of the point to FIN (could mean that the point doesn't exist or is truly faulted in the device)

When it comes to COV, make sure that the “cov_increment” property is properly configured on all the analog points. Basically make sure that they aren’t set to such a small value that would trigger a ton of COVs and flood the network. This is property found on the object in the device side.

Polling - There are a couple ways a point can be faulted when set up as Polling.

• If FIN gets no response from the device after 3 successive requests (or whatever is specified in the BACnet Global Config window for retries), then the fault status is enabled. (could mean that device is faulted, or getting overwhelmed with a lot of requests and unable to respond)

• If the device itself sends a fault status of the point to FIN (could mean that the point doesn't exist or is truly faulted in the device)

When it comes to Polling, we recommend creating multiple tuning policies that run at different intervals so that not everything is polled at the same. By staggering them, it would be easier on the device as it only processes what is needed more often. Here is the Tuning Policy doc we created that the users could use or get an idea of how to configure theirs using the Tuning Policy Tree.

Errors - These errors that can be found on the point indicate that the point is in Fault in the remote device (this info can be found in the  Point Debug Info or in the point Essentials “Reading” section):

• curErr==Remote status err: remoteFault

• curStatus==remoteFault

BACnet objects have a property called STATUS_FLAGS, which is composed of 4 flags that represent {IN_ALARM, FAULT, OVERRIDDEN, OUT_OF_SERVICE}. But when we print out a list of flags (called BitList) we print it from right to left so the first flag is the right-most. This can be checked by running the  bacnetReadObject(@bacnetConn_Id,@point_Id) func in folio, which will display properties of that point. The STATUS_FLAGS property value will have something like this BitList(0 0 1 0), you can see that the flag that has a "1" is the second one (remember from right to left) it corresponds to FAULT. So, the point is in FAULT in the device. This can be confirmed via a Wireshark Tool capture as well or just within the device.

Issue 1: Connector state is ‘closed’

The ‘closed’ state (not status) indicates that your connector is in idle mode. This is normal. The reason why a connector is in idle mode is because there is no watch active on it.

To have a watch active:

• Open and view a point from the connector (On View Only)

• Trended (Always a watch active)

• Programs (Always a watch active)

• Alarms (Always a watch active)

• Graphics (On View Only)

• Point Graphics (On View Only)

• Summaries (On View Only)

Issue 2: Connector status doesn’t appear in the list view

Connectors are required to have the bacnetDeviceName tag. If for some reason it doesn’t exist, the connector status will not be available, therefore won’t be able to disable/enable those connectors. The dis tag is required for these queries to write to the bacnetDeviceName tag whatever the dis tag value is. Run these queries in Folio to apply this to any BACnet connector that might not have the bacnetDeviceName tag on it. A restart of the FIN service is required.

If for some reason the dis tag doesn’t exist either, then the user will have to manually add the dis as a string and the value being the name of the connector via the property editor.

Issue 3: “ErrorTag { OBJECT:UNKNOWN_OBJECT}” error

This typically means that the address instance of the object is invalid/does not exist. The user would need to find the object they are trying to use in the device and confirm the instance. Then update the instance on the point/connector.

For example, a point might have AI1 for the instance when first configuring the project. Later on, for whatever reason, it is no longer AI1 but instead A14 or the object may no longer exist at all. If the former, then the user would need to update the instance. If the latter, then the user would need to delete that point from the database.

Issue 4: “ABORT_OTHER Object:DEV1102” error

This is a networking error. It means the device is not online (not pingable) or there is a conflict of networks/instances. For example, having multiple Ethernet routers with the same network number. Go through your network topology and verify that there aren’t any conflicts such as network numbers and instances on the same network etc.

Another case is having a router in between. So the devices may be fine but when you restart the FIN service they are faulted and only recover if you do a discover for example. In this case, follow the BACnet Route #7 under the Discover issues to resolve this.

A rare case could be that the connectors don’t have a “bacnetDeviceName” tag, which is required. Once that tag is added, restart the FIN service for them to re-initialize and sync with the bacnetDeviceName. Look at Issue 2: Connector status doesn’t appear in the list view on how to add these with a query automatically.

Issue 5: “BBS Stack registry entry missing or invalid registry entry.” error

This error means that the BBS Stack registry is not initialized, which means BACnet will not work. This would be typically be found on Windows instances when using the zip to run FIN. Follow the “Setting BBS Manually” section in the BACnet Connector doc.

Issue 6: “sys::Err: com.siemens.bt.bbs.adapter.arch.exceptionhandling.InitModeNotSupportedException: Init mode null not supported.” Error

This error means that the BBS Stack registry is not initialized, which means BACnet will not work. This would be found more on Windows instances when using the zip to run FIN. Follow the “Setting BBS Manually” section in the BACnet Connector doc.

Issue 7: “BBS Stack initialization failed with status : null” error

This means that the BBS Stack registry is missing in the Registry Editor. Some external service or someone must have removed it. This is typically on a Windows instance. A reinstall is required to get this working again. Make sure to make a backup of the var folder in the FIN directory before re-installing.

Issue 8: “BACSTAC_STATUS_SERVICE_NOT_FOUND” error

This error means that another BACnet client is running on the same instance. It needs to be stopped or look at Multiple BACnet Instances #4 under the Discover Issues section above.

Issue 9: “sys::Err: java.lang.Error: Invalid memory access” error

This error means that another BACnet client is running on the same instance. It needs to be stopped or look at Multiple BACnet Instances #4 under the Discover Issues section above.

Issue 10: “Duplicate Request.” Error

This error means that either there are duplicate instances on the network when they should be unique or that there is another BACnet client running on the same instance. Double check the network or if the latter look at Multiple BACnet Instances #4 under the Discover issues section.

Issue 11: “Ping Failed.” error

This means that the ping command was not successful since the device didn’t respond to it in time. Likely the device is still booting up and/or busy processing packets. Give it a few seconds before trying again.

Issue 12: Point is not changing value

This can be a few things. We’ll cover some of these scenarios below.

1. If commands are not going through, check the Point Debug Info and see if a curWrite error is being thrown. A couple of example errors below and what they mean.

   1. ErrorTag { PROPERTY:WRITE_ACCESS_DENIED} Object:AI4 – means that said object (AI4) is not writable. The Writable should be disabled on this point.

   2. ErrorTag { PROPERTY:INVALID_DATA_TYPE} Object:AV52 – means that commanding it to null or said value is not valid on said object (AV52 in this case).

2. If commands are going through, make sure the point being commanded isn't being commanded at higher priority on the device side. You can check this with the Bacnet Priority Array tool. If something is written at higher priority, you can either release that value so that FIN controls it, or adjust the bacnetWriteLevel so that FIN controls it at a higher priority.

3. If commands are going through, but confirm that it is not a priority level issue, check to see if the point is COV based on the Point Debug Info. If yes, try disabling the firewall or adding an inbound rule for port 47808 (or whichever port is being used for BACnet traffic) and see if it works. Some devices send COV as broadcast messages instead of unicast, which in turn gets blocked by the firewall.

4. If commands are going through and not a priority or firewall issue, then check if the point has both bacnetHis and hisCollectInterval and/or hisCollectCov. The bacnetHis and hisCollect tags should not be applied at the same time. Only one should be enabled, either the bacnetHis or hisCollect tags. Below is a query to quickly find all points that have both of these types of configurations so that they can be updated to only use one method. We recommend to sync history (bacnetHis) from the device instead of hisCollect in FIN as it is more efficient.

   readAll(bacnetHis and (hisCollectInterval or hisCollectCov))

Issue 13: Point writes hit or miss

If the commands go through sometimes and it is confirmed that it is not a priority or COV issue covered in #3 of Issue 12: Point is not changing value above, then it is recommended to create a tuning policy that is applied to all points and add the writeOnStart and writeOnOpen marker tags to that tuning policy. If you already have existing tuning policies for points, you can just apply these tags to those tuning policies instead.

Issue 14: Point showing incorrect value

The case here was that a point would read a certain value, then a couple minutes later change to something drastically different. This wasn’t occurring on the device side. This turned out to be a networking issue. Check the network topology to make sure there are no duplicate instance numbers between devices. Having duplicate instance numbers even on different subnets is not compliant with BACnet standards.

Issue 15: Points keep faulting every few seconds (MSTP)

This is more of a network tuning issue and most often related with MSTP devices. If there are MSTP devices on the network with slow baud rates, we recommend following the Tuning Policy doc and adding bacnetDisableCov tag to all the tuning policies to make everything polling based. Then set the APDU Timeout property to 6 seconds in the BACnet Global Config window. Then disable and re-enable all the BACnet connectors. Give a few minutes for all connectors to re-establish connection.

The following is a website on how to troubleshoot MSTP: Troubleshoot MS/TP Network

Issue 16: Point fault types

Below are some point curStatus fault types and what they mean. The full curStatus error can be found in the Point Debug Info window under the “Conn Cur” section.

• Error 1: connExt::RemoteStatusErr: remoteFault. A “remoteFault” error means that the point in the remote system is in fault state. This is not a FIN issue, but rather something in the BACnet device side. It could be that the device is offline or that particular object that the point is referencing is no longer valid/exists or something else.

Issue 17: Alarms not coming in

Below are some common areas to check based on what customers have encountered:

1. Ensure that the alarmable BACnet object(s), including Event Enrollment (EE), exist in the database for the alarms to be synced.

2. Verify that the Notification Class (NC) exists in the device before assigning it to an object.

3. Check the recipient-list in the Notification Class (NC) table to determine if the processId is empty or different from FIN's processId (333). It is crucial to ensure that FIN's processId is included. If there is an existing processId entry that is different from 333, add the bacnetAlarmPid number tag with the corresponding processId value to a tuning policy. This tuning policy should be applied to the BACnet connector.

4. To verify whether alarms are being generated by the device but not received in FIN, run the below function in Folio → Launch with the ID of the BACnet connector. If the function returns any results, it indicates that the alarmable BACnet object(s) do not exist in FIN, as described in point #1.
   Function: bacnetGetUnhandledAlarms(@conn_id)

5. Check release notes of newer builds to see if any alarming improvements may already address the current issue.

6. Still not receiving alarms even with the latest updates? Capture the network traffic with Wireshark while triggering some alarms, then share the capture with our support team to provide a network report diagnoses.

Still having trouble?

If none of the above steps help, be sure to provide Point Debug, Connector Debug, Network Topology (comm riser), Wireshark captures, point/connector info and a detailed description of the behavior that is occurring based on your observation.

Point and Device info

If the Point Debug and Connector Debug don’t already include some of the following info, please gather and provide the below. A quick way is to take a screenshot of the Property Editor (‘i’ icon) of the point and connector records. Only one set of errors are needed per issue since all others would have the same error. Once the issue is figured out on one, the resolution can be applied to all.

• point instance (if applicable - maybe only having a connector issue and not a point issue)

• device IP

• device instance

• device network number

Wireshark capture

follow this process when capturing Wireshark packets.

• stop FIN

• start Wireshark and start recording on the network that has the BACnet traffic

• start FIN

• reproduce the issue

• stop the Wireshark capture and save it to send over

Logs

The logs can be found in the directory. The path should be something like this: C:\Program Files (x86)\FIN Stack\FIN Stack v5.1.1.110\var\log. The name has the date stamp on it and the latest would be best.

Event Viewer logs

This is usually for BBS initialization issues on Windows machines. It provides some useful info on the BBS service to see what is happening.

• Stop the FIN service.

• In the Windows Start menu search for “Event Viewer”.

• Then go to Window Logs -> Application on the left side.

• Look for BT BACnet Stack v6 in the Applications list view if any.

• Clear them all.

• Start the FIN service.

• Then select “Save All Events As…” on the right of the Event Viewer to save a copy and send over.