How can I access X-Plane DataRefs from another computer?

To access X-Plane DataRefs from another computer, send UDP RREF requests from the remote machine to the X-Plane computer’s LAN IP address and UDP listening port, normally 49000, then decode the RREF replies. Use DREF only for writable DataRefs. For arrays, strings, commands or authenticated links, use a custom X-Plane plugin instead.

Which X-Plane network method should you use?

Use RREF when you need to read named DataRefs and DREF when you need to change a writable DataRef.

Do not enable Data Output checkboxes merely to use RREF. Those checkboxes control X-Plane-initiated DATA packets; RREF is a separate request-and-reply mechanism. Our guide to X-Plane UDP packet types and LAN configuration explains the broader differences between DATA, RREF and DREF.

How do I read DataRefs from another computer?

A remote application reads X-Plane DataRefs by opening a UDP socket, sending correctly formatted RREF subscriptions and receiving replies on that same socket.

1. Confirm the DataRef name. Find its exact path, type and access permissions using our explanation of where to find searchable DataRef names and definitions. Aircraft and plugin DataRefs may exist only after their provider has loaded.
2. Verify the value inside X-Plane. Before blaming the network, inspect the live value with DataRefTool. This catches spelling mistakes, obsolete names and DataRefs that are inactive in the selected aircraft.
3. Find the X-Plane computer’s LAN address. Use its private IPv4 address, such as an address in the 192.168.x.x or 10.x.x.x ranges. From another computer, 127.0.0.1 points back to that other computer, not to X-Plane.
4. Check X-Plane’s receiving port. The normal UDP port is 49000, but confirm the network setting because it can be changed. The client may bind to any suitable local UDP port and should keep that socket open for the replies.
5. Send an RREF subscription. The packet contains the five-byte RREF header including its null terminator, a 32-bit requested frequency, a 32-bit client-defined index and a null-padded 400-byte DataRef name. In Python-style packing, the layout is struct.pack('<4sxii400s', b'RREF', frequency, index, dataref_bytes).
6. Decode the response. An RREF reply begins with the same five-byte header, followed by one or more eight-byte pairs containing a 32-bit index and a 32-bit floating-point value. The index identifies which subscription produced each value; it is not part of the DataRef itself.
7. Cancel unused subscriptions. Send the same RREF request with a frequency of zero when the value is no longer required. This prevents unnecessary packets and processing.

Give every active subscription a unique index. X-Plane can place several index-value pairs in one datagram, so the receiving code must process the complete packet rather than reading only its first value.

How do I write a DataRef over the network?

Send a DREF packet only when the DataRef is documented as writable and a direct value assignment is the correct control method.

A DREF packet contains the five-byte DREF header, one 32-bit floating-point value and a null-padded 500-byte DataRef name. The equivalent Python packing layout is struct.pack('<4sxf500s', b'DREF', value, dataref_bytes).

Treat DREF as a write request, not as confirmation that the value remained set. Subscribe to the same DataRef with RREF if the external application must verify the result. X-Plane’s flight model, autopilot or aircraft plugin may legitimately replace your value on the next update.

Many cockpit actions are commands, not writable DataRefs. Use X-Plane’s command mechanism or a plugin rather than repeatedly forcing a related state value; our overview of DataRefs, commands and custom plugin integration explains that distinction.

Why am I not receiving RREF replies?

Most RREF failures come from an incorrect address, blocked UDP traffic or a malformed packet rather than from X-Plane itself.

• Wrong destination: Send requests to the X-Plane computer’s LAN address and receiving port, not to the Data Output destination configured for unrelated DATA packets.
• Firewall blocking UDP: Allow X-Plane or its configured UDP port through the operating system’s private-network firewall. Also permit the client application to receive replies.
• Wireless client isolation: Some routers prevent Wi-Fi devices from communicating with each other. Test basic communication between the two computers or use the same trusted wired network.
• Incorrect packet layout: The null byte after RREF, field order, byte order and fixed-length name field all matter. A plain text string containing a DataRef path is not a valid RREF request.
• Receiving on the wrong socket: RREF replies return to the requesting UDP endpoint. Listen on the same socket used to send the subscription.
• Unavailable DataRef: A custom aircraft or plugin DataRef will not exist until that aircraft or plugin has loaded. Check the name during the same X-Plane session.
• Zero or excessive frequency: Zero removes the subscription. Request only the update rate the remote display or hardware genuinely needs.

When is a custom X-Plane plugin better?

Choose a custom plugin when the built-in float-based RREF and DREF messages cannot represent the data or behaviour your external application needs.

This includes arrays, strings, atomic groups of values, validated writes, reliable acknowledgements and application-specific commands. A plugin can read X-Plane through the SDK and expose a deliberately designed network protocol instead of trying to make every simulator state fit a single float.

X-Plane’s UDP interface is connectionless, unencrypted and unauthenticated. It is suitable for a trusted local network, but it should not be exposed directly to the internet through router port forwarding. Build timeouts and stale-data handling into the client because UDP packets may be lost, duplicated or arrive out of order.