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?

Not at work currently, but just re-downloaded/installed them Monday, so judging by the web site, I'd recon core-2.1.0 and bacnet 2.0.3.

Upon further playing, it seems that setting the bind to address to 0.0.0.0 screws up actual data point access - so that's a non-fixer. I did see this thread, that seems to indicate a possible fix for the quirky behavior in regards to linux/java/local IP bniding/broadcast reception.

http://stackoverflow.com/questions/835960/java-on-linux-listening-to-broadcast-messages-on-a-bound-local-address

I actually had already disabled IPv6 on ubuntu, but didn't do so in java itself.

I added the preferIPv6Addresses=false and preferIPv4Stack=true to the ma-start.sh script, and it allowed binding to the broadcast address, but then it wouldn't receive directed packets. It really looks like the only way to get around this 'limitation' in linux+java is to bind to both the broadcast address, AND to the interface address with separate bindings, and route packets from either to the parser.

When discovering bacnet points, would it be possible to set the point's 'Name' to the value returned by the Description property instead of the Object_Name property? Perhaps maybe only if Description is actually populated, and if not revert to Object_Name? On most controllers, Object_Name is tied directly to the hardware (AI-1, for instance) and is in no way related to the actual point data being represented. Description, on the other hand, is usually the writable property that describes what the point value represents.

When discovering bacnet points, would it be possible to set the point's 'Name' to the value returned by the Description property instead of the Object_Name property? Perhaps maybe only if Description is actually populated, and if not revert to Object_Name? On most controllers, Object_Name is tied directly to the hardware (AI-1, for instance) and is in no way related to the actual point data being represented. Description, on the other hand, is usually the writable property that describes what the point value represents.

So i am getting through my device scan issues, as discussed in other threads, and have come upon a new issue. I get results from a BacNet discovery. This is on a site with about 1200 or so devices, most MSTP devices connected to BACNet/IP based global controllers:

For the Bacnet/IP devices, clicking on the 'Get Details' arrow works fine, adding yet another insanely long list to the bottom of the already insanely long page.

For the Bacnet/MSTP devices that are accesed via Bacnet/IP routers, however, the web page has a problem dealing with the MAC Address as displayed. Using Device 501201 in the above image as an example, clicking on the Get Details arrow presents the following error (related to the MAC address entry):

Entering the proper values into a new Remote Device Object query starts to work:

It gets the object list properly, and displays the table, but something goes wrong when performing the RPM request for the object name and values. It may be due to the simple controllers limits (I don't believe they support segmentation), but there is something bacnet4j/mango doesn't like that is halting the process.

So i am getting through my device scan issues, as discussed in other threads, and have come upon a new issue. I get results from a BacNet discovery. This is on a site with about 1200 or so devices, most MSTP devices connected to BACNet/IP based global controllers:

For the Bacnet/IP devices, clicking on the 'Get Details' arrow works fine, adding yet another insanely long list to the bottom of the already insanely long page.

For the Bacnet/MSTP devices that are accesed via Bacnet/IP routers, however, the web page has a problem dealing with the MAC Address as displayed. Using Device 501201 in the above image as an example, clicking on the Get Details arrow presents the following error (related to the MAC address entry):

Entering the proper values into a new Remote Device Object query starts to work:

It gets the object list properly, and displays the table, but something goes wrong when performing the RPM request for the object name and values. It may be due to the simple controllers limits (I don't believe they support segmentation), but there is something bacnet4j/mango doesn't like that is halting the process.

Attachment: download link

Okay, so that helps in one regard. By changing the datasource's bind to address to 0.0.0.0, it is now recognising the I-Am's resulting from the global Who-Is, and populating the (VERY LARGE) table of device results. Which comes to the next issue. The list is ordered in the order the results come in, and there is no way to sort the list. Finding an item on a site with >1200 devices would be quite a chore (luckily, find works).
I did find another issue which I'll put into a new post, as ti is unrelated to the actual network issues.

@mlohbihler said:

The version of Mango you are using does not send WhoIs to find devices. It expects to be configured to find them without WhoIs. (Except for the discovery tool, of course.)
Actually, this looks related to my other post. It looks like, when starting up, mango DOES send out an undirected who-is - but since it is not seeing the broadcasted i-am's, it is still unable to route to the appropriate link. On the devices that DO respond directly the the source of the who-is, it then requests some capabilities - but it still won't actually poll a point using the device instance and object alone (which it really SHOULD be able to do). I wouldn't think you'd need to set up network numbers, MAC addresses and link service IP, unless specifically needed by network topology. That information should be able to be obtained via basic bacnet who-is requests and i-am responses.

My concern, is that by having to specify the link service IP and MAC address, you eliminate the REASON for bacnet having a device instance number (meaning a specific name for a given piece of equipment, regardless of network topology to get there). BACNet should be immune to issues involving IP changes and such, and should always be able to find a given device by instance number alone.

The way i would like to see it done:
If a point's details include network/MAC/link service IP, it will use them. However, if left blank, then on enabling of the point, it will perform a who-is on that device, and fill in the missing data in the dynamic online database, and use that going forward for communication with that device. It will not, however, write that information to the stored database, as next time that point/data source is enabled, it may very well be different.

No response on this call for help?

I am attempting to pull points into a new mango install from a large existing campus. The equipment is mostly Alerton hardware. I have, to date, been unable to get it to pick up any of the alerton hardware (non-alerton hardware comes in fine), and after some deep wireshark time, I have found the issue. The Who-is is sent out properly, on the designated interface (192.168.92.247), to the proper broadcast address (192.168.92.255). All the hardware responds with I-AM messages, but the Alerton hardware is broadcasting the I-AM to 192.168.92.255, and not sending it directly to the mango server (192.168.92.247). These broadcast messages are being ignored by Mango, and as a result, I cannot add those devices to the datasource.

Is there a way to get Mango to acknowledge i-am messages on broadcast? I am not sure if the standard requires I-AM's to be only directed, or if they could be broadcast, but I see no technical reason why mango shouldn't listen for directed AND broadcast responses.