@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.