Any object type CAN have a Description property, but it is optional. Similarly, there is nothing wrong with the fact that your code asks info on vendor object types, what was wrong was that when it got the unknown object response, it stopped any further requests. It should, if anything, report that error in the results, and carry on. If you are only asking for objects returned by an object_list request, you SHOULDN'T ever see that error, but BACNet manufacturers are notorious for not checking everything out, and bugs like this exist everywhere. The error just needs to be handled gracefully.

In the case of those bugged devices, those points are AV's, but are not being reported as such properly in the object_list. I'm in communication with the manufacturer about getting the firmware fixed.

At a quick glance, it looks like you aren't handling when le and re might both be false. If that is the case, x is never initialized.

So, some issues. The results table is not generated properly. The heading reflects the new Description column added, but the results do not. (see attached image) The description is getting fetched properly, as it shows up in the Point Details if you click 'Add Point', but the table is not being populated. Also, fetching the descriptions is pretty slow, as it is fetching them one at a time, instead of using RequestPropertyMultiple as all the other requests. It might be a lot quicker if the description fetch was done in the same loop as the one issuing the RPM's for object-name, units, and present-value.

I've got some devices (CRC-RPM1) that return screwed up object types for 2 of the AV's in the object list. For these, instead of ignoring the object, it looks like mango is going forward and requesting info about it. When the description request is sent for those bad objects, the unknown-object error response seems to halt the scan - I guess this needs some error handling.

I've got other devices (sadly enough, the major bulk of my device count - our vav controllers - Alerton VAVi-SD), which are returning the descriptions properly, then when the first RPM request is sent to get object-name, units, and value for the first 6 objects, no response is received at all from the device. It retries 2 more times, and after no response, the scan just stops.

Other than the display issue, and the poor handling of even poorer devices, this seems to be working. Our Alerton VLX controllers (very large point density) work great, other than being pretty slow to get through all those points individually.

Attachment: download link

Excellent, i'll give it a whirl tonight. Though my testing will be limited, as only 4 of my 1200 devices show up on a device scan due to linux's improper handling of broadcasts when bound to an IP. I'm sure that is on the BacNet4J side, so I'm not sure if you work with that, but it seems the only fix is to bind twice, once to the interface address, and once to the broadcast address - or switch to windows, which just doesn't sound fun.

That does appear to have fixed the MAC address issue, and I am also not getting the socket error now either (it may have been a result of the BacNet4J calls being made incorrectly due to the MAC problem). So this seems to have sorted it. Now, on to slightly other issues since you are looking in that code, is there a way to pull the 'Description' property instead of Object Name? in most bacnet devices I've dealt with, Object Name is a hard-coded string tied to the actual hardware input, and not necessarily what the point represents. Description is usually much more meaningful, and would be the best candidate for populating the Point Name field.

Really, to be proper, there should be no REQUIREMENT to tell the module the MAC address or Link Service ID. Bacnet should be able to properly find any device with nothing more than the Device Instance number. If the other information is NOT fed to the module, it should use WhoIs messages to find that information (and it can then cache it for further requests). Any point should be able to be set up using nothing but the Device Instance, Object Type, and Object Instance. Ex: Dev 240110, AV-101

Okay, so I'm at work now, so I checked this out some more. I was wrong before. The network number is what is in the parentheses, and the MAC is before it. The points DO work if entered manually with JUST the MAC integer in the MAC field, network number in Network number field, and the gateway's IP:port in the Link service IP field. But there are at least two actual problems.

1. Transferring information from the Device Scan results to the Object scan settings brings over the entire string "MAC(NETWORK)" and puts that in the MAC field - needs to JUST be the MAC address.
2. The object scan throws a socket exception even when the information is entered properly manually.

I believe the network is the first number, and the MAC (MSTP MAC addresses are a single byte integer, 1-255) is in parentheses (20).

I believe this is the same problem I reported here: http://forum.infiniteautomation.com/forum/posts/list/1633.page

with no response.

Joel,
Did you ever look further into this issue?