Announcing openHAB for Garmin

the-ninth · September 22, 2025, 6:03am

The issue comes from the JSON response generated by OH, which exceeds the limits imposed by Garmin. The JSON includes not only the item states but also metadata (for example, command descriptions), making it significantly larger than the sitemap definition itself. I suspect that OH5 introduced changes that add even more data to the JSON. This matches your observations: there is no single problematic element, the overall sitemap is simply too large. Reducing the sitemap size resolves the issue.

Do you still have access to your OH4 setup? Comparing the JSON outputs of OH4 and OH5 could help us better understand what changed, although it probably will not lead to a direct fix.

For now, the only practical solution is to remove a few elements from the sitemap. I plan to work on an implementation that fetches JSONs per page this autumn. However, this is a fairly complex change and will take some time.

moesfeld · September 24, 2025, 5:24pm

I’m loving this so far Any plans to add the Venu SQ to supported devices? As far as I can see the API level supported is the same on SQ2 and SQ.

EDIT: Sorry just found out that Venu SQ is 3.3 while SQ2 is 5.0

the-ninth · September 24, 2025, 5:52pm

Yes, and unfortunately it also doesn’t have enough memory to run the OH App. After the SQ and other watches of that generation, memory was increased significantly: the SQ has only 64 kB available for widgets, while the SQ2 already provides 768 kB.

If anyone is interested, here are two useful sources for details on specific Garmin models:

The Device Reference, which lists most technical specs such as screen resolution and memory.
The Compatible Devices, which shows the API level supported by each device.

stonke · September 28, 2025, 7:30pm

I sent you the JSON responses for the same sitemap via DM. The June file is a response from OH4.3.5, while the September file is a response from OH5.0. The latter is larger, but only slightly. If you have a moment, I hope you can identify which items caused the size increase and ultimately contributed to the “sitemap too large” error.

the-ninth · September 29, 2025, 7:29am

Good morning,

Thanks a lot for the JSONs!

A couple of things stood out:

The older JSON had quite a few syntax errors, especially empty arrays not written as []. But that only explains a small part of the size difference.
The newer JSON adds lastState, lastStateChange, and lastStateUpdate for every item, which also bumps things up a bit.
The LED structure looks more complex now. For example, LedG has four widgets in the newer JSON versus just two before. If you could send me your sitemap definition, I’d be able to dig into this a bit more and get a clearer picture.

the-ninth · November 28, 2025, 8:17am

Good morning,

I just released a minor upgrade v1.1.2, which

adds the motion icon
upgrades the app to Connect IQ SDK 8.3.0

Please let me know in case you run into any issues with the new version.

the-ninth · January 22, 2026, 8:52am

Hi all,

I’m currently working on a bug-fixing release and would really appreciate your support.

On the one hand, I already have a beta release that fixes several issues, and on the other hand I’m still analyzing a few remaining crash reports. These reports are collected by Garmin and provided to me in an anonymized form, without any user data.

First of all, the beta app is now at v1.1.3-beta7. If you have some time to test this version in your environment, that would be extremely helpful.

This release fixes the following issues:

Crash when using a Slider with minValue, maxValue, or step in some environments (#209)
Crash when a Slider item state exceeds the maxValue defined in the sitemap (#218)
Crash on Edge devices when using a generic switch or a toggle switch whose state is not yet known (#211)
Crashes in some widgets when a UI error occurred; instead, a toast warning with a UI: error code is now shown (#213)

In general, if you encounter a crash or any other issue, it would be very helpful if you could post as many details as possible here. I still have a few crash reports that I cannot fully analyze because I don’t know enough about the circumstances under which they occurred.

In particular, I’m looking for information about the following cases:

Crashes that occurred between Jan 1 and Jan 18 when pressing the Back button in a menu (e.g. a Frame or Group) on Venu X1, Forerunner 970, and Fenix 8
Crashes that occurred on Dec 27 when starting the app on a Fenix 8 Pro
Crashes that occurred on Jan 14 and 15 on an Edge 1040

Thanks a lot for your help and for testing the beta!

the-ninth · January 22, 2026, 8:10pm

v1.1.3-beta8 now fixes another issue:

If a structural sitemap change is applied while the app is running and one widget is replaced by another widget of the same type, the new widget correctly displays the status of its associated item, but any commands are still sent to the previously associated item, until the app is restarted. (#219)

By the way, I discovered this bug the hard way. I was experimenting with my sitemap and accidentally turned on the lights in my little daughter’s room just as she was falling asleep. She was wide awake immediately and still is now, more than one hour later.

the-ninth · January 23, 2026, 8:12am

v1.1.3-beta9 includes further fixes and small improvements:

For some of the still-unsolved crashes, additional validation has been added to verify data received from the API and to provide more detailed diagnostic information should they occur again. (#221)
Added a heating icon with support for ON/OFF states.(#220).
The setting to use the REST API for sending commands is now enabled by default for new configurations, as openHAB 5 has been available for some time and the REST API has been backported to openHAB 4. (#222).

the-ninth · January 24, 2026, 6:25pm

v1.1.3-beta9 has been published to the Beta app as release candidate v1.1.3-rc1. If no issues are identified, it will be released as the stable version v1.1.3 by Sunday, Feb 1.

the-ninth · January 27, 2026, 9:07pm

In the meantime, I am working on the Wi-Fi mode. Is anyone still following this thread who originally expressed interest in that feature? I would really appreciate some feedback on the design, and potentially also some help with beta testing.

The core principles behind the Wi-Fi mode are as follows:

Wi-Fi is only available in a dedicated sync mode that overlays the UI and requires user confirmation at the end of the sync. This behavior is dictated by the Garmin API.
As a result, continuously polling for sitemap updates in the background is not possible.
Consequently, the app cannot reliably display the current state of items, nor can it depend on that state when determining which commands to send. A simple example is a toggle switch, where the user must explicitly choose whether to send ON or OFF when on Wi-Fi.
Commands are sent via sync mode.
A sitemap request is only performed via Wi-Fi sync mode if no sitemap is available in storage, for example after certain error conditions or when the app is launched for the first time. Additionally, the settings menu will provide an option to trigger a sitemap request via Wi-Fi sync mode, such as to update the sitemap structure without a phone connection.

What do you think about this approach and its inherent limitations?

stonke · January 30, 2026, 12:36pm

@the-ninth

I changed on sitemap “==>” with ➔ (U+2794) that is symbol UTF-8 based I guess.

Sitemaps on mobile/PC/tablet works fine but Garmin App shows a square with a question mark in it.

Is it Garmin or your app limitation to show UTF arrow correctly ?

the-ninth · January 30, 2026, 8:08pm

This is a Garmin limitation. While UTF-8 is supported, the built-in fonts do not provide full Unicode coverage. Which characters actually render depends on the font and device, and there is no official documentation, so it’s largely trial and error.

the-ninth · January 31, 2026, 5:03am

Good morning,

Release v1.1.3 has now been published to the stable app. Since I already posted details about the bug fixes above, I will not repeat them here. You can find the full release notes here.

Functionally, this release is identical to the current v1.1.3-rc1 available on the beta app. Over the next few days, I plan to release the first version with Wi-Fi support on the beta app.

mvbergen · January 31, 2026, 12:30pm

Happy to test Wi-Fi on my Epix 2. The Garmin app is really useful to me and very reliable (I am using the myopenhab cloud service). I do not really miss the Wi-Fi mode, but there definitely is a use case when you go for a run with your watch only and would like to open a door or gate when you arrive at the house. The Wi-Fi limitations by Garmin are not ideal, so for me it would only be worth it if the overall functionality of the app is not affected.

the-ninth · February 1, 2026, 10:41am

Yes, that is the idea. As long as a phone connection is available, everything stays as it is. Only when there is no phone connection does the app check whether a Wi-Fi connection is available. If so, it switches to Wi-Fi mode, where states are not shown and commands are sent via Wi-Fi.

Everything works in the simulator now, and I have uploaded v1.2.0-beta1 to the beta app. I also tested it on my watch. Overall, it works well, but in some cases Garmin’s Wi-Fi sync behavior differs on the watch compared to the simulator. I will work through those issues and post an update once it is ready for broader testing.

the-ninth · February 3, 2026, 7:35am

Good morning,

The beta app is now at v1.2.0-beta6, and Wi-Fi mode is ready for public testing.

Overall, it works well on my watch. However, I occasionally see a “Sync Failed” message when sending a command. I have not been able to pinpoint the exact situation in which this happens, and despite extensive testing, it has never occurred in the simulator.

I would be very interested to hear whether you are seeing this issue on your device, especially when sending multiple commands in quick succession.

I am tracking the issue here:
https://github.com/openhab/openhab-garmin/issues/227

Below is the new Wi-Fi section from the updated user documentation, which has not yet been published:

Network Access

All Garmin wearables can access your local network and the Internet via a BLE (Bluetooth Low Energy) connection to your phone.

BLE / Phone Connectivity

Using your phone for connectivity allows the app to take advantage of all network options available on the phone, including VPNs such as Tailscale. When connected via the phone, the openHAB app maintains a permanent connection to openHAB and is therefore able to display live item states.

Platform-specific limitations:

iOS: HTTP and HTTPS are supported
Android: Only HTTPS with a valid certificate is supported due to Garmin SDK limitations

You can use myopenHAB to securely access your local openHAB instance over the Internet via HTTPS.

Wi-Fi

Some Garmin wearables can also connect directly to Wi-Fi. This allows access to the local LAN and, if Internet connectivity is available, to services such as myopenHAB.

When connected via Wi-Fi, both HTTP and HTTPS are supported.

Garmin does not allow a permanent Wi-Fi connection. Instead, the app must enter a dedicated sync mode, perform its network operations, and then close the Wi-Fi connection again. While this sync is active, Garmin displays system-provided views to inform the user about sync progress.

Automatic Wi-Fi Detection and Mode Switching

If no BLE connection to a phone is available, the app automatically checks whether a Wi-Fi connection can be used and, if so, switches to Wi-Fi mode. These checks continue while the app is running, and the app may switch between BLE and Wi-Fi connectivity at any time.

As described above, when running in Wi-Fi mode no live item states are displayed. The current connectivity mode can be checked in the settings menu.

No Polling of Sitemap Changes and States

Due to these limitations, the app does not regularly poll openHAB for sitemap changes or state updates while in Wi-Fi mode. As a result, item states are not displayed.

Only if no data is available at startup, for example after settings changes or a fatal error, the app enters sync mode to retrieve the full sitemap. The settings menu shows when the sitemap was last retrieved, and the user can also manually trigger an update via Wi-Fi, for example to download structural changes to the sitemap.

Sending Commands

Because current item states are not available in Wi-Fi mode, sending commands cannot rely on existing state information. For toggle switches, this means the user must explicitly choose whether the item should be switched on or off via an action menu.

Another example is the Slider. In Wi-Fi mode, the slider always starts at the middle of its range and operates in releaseOnly mode. The command is sent only when the new value is confirmed, not while the value is being adjusted.

the-ninth · February 5, 2026, 9:50am

Just uploaded v1.2.0-beta7. This release replaces the Wi Fi check and loading text messages with icons and adds a Wi Fi mode indicator to menus and full-screen widgets.

Another issue remains: the Player variant of the Switch widget does not yet work without a state. If no state is available, it shows Pause, and in the full-screen widget only the Play command can be sent.

the-ninth · February 5, 2026, 3:53pm

Apologies, v1.2.0-beta7 fails with a -300 error everywhere except in my own home. When sideloading builds directly onto my phone, I need to hardcode the URL in the source code. Unfortunately, I forgot to remove this before uploading v1.2.0-beta7.

The issue is now fixed in v1.2.0-beta8, which you can download right away.

Regards,
Robert

the-ninth · February 5, 2026, 5:44pm

I’d like to ask if anyone else is seeing the following issue.

After toggling a Switch, the app UI often changes to the new state, then briefly jumps back to the previous state, and finally switches again to the new state.

What appears to be happening is that, even though the command request succeeds, the first sitemap refresh executed after the HTTP response still returns the old Item state. Only the next refresh reflects the updated state.

This behavior used to occur only occasionally, but in my environment it now happens most of the time. I upgraded to openHAB 5.1.1 two days ago, and I am not sure whether this change is related.

Is anyone else experiencing delayed state updates like this after sending a command?