GET_METAR_BY_IDENT / GET_METAR_BY_LATLON - invalid METAR

Version: 1.6.34.0

Frequency: Consistently

Severity: Blocker

Bug description:

We are attempting to retrieve METAR data from an HTML/JS instrument (EFB) using the documented Coherent calls:

GET_METAR_BY_IDENT
GET_METAR_BY_LATLON

However, both APIs consistently return "Invalid METAR" even when:

  • Live Weather is enabled

  • Online services are enabled

  • The aircraft is located at a major airport

  • A facility listener is registered

SimVars return correct weather data, but the METAR APIs always fail. We would like clarification on the correct initialisation or usage pattern for these APIs.

Here are the essentials of our implementation:

Facility listener

let facilityReady = false;

RegisterViewListener("JS_LISTENER_FACILITY", () => {
    facilityReady = true;
    console.log("[EFB] Facility listener ready");
});

METAR retrieval

async function efbGetMetar(icao, airportLat, airportLon) {

    // 1 — try ident
    try {
        const metar = await Coherent.call("GET_METAR_BY_IDENT", icao);
        if (metar && metar !== "Invalid METAR") {
            return metar;
        }
    } catch(e) {}

    // 2 — try airport coordinates
    try {
        const metar = await Coherent.call("GET_METAR_BY_LATLON", airportLat, airportLon);
        if (metar && metar !== "Invalid METAR") {
            return metar;
        }
    } catch(e) {}

    // 3 — try swapped coordinates
    try {
        const metar = await Coherent.call("GET_METAR_BY_LATLON", airportLon, airportLat);
        if (metar && metar !== "Invalid METAR") {
            return metar;
        }
    } catch(e) {}

    // 4 — try aircraft position
    const lat = SimVar.GetSimVarValue("PLANE LATITUDE", "degrees");
    const lon = SimVar.GetSimVarValue("PLANE LONGITUDE", "degrees");

    try {
        const metar = await Coherent.call("GET_METAR_BY_LATLON", lat, lon);
        if (metar && metar !== "Invalid METAR") {
            return metar;
        }
    } catch(e) {}

    // 5 — swapped aircraft coordinates
    try {
        const metar = await Coherent.call("GET_METAR_BY_LATLON", lon, lat);
        if (metar && metar !== "Invalid METAR") {
            return metar;
        }
    } catch(e) {}

    return null;
}

Example test

EGSS
lat = 51.885
lon = 0.235

Console output:

[EFB] Facility listener ready

[PERF][WX] takeoff metar_unavailable lastSource=LATLON_PLANE_SWAP err=Invalid METAR
[PERF][WX] takeoff source=SIMVARS_FALLBACK icao=EGSS wind=20/9 oat=11C qnh=1019hPa

Both calls consistently return: Invalid METAR

Are there additional initialization steps required before calling GET_METAR_BY_IDENT or GET_METAR_BY_LATLON?

  1. Is the facility listener alone sufficient to enable the METAR APIs?
  2. Are there timing constraints or weather subsystem readiness checks required before these APIs return valid results?
  3. Are these APIs still supported for HTML/JS instruments in MSFS 2024?

Thanks in advance for any assistance,

Martyn

Hello Martyn (@MartynJF),

I made a quick test of the GET_METAR_BY_IDENT call on Coherent through my EFB, and it works for me as expected, returning the object that should be returned. Tested on MSFS2024 version 1.6.34.0 (SU4 stable) as you state on the bug report post. I am also using the JS_LISTENER_FACILITY and it was sufficient to make that call.


I also tested with GET_METAR_BY_LATLON. Successful result as expected for me as well.


I tested with the following calls made, provided the Facility Listener is registered after initializing the instrument:

Coherent.call("GET_METAR_BY_IDENT", "LEAS").then(result => console.debug(result)).catch(err => console.debug(err));
Coherent.call("GET_METAR_BY_IDENT", "LEMD").then(result => console.debug(result)).catch(err => console.debug(err));
Coherent.call("GET_METAR_BY_LATLON", 43.469989306817915, -1.5328875514646036).then(result => console.debug(result)).catch(err => console.debug(err));

Is it under SU4 that is happening, or is it maybe under the SU5 beta (in which case, it should be version 1.7.9.0)? I cannot tell for SU5 because I am not enrolled on the SU5 beta, as I am closer to release a new 2024-native product. Anyway, it is very weird that it is not working for you guys :thinking:

Regards,
Carlos Daniel González Gómez
NextGen Simulations

1 Like

Hi Carlos,

Thanks for taking the time to test this and for confirming the expected behaviour.

Your screenshots helped us identify the issue. Our implementation was originally written against the older behaviour where GET_METAR_BY_IDENT returned a string, so we were checking the return value against "Invalid METAR" and then parsing the string directly.

In MSFS 2024 the call returns a Metar object, with the raw METAR available in the metarString field and decoded values such as windDir, windSpeed, temp, and altimeterQ. Because of our original string check, the returned object was being rejected and our code was falling back to simvars.

Updating our logic to treat the response as an object and check metar.metarString resolved the issue, and we are now successfully importing weather via GET_METAR_BY_IDENT.

Thanks again for the clarification and example calls — they were very helpful.

Martyn

3 Likes