Please Note This forum exists for community support for the Mango product family and the Radix IoT Platform. Although Radix IoT employees participate in this forum from time to time, there is no guarantee of a response to anything posted here, nor can Radix IoT, LLC guarantee the accuracy of any information expressed or conveyed. Specific project questions from customers with active support contracts are asked to send requests to support@radixiot.com.
Newbie Bacnet questions
-
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
-
I have changed some of the module code but I don't have a way to test the gateway side of things. Would either of you mind helping me out by testing it for me? I am attaching the updated jar file.
To test:
- stop Mango
- make a backup of the file: $MA_HOME/web/modules/BACnet/lib/m2m2-BACnet-x.x.x.jar
- delete the original file so it is no longer in the $MA_HOME/web/modules/BACnet/lib/ folder
- place the attached m2m2-BACnet-2.0.4-beta.jar into the $MA_HOME/web/modules/BACnet/lib/ folder
- start mango and check discovery
When done if this doesn't fix the problem replace the beta jar with the original to revert back.
This fix is only for #1 of CraziFuzzy's noted issues.
Issue #2 about the Socket being closed is going to take some further digging. The error is being propagated from within the BacNet4j library and isn't directly part of the mango code.
Attachment: download link
-
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.
-
Here is a beta version for a new module that will use the Description from an Object for the point name if it exists. If there is no description it will fallback to using the Object Name. Please give this a test and let me know if it performs as expected. Thanks for your assistance.
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.
-
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
-
Thanks for taking the time to test that you for me. I will make some changes this week that should fix those issues. I’ll post back when I’m done.
-
-
Table should be fixed, I must have forgotten that code change in the posted module. Perhaps you need to clear your browser cache to pickup the new javascript? Either way I'm sure that code is in this version of the module
-
I've added some error handling and cleaned up the way the description is requested. Please let me know if that works now. I am not sure what object types will allow a request for the description so I hope what I did works.
-
The unknown-object errors you are receiving can probably be fixed but I'm not sure of what constitutes a 'screwed up' object type? It appears as though the code is able to handle object types 0-30 and then anything else is labeled 'Vendor Specific'. Should we not request anything else for the types > 30?
Attachment: download link
-
-
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.
