BACnet4J FDR: Custom Development, Not Configuration

On the Mango M2M panel, the remote BACnet site never becomes available across the Internet path. Discovery retries do not change the result. Start here: this is not an address-tuning fault when the connection design depends on Foreign Device Registration (FDR). The stated BACnet4J stack does not provide that function, and no plan to add it was identified.

Reject fixes that cannot add FDR

Engineers often attack the network first. That work can remove a transport blockage, but it cannot make BACnet4J generate a registration transaction that the stack does not implement.

Do not spend the service window cycling the application, widening firewall rules, or repeating discovery. First determine whether the topology specifically requires FDR. If it does, configuration changes inside a non-FDR stack are a dead end.

Identify the missing protocol function

BACnet discovery commonly depends on broadcast traffic. Broadcasts are limited by IP routing boundaries, so a client outside the BACnet/IP network needs an explicit mechanism to participate in that broadcast domain.

With FDR, a foreign device sends a registration request to BACnet infrastructure that accepts foreign-device registrations, commonly a BACnet Broadcast Management Device. That infrastructure maintains an entry for the foreign device and forwards applicable broadcast traffic to it. The foreign device must also renew its registration before the accepted lifetime expires.

This is application behavior, not merely routing. The client stack needs logic to send the registration request, process the response, maintain registration state, renew it, and recover after communication loss. If BACnet4J lacks that logic, Mango M2M cannot become a foreign device by entering a remote address in a configuration field.

Confirm that the topology requires FDR

Do this check before changing code or commissioning a gateway.

1. Draw the path from Mango M2M to the remote BACnet site. Mark every routed boundary, address translation point, firewall, and BACnet broadcast-management component.
2. Identify the component at the remote site that accepts foreign-device registrations. Obtain its configured address and registration policy from the site administrator; do not infer them from a device-discovery result.
3. Decide whether the required operation depends on broadcasts. Device discovery usually does. Known-device unicast communication may follow a different path, but it does not replace discovery or make the client a registered foreign device.
4. Capture traffic while starting the BACnet connection. Look for an outbound foreign-device registration transaction and its response. If the application never emits the transaction, stop troubleshooting the return route.
5. Record the installed Mango M2M and BACnet4J versions from the running system. Version data belongs in the development request and acceptance test; do not substitute a version from another installation.

A remote site described only as “FD capable” still needs a concrete endpoint, an enabled registration service, and a network policy that admits the client. Measure those items separately from the client-side feature gap.

Choose the implementation that works

The direct path is custom development and support for FDR in the BACnet4J stack. No standard Mango M2M configuration step can replace that code.

1. Define the required scope: initial registration, response handling, renewal, loss detection, re-registration after restart, and diagnostic reporting.
2. Give official support the installed product and stack versions, the remote foreign-device endpoint, the network topology, and a packet capture showing the missing registration transaction.
3. Request a testable build or supported implementation. Require visible registration state and actionable failure diagnostics; a silent retry loop is not an adequate field diagnostic.
4. If custom development is not acceptable, redesign the connection. Use an external component that supports the required foreign-device role and presents data to Mango M2M through an interface Mango already supports, or place the application within a network architecture that carries the required BACnet traffic correctly.
5. Review the revised path with both the BACnet administrator and network administrator before opening access. Each must validate a different layer.

A private routed connection can protect and transport IP packets, but it does not automatically extend broadcast behavior. Confirm how discovery and forwarded broadcasts traverse the new architecture rather than treating basic IP reachability as proof.

Verify registration before testing objects

Test from the bottom up. A successful device or object read is useful, but it does not prove that registration renewal and broadcast forwarding will remain healthy.

1. Confirm bidirectional IP transport to the configured foreign-device endpoint.
2. Capture the initial FDR request and the remote response. Match both packets to the intended endpoints.
3. Check that the application reports an active registration state rather than merely an open socket or running BACnet service.
4. Observe a renewal cycle using the lifetime accepted by the remote infrastructure. Read the actual configured or returned value; do not invent a renewal interval.
5. Run remote device discovery and compare the result with the site’s expected device inventory.
6. Read a known object from a discovered device, then verify normal polling or subscription behavior required by the project.
7. Interrupt and restore the path. Confirm that the client detects loss and registers again without requiring a manual application restart.

Avoid recurring commissioning traps

• Do not confuse an open firewall with a registered foreign device. Transport permission and BACnet registration are separate states.
• Do not validate only unicast reads. A known remote address can work while discovery and forwarded broadcasts remain broken.
• Do not leave address translation undocumented. Packet captures on both sides must show which address the remote BACnet component records and where it sends forwarded traffic.
• Do not hard-code an assumed registration lifetime. Use the remote policy and verify renewal on the wire.
• Do not widen Internet exposure to compensate for missing client behavior. Restrict the path to the defined endpoints after the protocol flow works.
• Do not treat one successful registration as the finish line. Test renewal, application restart, network interruption, and recovery.

FAQ