Re: Copying/recreating a Meta Data source from project to project

@SGAF apologies for the long delay on this; here’s a complete walkthrough.

Exporting the Meta Data Source

1. Go directly to the Meta Data Source itself (Data Integration > Data Sources, select it).
2. Click the ⋮ menu in the top right and choose Export with points, this exports the data source and all its meta points together as JSON in one step, without going through the full Import/Export page.

Preparing the JSON for the new site

3. In the exported JSON, give the Meta Data Source a new, unique xid for the new site (e.g. META_SITEB), unless you intend to overwrite an identical one already on the target.
4. For every meta point under dataPoints, update its dataSourceXid to match the new Meta Data Source’s xid, and give each point its own unique xid as well (e.g. prefix with the site name, like SITEB_DP_ZoneTemp).
5. This is the step you already identified: each meta point’s script references context points by XID (the real underlying data points it reads). Those context XIDs need to be remapped to the equivalent real points on the new site before importing.

Importing

6. Go to Administration > Import/Export, paste or upload the edited JSON, and import. You need an admin account, non-admin users get a “Permission denied” error on import.

On the error you hit
The most common causes of an import failing are:

• A data point’s dataSourceXid doesn’t match any data source in the import or on the target (often from a typo when reassigning XIDs)
• A duplicate XID that collides with something unrelated already in the system
• Malformed JSON from a manual edit (missing comma/bracket), which shows up as a generic “Bad Request” instead of a specific error

If you still have the exact error message or result summary Mango gave you, paste it here and we can pinpoint it directly.

One more option: if you’re doing this for many similar sites, it may be worth scripting the XID remap with something like jq against the exported JSON rather than editing by hand each time, this avoids the typo/bracket issues above. Happy to help put that together if it’d save you time.

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

The RD201C is a higher-performance edge gateway for demanding industrial environments: an Intel quad-core processor, dual Gigabit Ethernet, isolated digital I/O, and expandable storage, running Mango by Radix IoT for enterprise-grade edge data collection and control.

Specs:

Supported protocols: BACnet IP, BACnet MS/TP, Modbus TCP, Modbus RTU, DNP3 IP, DNP3 Serial, MQTT Sparkplug B, SNMP, HTTP JSON, SQL, gRPC, InfluxDB Line Protocol, Serial, SSH (additional protocols available via Mango by Radix IoT modules).

Also includes TPM 2.0 for hardware-rooted secure boot and credential storage.

Full details and datasheet: radixiot.com/hardware/rd201c

For anyone asking what hardware is currently available from Radix IoT: the RD50 is a compact, fanless edge gateway built for field deployment. It runs Mango by Radix IoT out of the box, connecting serial and IP devices at the network edge with minimal power draw.

Specs:

Supported protocols: BACnet IP, BACnet MS/TP, Modbus TCP, Modbus RTU, MQTT Sparkplug B, HTTP JSON, SNMP, Serial (additional protocols available via Mango by Radix IoT modules).

Full details: radixiot.com/hardware/rd50

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:

1. 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.
2. 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.

Three patch releases have shipped on each line since the last advisory (5.6.12 / 5.7.5). Affected versions: all 5.6.x releases prior to 5.6.15, and all 5.7.x releases prior to 5.7.8. We recommend upgrading to 5.6.15 or 5.7.8. Full changelogs: 5.6.x / 5.7.x.

Mango 5.6.x

5.6.13 (Sep 28, 2026)

• Security: BouncyCastle upgraded to 1.86, resolving CVE-2026-8763 and CVE-2026-13506 (neither exploitable in Mango's configuration). Apache SSHD, used by Cloud Connect, upgraded to 2.19.0, resolving CVE-2026-56624.
• Security: FreeMarker upgraded to 2.3.35, hardening template loading against directory traversal, XML-escaping xmlns, and restricting a template's ability to list Java system properties.
• Breaking change: Mango may now reject private keys or certificates with unusually expensive key-derivation parameters or malformed subject names at startup, due to stricter BouncyCastle limits on untrusted input.
• Fixed an event-acknowledgement rollback bug, and a failing event handler blocking every handler after it, on the Events page.

5.6.14 (Oct 5, 2026)

• Security: Fixed CVE-2026-84939, a path traversal via a malformed locale identifier, by upgrading the bundled Moment.js UI dependency to 2.31.0.
• Security: Jackson (jackson-databind) upgraded to 2.21.7, fixing two denial-of-service CVEs (2026-91777, 2026-91776). Mango doesn't use the feature behind the first; the second can only be triggered by the remote source a Persistent TCP publisher connects to.
• Fixed the Cloud Connect proxy filter intercepting requests for any hostname under its configured proxy domain even while the proxy itself was disabled, a regression present since 5.6.0. The filter now only registers when the proxy is explicitly enabled.
• Fixed several data sources and publishers (BACnet COV, VMStat, SNMP traps, MQTT Sparkplug, Modbus IP publisher) running on background threads without a security context, which silently dropped event detectors, meta point updates, and reconnect handling.

5.6.15 (Oct 14, 2026, latest)

• Security: Fixed CVE-2026-106451, a local privilege escalation in lz4-java. On a server where Mango connects to ClickHouse, another local user could replace the native library Mango extracts to its temp directory and run code inside Mango. If you can't upgrade immediately, set paths.temp in mango.properties to a directory only the Mango user can write to.
• A BACnet device writing to a published object's non-presentValue properties (e.g. description) no longer sets the corresponding Mango point value; only writes to presentValue do.
• Fixed events raised by non-superadmin users, or by a data source/publisher with no signed-in user, failing to notify configured event handlers and alarm recipients.
• Fixed acknowledging an event as a non-superadmin user stopping its handlers from firing when the event returns to normal.

Mango 5.7.x

5.7.6 (Sep 23, 2026)

• Security: Same BouncyCastle and Apache SSHD fixes as 5.6.13 above.
• Security: Watch-list maintenance events previously evaluated the watch list as superadmin, regardless of who configured the event, so it could suppress alarms on points the configuring user couldn't even read. A new "Roles used to resolve watch list points" setting scopes this correctly. Existing events are migrated to superadmin to preserve current behavior; review them if that's broader than intended. (5.7.x only, not backported to 5.6.x)
• New OAuth 2.0 / OIDC extraClaims feature: fetch additional claims (groups, roles) from an HTTP endpoint for identity providers that can't include them directly in the token. (5.7.x only)
• gRPC connections now send keepalive pings, detecting a vanished peer in about 90 seconds instead of stalling indefinitely. (5.7.x only)
• Breaking change: Same stricter BouncyCastle key/certificate validation as 5.6.13.

5.7.7 (Oct 5, 2026)

• Security: Same FreeMarker hardening as 5.6.13 (lands one release later on this line).
• Security: Same Moment.js (CVE-2026-84939) and Jackson (CVE-2026-91777, CVE-2026-91776) fixes as 5.6.14.
• Same Cloud Connect proxy filter fix and background-thread security context fix as 5.6.14.

5.7.8 (Oct 14, 2026, latest)

• Security: Same lz4-java fix as 5.6.15 (CVE-2026-106451). Also upgrades Spring Framework to 7.0.9, fixing CVE-2026-47884 and CVE-2026-47890 - Mango isn't affected by either, since it doesn't use XSLT views or render view fragments as server-sent events. (Spring upgrade is 5.7.x only)
• Fixed authentication tokens being rejected once a user's password expired, which broke token-based integrations (e.g. polling engines) with no visible error. Token validity no longer depends on password age. (5.7.x only)
• Same BACnet publisher property-write fix and non-superadmin event-handling fixes as 5.6.15.

As always, back up your database and configuration before upgrading, and test in a non-production environment first.

The Radix IoT team is at the Yotta Show this week at Caesars Forum in Las Vegas. The show floor runs Sep 29-30, and we're at Booth 1115.

Tonight (Sep 28) there's a networking event ahead of the show floor opening. If you're in Las Vegas for Yotta or otherwise, stop by the booth once the floor opens or reply here and we'll set up time to connect.

BACnet4J 7.0.0 has landed with an implementation of BACnet Secure Connect (BACnet/SC). Worth knowing about, but also worth being clear-eyed on what it does and doesn't cover yet.

What's there:

• BACnet4J can now act as an SC node connecting to a Hub. If you already have a BACnet/SC Hub Function on your network (from another vendor's device or software), BACnet4J can join it as a node.
• Alongside it, 7.0.0 brings a batch of spec-compliance work: protocol revision bumped to 20 (with further fixes toward revision 30 compliance), a rewritten segmentation handler (clause 5.4 / addendum 135-2020ch-1), stricter decoding of malformed messages, and the new NetworkPortObject and related structures from the 2024 spec.

What's missing:

• No Hub Function. BACnet4J only implements the node side of BACnet/SC. It cannot act as the SC Hub itself, so you still need a separate Hub (another BACnet/SC device or product) for nodes to connect through.
• Not in Mango yet. This is 7.0.0 of the standalone BACnet4J library. Mango's BACnet data source currently ships BACnet4J 6.1.1 (as of Mango 5.6.11 / 5.7.5). BACnet/SC support has not been integrated into the Mango data source or local device configuration, so you can't configure it from the Mango UI today. That's a separate piece of work from the library update.
• 7.0.0 is a breaking release. If you consume BACnet4J directly in your own code, this version carries a long list of breaking API changes (Unsigned32 vs UnsignedInteger, renamed classes, changed exception types, stricter decoding that can now fail reads that previously "succeeded" with garbage data). It's not a drop-in upgrade from 6.x.

If BACnet/SC support in Mango itself is something you need, let us know in this thread.

Repo and full release notes: github.com/RadixIoT/BACnet4J

Mango 5.6.11 / 5.6.12 (Aug 25 and Sep 1, 2026) and Mango 5.7.5 (Aug 25, 2026) contain fixes for several security issues. If you're running an earlier version on either line, we recommend upgrading as soon as your maintenance window allows.

Affected versions: All 5.6.x releases prior to 5.6.11, and all 5.7.x releases prior to 5.7.5.

Vulnerabilities fixed:

• Privilege escalation (core). Any user with a script engine permission could evaluate scripts with arbitrary roles, including superadmin.
• Path traversal (core). File store operations did not reject paths that traverse a symbolic link pointing outside the file store. A symlink placed inside a file store could be used to escape it.
• Modbus serial permission bypass (modbus-ds). The Modbus serial locator, serial write, and scan tools did not require the data source permission, unlike their IP equivalents. Any authenticated user could write to serial Modbus devices or trigger scans.
• BACnet denial of service (bacnet-ds). A malformed or malicious BACnet message could trigger an infinite loop. Fixed by upgrading BACnet4J to 6.1.1.
• Dependency CVEs. A broad set of third-party libraries were updated to patched versions, including Spring Framework, Spring Security, Jetty, Netty, Jackson, PostgreSQL JDBC, jOOQ, log4j, BouncyCastle, and Apache HttpComponents. lz4-java was upgraded to 1.11.1, fixing CVE-2026-59949 (a native-code JVM crash), and Spring LDAP was upgraded to address CVE-2026-41720.

Breaking changes to review before upgrading:

• Evaluating a script while requesting roles the caller does not hold now fails with a permission error instead of being silently allowed. If any of your scripts request roles beyond what the calling user holds, update them before upgrading.
• (5.7.5 only) The REST API now ignores the read-only id property in request bodies. Object identity comes from the URL path or xid instead.
• (5.6.11 only) BACnet REST serialization of CharacterString values now represents the character encoding as an object rather than a byte.

Also in 5.6.12: a fix for OAuth 2.0 / OpenID Connect logins resetting a user's roles to user when oauth2.client.registration.{registrationId}.userMapping.roles.sync is set to false. Roles assigned by an administrator in Mango are now preserved across logins.

As with any upgrade, back up your database and configuration first and test in a non-production environment before rolling out to production. Full details are in the 5.6.x and 5.7.x release notes.

Radix IoT's documentation has moved to a single, unified site: docs.radixiot.com. There's no separate v3 or v4 documentation anymore. Everything lives in one place now.

Sections:

• Getting Started: installing Mango by Radix IoT, configuring your first data source, connecting your first device
• Data Sources: OPC UA, Modbus, BACnet, MQTT, SQL, and 20+ industrial protocols
• Configuration: publishers, event handlers, scripting engines, system settings
• User Guide: data points, alarms, events, reports, dashboard designer
• Administration: backups, database, diagnostics, logging, upgrades
• Security: SSL/TLS, OAuth 2.0, user permissions, audit trails
• Developers: REST API reference, module development, tutorials
• Hardware: IO expansion tools and hardware integrations
• Release Notes: per-series changelogs for every Mango 5.x release

There's a search bar in the header if you'd rather jump straight to a topic than browse.

If you run into a page that's missing something or out of date, flag it here. The site is actively maintained.