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.

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

Good catch on the Jetty default. That requestHeaderSize limit comes from Jetty itself (the embedded web server Mango runs on), and Mango doesn't currently expose a mango.properties setting that maps to it. Mango exposes other web server tuning properties (web.threads.maximum, web.requests.queueSize, file upload and websocket buffer sizes, etc.), but request header size isn't wired through. A couple of options: Trim the proxy's injected headers. If your in-house proxy is adding several large headers, reducing what it injects (or moving some of that data to a request body/cookie instead) addresses the actual cause rather than working around a limit. Terminate at a reverse proxy in front of Mango. Nginx or Apache in front of Mango (see our HTTP and HTTPS Settings guide) gives you a layer where header size limits are configurable (large_client_header_buffers in nginx, for example) before the request reaches Mango's embedded Jetty server at all. This is likely your most practical fix given the limit is coming from Jetty's defaults.

@mihairosu FYI - Image issue with the forum has been fixed.

Hello @mihairosu, Single data point not publishing from MangoES to MangoEnterprise, steps to try: If other points on the same publisher are working but one specific point is not arriving on the Enterprise side, the most common cause is an XID mismatch introduced when the point was removed and re-added to the publisher. Work through these steps in order: On MangoES: Go to Publishers and open the publisher sending to MangoEnterprise Find the entry for the affected data point and note its Published Point XID (this is separate from the data point XID, it typically looks like PP_xxxxxxxx) Confirm the data point itself is healthy: add it to a Watch List and verify it is receiving fresh values from the Modbus source Confirm the data point's Logging Type is not set to Do Not Log, some publisher configurations will not forward a point that has no logged values On MangoEnterprise: Go to the Data Source that receives published data from MangoES Find the data point that is supposed to receive this value and open its configuration Look at the Point Locator, it will contain the Published Point XID it is listening for Compare this XID to the one you noted on MangoES, if they do not match, this is the cause To fix: Update the Point Locator on the MangoEnterprise data point to match the current Published Point XID from MangoES Save the data point, then disable and re-enable the data source on MangoEnterprise to force it to reconnect If the XIDs already match, also check: The data point and its data source are both enabled on MangoEnterprise The data type on the Enterprise point matches what MangoES is sending (e.g., both NUMERIC) The publisher on MangoES shows a healthy connection status with no errors The remove/re-add step almost always generates a new Published Point XID on MangoES while the Enterprise side still holds the old one, updating the Point Locator on Enterprise is usually all that is needed

@joeamiraglia Just wanted to confirm that the latest update as of a couple of days ago, was successful.

Its good to see the validation of mango is fixed.