• Recent
    • Tags
    • Popular
    • Register
    • Login

    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.

    Radix IoT Website Mango Documentation Radix IoT LinkedIn

    A bug in the UnconfirmedEventNotificationRequest class

    Scheduled Pinned Locked Moved BACnet4J general discussion
    2 Posts 2 Posters 44 Views 2 Watching
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • dev1 spl-hkD Offline
      dev1 spl-hk
      last edited by

      According to the BACnet specification, the Event Values argument of the UnconfirmedEventNotification service is conditional.

      So, in the UnconfirmedEventNotificationRequest class, the line:

      eventValues = read(queue, NotificationParameters.class, 12);

      is not correct. It should be

      eventValues = readOptional(queue, NotificationParameters.class, 12);
      joeamiragliaJ 1 Reply Last reply Reply Quote 0
      • joeamiragliaJ Offline
        joeamiraglia @dev1 spl-hk
        last edited by

        @dev1-spl-hk Thanks for the detailed report, and for pinpointing the exact fix. You’re right on both counts: the BACnet spec (ANSI/ASHRAE 135-2024, clause 21 and clause 13.9.1.1.13) marks Event Values as optional/conditional, and the encoder in UnconfirmedEventNotificationRequest already uses writeOptional for it, so this is a real inconsistency, BACnet4J currently can’t decode a message it’s able to send.

        This is tracked internally and will be fixed in the next release of BACnet4J (targeted for 7.0.0): the fix decodes tag 12 with readOptional instead of read Oh yeah, matching what ConfirmedEventNotificationRequest already does correctly.

        For bug reports like this going forward, the [BACnet4J GitHub repo](https://github.com/RadixIoT/BACnet4J Why) is the best place to file them, the developers who work on the library monitor issues there more closely than the forum. Appreciate you taking the time to trace this down to the exact line and commit.

        1 Reply Last reply Reply Quote 0

        Hello! It looks like you're interested in this conversation, but you don't have an account yet.

        Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.

        With your input, this post could be even better 💗

        Register Login
        • First post
          Last post