• State Not Answered
  • Replies 30 replies
  • Subscribers 24 subscribers
  • Views 11674 views
  • Users 0 members are here
Options
Related

HTTP request over device Wi-Fi specification

3049222

I was reading in the documentation, regarding the http Communications moudule, that:

"Monkey C exposes a high level APIs to allow calls to basic web services through Garmin Connect Mobile"

Soruce: https://developer.garmin.com/connect-iq/core-topics/https/

  1. Does that mean that i can only make http request trough the Garmin Connect app ?

  2. By trying to make a http request with the Communications modules on a simulated device i've notice that i'm able to make a succesfull request even when i'm not connected to a phone device. Does that mean that i can also make a htt request over the Garmin device Wi-fi without passing trough the Garmin Connect app ?

  3. Is there any way to check programmatically if the Garmin devies have a built in network support ?
  • 0 in reply to the-ninth

    That's it.

    Communications.startSync();

    As I remember, there is an exemple in the toolkit.

  • 0 in reply to RodolpheDumesnil
    RodolpheDumesnil said:

    That's it.

    Communications.startSync();

    Thanks! How do you detect when no BLE connection is available? I couldn’t find a direct method like Communications.checkWifiConnection() for Wi-Fi. Is the only option to use Communications.makeWebRequest() and check for specific error codes?

    Also, another question: the HTTPS requirements differ between iOS and Android. Do you know how it works with Wi-Fi connections? Is plain HTTP allowed, or is HTTPS with a valid certificate always required?

  • 0 in reply to the-ninth

    See:

    - DeviceSettings.phoneConnected (BLE only)

    - DeviceSettings.connectionAvailable and DeviceSettings.connectionInfo (BLE, WiFi, LTE)

    Note that in this context, "BLE connected" / "phone connected" really means "BLE is connected and Garmin device is connected to the Connect phone app". (iow if your device is connected to the phone but Connect is closed, these fields will indicate that BLE is not connected)

    This differs from the controls menu which is able to distinguish between the following 4 BLE states:

    - BLE disabled

    - BLE enabled, but no BLE connection

    - BLE connected, but Connect closed

    - BLE connected, and Connect open

  • 0 in reply to flowstate

    Thanks!

    So, phoneConnected tells me whether making a web request via BLE is possible.

    How does connectionAvailable relate to this? If it's true, does that mean I can make a web request immediately? Or could it also be true if, for example, a Wi-Fi connection is available, but I still need to put the app into sync mode before I can use it?

  • 0 in reply to the-ninth

    It can depend on the device.  For example, on at least some edge devices, it tries to establish wifi as soon as you turn it on. as it does with a phone connection, but will drop wifi as soon as you start recording. When wifi is connected, that can be used by CIQ with no additional code/logic

    What I've done for years is just do the makeWebRequest with no checks but then I pay attention to the responseCode for the call.  The phone could be connected, but it doesn't have a data connection, or there could be a data connection but the server isn't available.  All different errors, but the result is basically the same and need to be handled.

    Depending on what you are doing, forcing wifi night not be the best option.  There's time involved for scanning for wifi and connecting to a wifi network, where that can take longer than just using BLE.  Wifi is generally there for big things, like FW updates and music downloads   And it also requires more battery

    Requiring wifi means you can't support watches without music

  • 0 in reply to jim_m_58
    jim_m_58 said:
    Depending on what you are doing, forcing wifi night not be the best option.  There's time involved for scanning for wifi and connecting to a wifi network, where that can take longer than just using BLE.  Wifi is generally there for big things, like FW updates and music downloads   And it also requires more battery

    In my app, Wi-Fi would be an additional feature layered on top of the phone-based connection. The goal is to use the phone connection if it’s available, and fall back to Wi-Fi if it’s not.

    I’m already aware that using Wi-Fi requires setting up a sync delegate and related components, but for now, I’m focused on how to best decide when to trigger the fallback.

    My initial idea—same as the approach Jim described—was to make the makeWebRequest using the phone connection and, based on certain response codes, attempt to fall back to Wi-Fi. That still seems like a reasonable approach, but I wanted to check if there’s a cleaner or more reliable way to detect the need for fallback before going further down that path.

  • 0 in reply to the-ninth

    I’ve started working on the WiFi implementation of my app again.

    The app should behave differently depending on whether a WiFi connection is available. Ideally, I’d also like to know during startup (in AppBase.getInitialView()) whether WiFi is actually available.

    From the documentation, Communications.checkWifiConnection() seems like the right API to determine WiFi availability. However, it appears to be asynchronous, with the result delivered via a callback.

    So with that function I can’t determine WiFi availability inside getInitialView()? Or is there another approach I could use?

    Related question: Communications.makeWebRequest() also uses a callback, but under some error conditions the callback is invoked synchronously from within makeWebRequest(). Has anyone observed similar behavior with checkWifiConnection() for any of its error codes?

    Finally, how expensive is checkWifiConnection() on real devices? Is it lightweight enough to call every few seconds without affecting user experience, or could it block / slow down the app in a noticeable way?

  • 0 in reply to the-ninth

    Understand that you will rarely have a wifi connection.  It draws a bunch of battery, and for most things you can use the phone connection (BTE)

    See the bulk download sample in the SDK

  • 0 in reply to the-ninth

    What's your design? Why do you want to know if there's wifi or not? What will be different in what the user sees or can do?

  • 0 in reply to flocsy🤠
    flocsy🤠 said:
    What's your design? Why do you want to know if there's wifi or not? What will be different in what the user sees or can do?

    The app is a home automation client for the open-source openHAB server. It presents a hierarchical structure of devices (CustomMenu), showing their current state and allowing state changes either through device-specific menu items or dedicated full-screen views.

    There are two types of interaction with the server:

    1. Regular polling to retrieve device states

    2. Sending commands to change those states

    Due to the nature of the Wi-Fi connection, regular polling is not possible. However, sending commands often depends on knowing the current state. A simple example is a toggle switch: if the switch is ON, selecting it sends OFF, and vice versa.

    My approach is the following: if polling fails with error codes that indicate the absence of a phone connection (e.g. BLE_CONNECTION_UNAVAILABLE, BLE_HOST_TIMEOUT), the app enters a degraded mode. In this mode, device states are not displayed, and commands are sent without relying on the current state. For the toggle switch example, this means the user must explicitly choose between ON and OFF instead of the app automatically toggling based on an assumed state.

    I perform the initial poll when the app starts, in getInitialView(). Coincidentally, the error codes indicating the absence of a phone connection are passed on to the callback synchronously by makeWebRequest(). So, ideally, I'd already know at startup whether a Wi-Fi connection is available and either display an error or immediately enter the stateless Wi-Fi mode.

    State polling would then continue in the background. If the phone connection is restored, the app can transition back into normal operation. On the other hand, if at any point neither a phone nor a Wi-Fi connection is available, the app would display an error message.

    There are, of course, ways to work around this. I could display a waiting screen until it is clear whether a Wi-Fi connection is available. With some additional effort, the glance could even probe the Wi-Fi connection in advance and persist the result, allowing the app to start up faster.

    If you’re interested in more details about the app, the user documentation is available here:

    www.openhab.org/.../