Hi Marcel, thanks for the feedback—I really appreciate it! Just to confirm: are you connecting directly to your local openHAB instance, without using myopenhab.org?
Yeah, unfortunately the whole Connect IQ environment isn’t exactly known for its stability. For example, on my watch with my CIQ apps, updates do work, but the “Updating” message sometimes stays on screen forever - even though the update has already completed. This behavior started a few days ago and now affects all CIQ apps I have installed.
The SDK itself also has its share of bugs, though in most cases there are workarounds.
That said, in my experience, these issues don’t usually affect the user experience on the watch. Once the app reaches maturity, I’m confident it’ll work reliably for everyone.
I just uploaded version 0.0.6.3, which includes improved and more consistent error handling.
Non-fatal errors show a toast notification.
Fatal errors display a full-screen error message.
An error is considered fatal when continuing to display the sitemap no longer makes sense.
For example:
Errors that occur when sending a command are always non-fatal, since the sitemap remains valid.
Temporary communication issues while polling the sitemap are also non-fatal - unless they persist for more than 10 seconds. At that point, they are treated as fatal.
Even after a fatal error, the app continues polling the server and will return to displaying the sitemap if a valid response is successfully processed.
The documentation has been updated with a section on error handling and common issues: Troubleshooting
What still can be improved:
For common error codes, the app displays a descriptive label like “NO PHONE”. Over time, I’ll add more of these for frequently encountered codes. @Mark_VG - I’ve now mapped error code -2 to show “NO PHONE”, for example.
Regarding the myopenHAB issue, the app now displays EMRES (empty response).
If this behavior continues, I may suppress this error unless it becomes fatal. From what I’ve seen, usually only one response is affected and the next one works fine - so the app could just skip such erroneous responses without disrupting the experience.
About the recent updates:
You may have noticed several quick releases, for example 0.0.6, 0.0.6.1, 0.0.6.2, and now 0.0.6.3.
This is because I also need the CIQ Store to install and test updates on my watch.
Once development stabilizes, I plan to split the app into two versions on the CIQ Store:
A stable version
A beta version for testing new features and getting early feedback
It currently displays the app version and server URL. Additional features may be added in the future when the app evolves.
Getting this working was trickier than expected - it took several iterations (from 0.0.7 to 0.0.7.8) to track down and work around a Garmin SDK bug that only appears on the real watch, not in the simulator.
To access the settings menu, scroll down on the home screen and continue past the settings icon.
Just uploaded v0.0.7.9 with a small fix for the settings menu. Previously, exiting the settings via the back button and then re-entering it caused the app to crash - this issue has now been resolved.
You can navigate to and from the settings menu using the up/down keys or the corresponding touch gestures. The back button also returns you to the main menu.
Great! I’ll see if I can include support in the next release: Support Fenix 6 Pro
In the meantime, I’ve just uploaded version v0.0.8.2, which includes two fixes:
Fixed a bug that prevented errors from being shown if they occurred during the very first sitemap request. Details
The app now correctly handles a trailing / in the server URL when constructing the REST API URL. Details
I’ve also submitted a new BETA app to the Garmin CIQ store. Once it’s approved (in about 2–3 days), I’ll be able to use it for my own testing - which means I won’t have to bother you all with frequent releases that haven’t even been tested on a physical watch.
v0.0.9 Released - Now with Support for Fenix 6 Pro, Venu 2 & Venu 2 Plus
I’ve just uploaded version v0.0.9, which adds support for the Fenix 6 Pro series, Venu 2, and Venu 2 Plus.
To support the Fenix 6 Pro, the glance now handles memory constraints more gracefully. If there’s not enough memory to process the full JSON response, it will still show a previously stored sitemap label. Normally, the glance caches the full JSON so the widget can start with fresh data, but if that fails, it will fall back to the last cached data and update once new data becomes available.
One limitation: these devices only support API level 5.0.0, not the newer 5.1.0. On touchscreen devices, this affects how the settings menu behaves:
You must tap the settings icon (scrolling over it won’t work).
To exit the settings screen, swipe right or press the back key.
I’ll explore ways to improve this behavior further.
(See issue: #55 on GitHub)
In the simulator, all Venu devices currently open the settings screen at the last entry instead of the top. If you have a physical Venu device, please let me know if you see the same behavior. See issue: #56 on GitHub)
Thank you, its working
About issue 56 you mentioned: on my watch while go into setting and then out it looks like focus is on middle frame(recreated map with 3 frames like yours). Focus means that is exactly in the middle of screen, not sure if it is what you looked for.
Anyway not a big issue at all, its great to have OH inside Garmin device
In the next version, the settings menu will be implemented differently for touch devices.
Note: By touch devices, I’m referring to models primarily designed for touch input (like the Venu and Vivoactive series), in contrast to button-based devices such as the Fenix or Forerunner series. While the latter may have touchscreens, their interaction model is still centered around button use.
On touch devices, the settings will appear as a standard menu entry, rather than as a parallel menu positioned below the footer. This approach aligns better with the user interface conventions of touch-centric devices.
@stonke, my expectation for the menus is that when navigating into a submenu and then returning, the parent menu should restore its previous scroll position. In the simulator, this doesn’t seem to work correctly - on return, the focus shifts lower than where it was left. Do you observe the same behavior on your actual device?
I’ll need to look into it further, but at first glance, it should be possible. The Edge Explore 2, along with the Edge x40 and x50 series, appears to have sufficient hardware resources and a recent enough API level. Support for the older x30 series might also be feasible.
Personally, I use an Edge 830 and currently use APICall to open our entrance gates - but of course, it would be much cooler to do via the openHAB app.
@stonke, one more question: the height of each menu item is relatively small. I think that works well on button-operated devices, but do you think it would make sense to increase the height for touch devices? Or does the current layout work well as-is?
Very strange with my sons watch.
Thecapp only works if the garmin app is actually running on his phone.
Any time the Garmin Connect is not running the No Phone error is displayed.
Confirmed by testing thevapp a few times with Garmin Connect open and closed and consistent that if Garmin Connect not running app shows No Phone.
In general, the Garmin Connect app needs to remain active in the background for watch apps to access the Internet. Usually, after a phone restart, you need to open the Connect app at least once - after that, it should stay running in the background automatically.
Are you using Android? There are several potential reasons why the app might not stay active in the background.
Here’s what the almighty AI has to say about it (I don’t have an Android device myself, so I can’t test it):
Several factors can prevent the Garmin Connect app from running reliably in the background on Android. Here are the most common culprits:
Battery Optimization / Power Saving Settings
Android aggressively limits background activity to save battery. Garmin Connect can get shut down or restricted unless excluded from battery optimization.
Fix:
Go to Settings > Apps > Garmin Connect > Battery > Battery Optimization
→ Set to “Don’t optimize” (or similar wording depending on the manufacturer).
Some phones (like Samsung, Xiaomi, Huawei) have extra power management settings:
Look for “Background usage limits”, “App launch control”, or “Auto start” settings.
Restricted Background Data / Network Access
Garmin Connect needs background access to Bluetooth, Wi-Fi, and mobile data.
Fix:
Go to Settings > Apps > Garmin Connect > Mobile data & Wi-Fi
→ Enable “Background data” and “Unrestricted data usage”.
Device-Specific App Killers
Some Android OEMs (like Xiaomi, Huawei, Oppo, Vivo) use aggressive app-killing policies.
Fix:
Check the OEM-specific background management settings.
For example:
Xiaomi: Add Garmin Connect to “Autostart” and exclude from “Battery saver”
Huawei: Set to “Manage manually” with all permissions enabled
(I don’t have an Android device myself, so I can’t test it):
Battery Optimization / Power Saving Settings
Restricted Background Data / Network Access
Device-Specific App Killers
Disabled Notifications or Permissions
Third-party Battery Saver or Task Killer Apps
