BACnet4J can place a ReadProperty request on the network while VTS remains silent if the receiving VTS port has no BACnet network number. Follow the packet from the BACnet4J caller through the physical interface, address and port selection, VTS port context, simulated device, and objectList property. Seeing the request in a capture proves transmission, but it does not prove that VTS accepted the request into its device model.
Where does the BACnet4J request stop?
The request originates at localDevice.sendReadPropertyAllowNull(d, d.getObjectIdentifier(), PropertyIdentifier.objectList). The destination object is the Device object returned by d.getObjectIdentifier(), and the requested property is objectList.
The data path is BACnet4J application logic, local network stack, physical or virtual interface, configured VTS port, BACnet network context, simulated Device object, and property-service handler. A response follows the reverse path. Because the capture shows the outgoing ReadProperty, the caller has reached at least the capture point. Start by locating the last confirmed hop rather than changing the created analog objects.
| Observation | Last confirmed point | Next check |
|---|---|---|
| No request in the capture | BACnet4J application or local stack only | Check interface selection and destination configuration |
| Request appears, but not on the interface used by VTS | Host routing or adapter selection | Correct the bound interface or destination address |
| Request reaches the VTS-facing interface, with no reply | VTS port boundary | Compare the address, transport port, and VTS network number |
| VTS returns an error response | VTS device-service layer | Check the Device object and requested property |
Does the frame reach the VTS interface?
Layer one first. Confirm that the capture is taken on the interface carrying traffic to VTS. On systems with multiple physical adapters, loopback paths, VPNs, or virtual-machine adapters, a packet can be visible on one interface while VTS is bound to another.
- Start a capture on the interface configured for the VTS port.
- Issue one
ReadPropertyrequest from BACnet4J. - Match the request by source, destination, and requested Device object.
- Check whether any packet returns from the VTS address immediately after the request.
If the request is absent, the VTS object database is not yet relevant. Correct interface binding, host routing, or local packet filtering first. If the request arrives and no response leaves, move inward to the port configuration.
Do the address and transport port match?
For an IP-based BACnet path, the destination IP address and transport port in the capture must match the endpoint on which VTS is listening. A packet viewer can display traffic addressed to the host even when no VTS port owns that endpoint.
| Reading | Expected relationship | Meaning when it differs |
|---|---|---|
| Destination address | Matches the interface or endpoint assigned to the VTS port | The request reaches another adapter, host, or configured endpoint |
| Destination transport port | Matches the listening port configured in VTS | The operating system receives the packet, but the intended VTS port does not |
| Source address and port | Provide a usable return path to BACnet4J | VTS may reply through a path the caller is not monitoring |
| Response timing | A response follows the individual test request | No response after a clean single request points to port or device dispatch |
Do not infer application acceptance from the mere presence of a decoded BACnet packet. Packet capture occurs below the VTS simulated-device logic.
Does the VTS port have a network number?
The resolving configuration item is the BACnet network number assigned to the VTS port. VTS uses that number to associate received traffic with a logical BACnet network. Without it, VTS can expose the inbound request in a packet view yet fail to pass the request to the simulated Device object, producing the observed no-reply condition.
| VTS port setting | Observed behavior | Action |
|---|---|---|
| Network number blank or unassigned |
ReadProperty is visible, but VTS sends no reply |
Assign the port's BACnet network number |
| Network number assigned | The port can place the request in a BACnet network context | Reissue the request and inspect the response |
| Duplicate or topology-inconsistent number | Routing and network attribution can become ambiguous | Use the network number defined by the system's BACnet topology |
The network number does not create AO1, AI1, or the Device object's objectList. It supplies the missing port context that lets the request reach those objects.
Does the request target the intended Device object?
Once VTS replies, inspect the application-layer fields. The call reads objectList from the Device object identified by d.getObjectIdentifier(). Confirm that this identifier belongs to the same simulated VTS device under which AO1 and AI1 were created.
| Result | Interpretation | Next branch |
|---|---|---|
| No VTS response | The failure remains before property processing | Return to the VTS port network number, address, and transport port |
| VTS returns a protocol error | The transport path and port dispatch are working | Check the target Device object and property support |
VTS returns objectList without expected objects |
The property read works, but the selected device or object database differs | Verify where AO1 and AI1 were created |
| VTS returns the expected list | The complete request and response path works | Validate the BACnet4J result handling |
Do not change the object definitions to solve a silent port. Object-model faults normally become relevant only after the request reaches the simulated device and produces a response or error.
How do you apply and verify the fix?
- Open the VTS configuration for the port receiving the captured request.
- Assign that port the BACnet network number used by the intended logical network. In a routed installation, match the established topology and avoid assigning one number to different logical networks.
- Apply the port configuration.
- Confirm that the VTS listening address and transport port still match the request captured from BACnet4J.
- Issue one fresh call to
localDevice.sendReadPropertyAllowNull(d, d.getObjectIdentifier(), PropertyIdentifier.objectList). - Follow the packet in both directions: request into the configured VTS port, response out of VTS, and response back to BACnet4J.
- Inspect the returned
objectListand verify that it contains the objects configured under the target VTS Device object, including the expectedAO1andAI1entries.
FAQ
What happens if the VTS port has no network number?
VTS can display the incoming ReadProperty packet without replying because the port lacks the logical BACnet network context required to dispatch it to the simulated device.
What happens if Wireshark shows the request but VTS stays silent?
Transmission has reached the capture point, not necessarily the VTS application. Compare the captured destination address and transport port with the VTS port, then check that the port has a network number.
What happens if VTS replies with a protocol error?
The network path and VTS port dispatch are working. Check that d.getObjectIdentifier() identifies the intended Device object and that the request targets PropertyIdentifier.objectList.
What happens if objectList does not contain AO1 or AI1?
Verify that AO1 and AI1 were created under the same VTS Device object addressed by the BACnet4J request. A successful response from another simulated device can contain a different list.
How do I verify the BACnet4J and VTS fix?
Capture a fresh request and response, confirm that VTS replies through the configured port, and confirm the returned objectList contains the objects configured under the intended VTS device.