Only devices with an active cook is returned by the API

[jlaur]

When my Block is turned on and connected to Wi-Fi, I see all four probes in the Android app. But GET https://public-api.cloud.meater.com/v1/devices returns:

{
    "status": "OK",
    "statusCode": 200,
    "data": {
        "devices": []
    },
    "meta": {}
}

MEATER Block software: 3.0.2.9

When starting a cook, the probe will start appearing in the list. However, I'm sure this behavior was changed recently, as it would not have been possible to initially discover all my four probes otherwise. This new behavior hides data and makes discovery painful.

Would it be possible to get back to the old behavior and be able to receive data when available, i.e. same as in the app?

Additionally, why does the app use a different API than this public API, which seems more limited?

[digitaldan]

FYI i have been lazy and keep delaying upgrading my firmware (its always prompting when i'm about to cook something), so my 4 meater block is still on 2.0.4.25 and the public API is thankfully still working. Wondering if something has changed with the 3.x firmware that is incompatible with the public API?

Having a public API is awesome btw, so thank you for continuing to support it apption-labs !

[digitaldan]

And just to comment to the updated issue title and description, on my 2.0.4.24 firmware devices show up when the block powers on, not just when the probes are cooking, sounds like this has changed with recent firmware?

[rafalkrol-xyz]

Hi, @jlaur, and @digitaldan! Thank you for your messages!

The public API's functionality for the /devices endpoint hasn't changed. However, as noted by @digitaldan, for MEATER Blocks on the previous (v2) firmware, that endpoint returns your devices after start-up - not any more for MEATER Blocks on the latest (v3) firmware. Next week, I'll look into why it's so, and if it's an easy addition, we shall implement it - no promises, though.

As for why the public API differs from the one the mobile clients use, this is due to a decision made years ago. Keeping the two separate is a double-edged sword. On the one hand, we can separately manage the two having different resources and security measures for each. On the other, it's extra overhead and, to a certain extent, duplication of work.

[digitaldan]

Thanks @rafalkrol-xyz !

[jannegpriv]

Any updates on this?