Timeouts when discovering BACnet device
-
I have BACnet devices with 1500+ data points. I am unable to discover data points. Although I set the timeout to 600000 ms (600 secons/5 minutes) I still get timeout errors. I can discover smaller devices with approx 300 data points, although even this operation takes an unusually long time.
-
@carnecro
are they the same kind of devices? You may have to adjust this setting as shown below: -
@carnecro could you share a screen shot of the timeout error, I wonder if this is not an API timeout.
-
@CraigWeb IMO it's an issue with Bacnet4J library. I can discover all these devices and objects with many Bacnet clients (Yabe, BacEye, Tridium Niagara, etc). So I have written a small application using Bacnet4J and when I am reading object list from a device with 750 data points, I get an error
error reading object list: ErrorAPDU(errorClass=services, errorCode=operational-problem,errorClass=services, errorCode=operational-problem)
There is no problem to read points from a device with approx 250 data points. Because I can read all objects with all other clients I have I assume it's Bacnet4J issue related to MaxAPDU setting.
-
@CraigWeb FYI I checked the device with 750 data points in BacEye (BacEye can communicate with this device without any issues):
-
@CraigWeb Mango doesn't give me much information where to look for the problem. That's why I wrote a BACnet client using BACnet4J. I have found that problems with BACnet4J occur when the discovery process tries to read information about a larger number of points. I can't say where the limit is. I've experimented with segmentation, ReadPropertyMultiple, APDU timeouts, all with no reasonable results.
What do you mean by API timeout? Personally, I don't think anyone has tested BACnet4J in this configuration.
-
@CraigWeb The problem is clearly a bug in the Bacnet4J library during the segmented response to ReadProperty. From a certain number of objects the server returns a segmented response. Bacnet4J for some reason misses the first segment of the response and therefore repeats the request. This leads to an error. Here are screnshots of the communication in the case of Bacnet4J and Yabe.
Yabe
Bacnet4J
I think that nobody has ever tested segmented responses, otherwise they would have found this problem.
-
I opened a ticket on GitHub Bacnet4J, but honestly, I don't believe anyone will bother with it. There are quite a lot of bugs described there, and I've documented and described some, but no one is responding. For me it is annoying because I bought a license to use Bacnet4J commercially (it was not cheap), but as it turns out, the library is not of good quality and especially there is no support. I do not recommend using it for professional implementations.
-
@carnecro I have created an internal ticket regarding this. We will be looking into it. If you are able to provide any wireshark captures to help us we would appreciate it.
-
@CraigWeb I apologize for the false alarm. I analyzed everything again with Wireshark and found out that the problem was a misconfigured firewall.
If the data are transported in multiple segments, the server obviously opens a new socket for each Complex-ACK. For us, the direction from device to Mango was blocked for BACnet. After modifying the rules on the firewall everything works fine. Sorry again.
-
@carnecro Not a problem, I would recommend upgrading to 4.5 there are 2 changes on the Bacnet module.