Alex Wells

Thank you Steve, it took a bit of figuring out because the outbound REQ APDU is shaped differently to the inbound ACK APDU. However, calling it like this seems to make all the unpacking work as expected: apdu_decode_confirmed_service_request(&apdu[2], apdu_len - 2, ... ) One last question: bacfile performs a check using "apdu[0] == ... ", but apdu_handler in apdu.c uses "apdu[0] & 0xF0 == ... ". Is there a functional difference between what the two of them are trying to do? Thanks again!

Is there an easy way to extract detailed information about the (failed) request when in Ack, Error, Abort, or Reject handlers? We're given the source, which through the address cache gives us the device ID, and the invoke id which can get us the APDU through the TSM's cache. I found the apdu_decode_confirmed_service_request() function, which can give me the CONFIRMED_SERVICE type, but I see no way to use the service data returned - there seem to be no decoding functions for the outgoing APDUs? For...

Thank you for the information Steve. So I think this indicates the correct solution in my case is to use RPM to request a series of specific indexes, the exact number depending on the APDU (which we retrieve from an IAm) Is there an easy way to calculate how many octets a single object-list instance is, so I know how many could fit in a response? Thanks again :)

Hello, I'm currently developing a Bacnet network scanner/monitoring tool. It'll scan for all devices, and for all devices get the list of all objects (and from there get all interesting properties, but that's beyond this question) What I want to do is to use ReadProperty(Multiple ) to get the entire object-list at once, and then iterate through it and request each object's properties in turn. However, many of the devices I have to scan have maximum APDU sizes of 206 bytes and contain 1500+ objects...

Binary releases on GitHub are pretty easy if you use a shared action. Here's one I use on other projects: https://github.com/softprops/action-gh-release If all you want to put into the release is whatever CMake's default built items are, then adding this to the end of the main.yml file with an appropriate list of files should be all that's needed. It'll get trickier if you want to publish the apps also built in gcc.yml - I suspect you'd need to refactor the two separate workflows into a single one,...

Thank you for that work Steve. it looks like I went on Christmas holidays mere hours before you submitted this, and so unfortunately the Git invite you sent me has expired. I expect to try out the code at some point in the next week or two. While I'm here, is there a particular tagging policy for Bacnet-Stack? I note the last one was from mid-2020, and if possible I'd prefer to base my work on a tagged version. Thanks again :)

Thank you for the feedback Steve. I'll look at adding your suggestion to the handler, although probably not until the new year at this point. There were also a few other changes I've had to/will have to make on my own checkout for my own use (e.g. I have to support ~10k subscriptions, so the MAX_COV_SUBCRIPTIONS of 128 ), so may neaten them up and throw those into a PR as well.

Thank you for the feedback Steve. I'll look at adding your suggestion to the handler, although probably not until the new year at this point. There were also a few other changes I've had to make on my own checkout for my own use (e.g. I have to support ~10k subscriptions, so the MAX_COV_SUBCRIPTIONS of 128 is somewhat problematic), so may neaten them up and throw those into a PR as well.