Jump to content
The simFlight Network Forums

Best way to make browser interface with FSUIPC?

Recommended Posts

What is the best way to make a browser web page interface with FSUIPC? So that we can easily design our own panels with buttons and information from the aircraft/simulator using HTML/CSS/Javascript? How could that be done?

It seems like it should utilize websockets since that provides two-way instant communication and the WebSocket API is supported by any modern browser. But FSUIPC doesn't have a websocket server in-built I presume... Plain requests via the HTTP protocol could be an alternative but would only be optimal for button presses...

I'm aware of WideFS button capabilities - it would be some similar to that but just done in the browser instead so that it will have many more options for layout and information. Seems with today's browsers it should be doable performance-wise and therefore an obvious feature to have.

Share this post

Link to post
Share on other sites
1 hour ago, Firefly said:

What is the best way to make a browser web page interface with FSUIPC?

There is no web browser interface to FSUIPC as far as I'm aware. Please check the SDK for the available interfaces.

I guess, for example, you could write a java plug-in that runs in the browser and communicates to FSUIPC via one of the Java SDKs. Or one of the other SDKs (e.g. python) if that is supported by the browser.

There are no plans to add a HTTP or websockets interface directly to FSUIPC. 

Share this post

Link to post
Share on other sites

Actually, I'll put this on my list to investigate at some point. i.e add a http (or maybe websockets) interface to FSUIPC. However, I don't expect to have time to look into this for quite some time. Any such interface would only expose reading and writing to the offset data area, as is supported by the current SDK.


Share this post

Link to post
Share on other sites

I've been thinking about this a bit and it should actually be pretty simple to implement, so I'll add it to my 'to be implemented' list. However, with FSUIPC7 for MSFS being the priority at the moment, it will take some time before I can get around to looking at this in detail. I will implement as a plug-in dll, so I can add extra features not available in the SDK, such as a direct 'control/event' interface, not via offsets.

Also, it should be reasonably straightforward to implement as a separate process,  using one of the provided SDKs. All that is needed is to add an embedded http/websockets server, and then exposed the FSUIPC SDK functions as endpoints. The most developed/used SDK at the moment seems to be Paul Henty's .net client. Maybe @Paul Henty has already considered this?


Share this post

Link to post
Share on other sites

Hi John,

Yes I've thought about it as I've seen some other requests for this in past but I didn't have the time for new project.

As you say, a small application that runs in the system tray that provides an http interface should be fairly straight forward. As well as the basic offset read/write I could also expose the helper classes in the DLL like accessing weather and AI traffic.

I guess the main advantage of a separate program is that it'll work with all version of FSUIPC/Flight Sims.

I'll investigate his week as I don't think it'll be too big a project and I'll report back.


Share this post

Link to post
Share on other sites

Guys, that's great to hear! I really think this could be very useful and open up for a lot of possibilities - as there are a lot of people who know how to work with the web technologies but don't how to use lower level languages, do compiling and all that stuff. But simple web APIs is what is tying systems together nowadays.

Looking forward to see what you can come up with!

Share this post

Link to post
Share on other sites

I have a proof of concept working.

It uses HTTP requests. I can't see any advantage in using WebSockets as FSUIPC itself does not have duplex communication. It's only one-way poll & response from client to FSUIPC.

Just to make sure I'm on the right track, and check if this this would be useful, I've posted some javascript below that I've used for testing. This runs directly in a browser, completely client-side.

It talks to the HTTP server program that is located on the flight sim PC (or can be on a different PC if connecting to the flight sim over WideFS).

The URL consists of the IP of the server and port number (setup in the server program) followed by /fsuipc/ and then the type of request you are making. e.g. to request offset data it might look like this:



You'll make an AJAX POST request to this URL, passing a JSON stringified array of offset requests (details in the code below). Then you'll get back another JSON string containing the values which you can turn into a Javascript object to use.

Here's the Javascript for reading three offsets:

var fsuipcURL = "http://localhost:2048/fsuipc/";

function btnReadOffsetsClick(e) {
    // make a request to the sever to read offset data
    // First setup a data structure containing the offset requests

    // This is an array of offset objects. Each object contains:
    // name: used to identify the value when the response comes back (can be anything)
    // address: Hexadecimal address of the offset
    // type: the type of data in the offset. Must be:
    //       'int'   (signed integer)
    //       'uint'  (unsigned integer)
    //       'string'
    //       'float'
    // size: The size of the offset in bytes 

    offsets = [
        { name: 'avionicsMaster', address: '2E80', type: 'uint', size: 4},
        { name: 'heading', address: '0580', type: 'uint', size: 4},
        { name: 'aircraftName', address: '3D00', type: 'string', size: 256 },

    // create the URL
    var offsetsURL = fsuipcURL + "offsets";
    // create a new AJAX request object
    var xhttp = new XMLHttpRequest();

    // setup a function to execute when the data is returned
    xhttp.onreadystatechange = function () {
    // make the request
    xhttp.open("POST", offsetsURL, true);

function showOffsetData(e) {
    // clear error display
    document.getElementById('fsuipcReadOffsets').innerHTML = '';
    var displayHTML = "";
    if (e.readyState >= 3 && e.status == 200) {
        // decode the JSON response 
        var response = JSON.parse(e.responseText);
        if (response.Success) {
            var data = response.Data;
            // display each offset value on the page
            document.getElementById('aircraftName').innerText = data['aircraftName'];
            document.getElementById('avionicsMaster').innerText = data['avionicsMaster'] > 0 ? 'ON' : 'OFF';
            // convert heading from FS units to degrees
            var headingDegrees = data['heading'] * 360 / (65536 * 65536);
            document.getElementById('headingTrue').innerText = headingDegrees.toFixed(2);
        else {
            displayHTML = "Request failed with error code: " + response.ErrorCode + " " + response.ErrorMessage;
    else {
        displayHTML = "Error communicating with FSUIPC Web Services. ";
    // set any error HTML into the div
    document.getElementById('fsuipcReadOffsets').innerHTML = displayHTML;

This is the result:


Do you think this would work?



Share this post

Link to post
Share on other sites

Hi Paul,

You're fast! This is great - it's exactly what I had in mind for HTTP communication. It can certainly work in a lot of scenarios - I'm just thinking that in case you for example wanted to do a gauge you would want very frequent updates, at least every 50-100 ms, and in that case there would be quite a bit of overhead in constantly opening/closing the HTTP connection and passing headers. At least theoretically that would be a concern... so that's why I was thinking of websockets. I was imagining that you could subscribe to a set of offsets which would then continually be sent back to the client at a given interval (maybe even user desired interval?). Either all the subscribed offsets could be returned, or even better, only those that have changed since last time.

I understand that FSUIPC in itself is stateless - poll and response - so this would of course require a running websocket server with some logic in it. But due to the overhead of HTTP I believe it would perform substantially better to have that websocket server continually poll FSUIPC internally than doing the polling over the HTTP protocol? Or is there something I'm missing?



Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Create New...

Important Information

By using this site, you agree to our Terms of Use. Guidelines Privacy Policy We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.