I’m developing an openHAB app for Garmin smartwatches and am currently looking for beta testers to help refine and improve it.
Supported Devices
Below are some of the currently supported devices. For the full list, please visit the Garmin Connect IQ Store.
Fenix Series: 6/6S/6X Pro, 7/7S/7X, 7/7S/7X Pro, 8/8 Solar (including Tactix, and MARQ variants)
Epix Series: 2, 2 Pro
Enduro Series: 2, 3
Forerunner Series: 165, 255, 265, 955, 965
Venu Series: 2, 2S, 2 Plus, 3, 3S
Vivoactive Series: 5, 6
Edge Series: Explore 2, 540, 840, 1040, 1050
Current Functionality
The app is based on openHAB sitemaps, and currently supports:
Sitemap frames for organizing display
Switch elements, including groups and with mappings
Slider elements
Text elements
With a standard openHAB installation, the app supports read-only access - you can view the status of your items directly on your watch.
To enable control commands (e.g., toggling a light), you’ll need to either install the backported JSON-based REST API for sending commands or set up a custom Webhook. Full instructions are available in the documentation (see link below). Note: openHAB 5 will include this REST API by default. Big thanks to @florian-h05 for implementing the new API!
Full app documentation, including Webhook setup instructions, is available here: https://ohg.the-ninth.com/
What’s Next
This thread is open for feedback, bug reports, and feature discussions.
I’d love to hear what you think, what works for your setup, and what you’d like to see in future versions!
The Fenix 6 Pro is not supported yet, but that shouldn’t be a major hurdle. In widget mode, it has more than enough memory to run the app smoothly. The only limitation is in the glance view, where available memory is tighter compared to newer models. I may need to simplify the glance UI slightly to ensure full compatibility.
I think the issue might be the trailing / at the end of the URL. You should enter https://home.myopenhab.org (without the /). I think that will be a common mistake, so I’ll update the app to handle both formats more gracefully in an upcoming version.
Most of my testing so far has been with a local openHAB instance. Now that I’ve started using myopenhab.org more in the simulator, I’ve noticed that it occasionally shows an S-400 error. This shows up as a toast notification (a brief message at the top of the watch screen), indicating that the sitemap polling returned an unexpected result.
I’d be curious to know if you’re seeing the same issue. It might be that the polling interval is too aggressive for myopenhab.org.
By the way, version 0.0.4 now supports text fields. I noticed you’re displaying garage door status in a separate field - I do something similar. With the new text field support, it now looks like this:
Thank you very much for your work. I am using the app on a Garmin Epix 2 through the myopenhab.org cloud connection. I previously had the “myHomeControl” app running as per the instructions on your blog. With your instructions everything was set up in 5 minutes, including the webhook setup. Your app works way better, as I used to loose connection if I didn’t have Garmin Connect open on the phone (I am using iOS). The idea to use a sitemap is perfect, this saves a lot of configurations in the Garmin ConnectIQ app.
Occasionally (or actually quite frequently) I am seeing the error “Unexpected response: null”. I have seen the S-400 error maybe once only.
I will keep on testing and report if I have any useful findings. For now very happy with your app, it also looks very cool matching with the other Garmin apps (and much better than APICall) with the cool openHAB logo of my favorite home automation system on my favorite watch
Unfortunately, compatibility with the Garmin Approach S62 is unlikely.
As with the Vivoactive 3 discussed earlier in this thread, the S62 provides very limited memory for Connect IQ apps - only 59.9 kB. By comparison, the newer Approach S70 (which I believe is its direct successor) offers around 763 kB, more than ten times as much.
This limited memory must accommodate everything: the application heap, binary code, and any image resources. As a result, both the feature set of the app and the size of the sitemap it displays directly impact memory usage.
In its current state, the latest app version already consumes about 68 kB in my demo setup - with support for just frames, switches, and text elements, and using a relatively small sitemap.
While there’s always potential for further optimization, I don’t expect to achieve compatibility with the S62 or similar-generation devices.
Both errors are actually the same - the S-400 is used in the toast notification, where there is not enough space to show the full error text.
Do you see the full version (“Unexpected response: null”) error in the glance view or the full-screen widget? If possible, could you take a photo the next time it appears?
I’ve created a GitHub issue to track this:
If you have a GitHub account, feel free to post the photo there directly. Otherwise, you’re welcome to share it here too
Update on S-400 / Unexpected response: null Errors
I’ve configured my Garmin watch to access openHAB via myopenHAB.org and can now consistently reproduce the issue.
Throughout the day, I’ve published several updates to the app - the latest is version 0.0.4.3. This version makes the polling interval configurable, with a default of 3000ms. With the longer interval, the errors occur less frequently - but that may simply be because fewer requests are being made, not because the underlying issue is resolved.
Importantly, I’ve also been able to reproduce the issue outside the Garmin app. When repeatedly calling the Sitemap REST API via Firefox, I occasionally receive an HTTP 200 OK response with an empty body.
Initially, I suspected this might be due to rate limiting, but typically rate-limited responses return HTTP error codes like 429 or 503, not a 200.
So it appears the issue is not specific to the Garmin app itself. I’ve started a thread in the myopenHAB subforum to gather more input:
If anyone is able to test the latest version (now 0.0.5.3), I’d really appreciate it if you could let me know whether you’re now only seeing SEMRES errors, or if S-400 is still showing up as well.
On my watch, the app is now quite usable with myopenhab.org. The SEMRES error still pops up occasionally, but thanks to the new error handling, it only appears as a toast notification - so the app remains fully usable.
Currently, the installed version is only visible indirectly through the Connect IQ app. If there’s no update option available, you’re likely on the latest version - but keep in mind, Connect IQ can be unreliable in this regard.
Specifically, -2 is BLE_HOST_TIMEOUT, which means there is a timeout between watch and the phone. For reference, -300 would mean a timeout between the phone and the server.
Can you confirm whether your watch has a stable Bluetooth connection to your phone? Is the error persistent, or does it happen only occasionally?
A complete connection loss usually results in error -104, which the app detects and displays as ‘No phone’.
Thanks for the explanation. It is my Sons watch - so the error was most likely due to him moving around while I setup his watch.
This did trigger me to try the App again with his phone nowhere near.
The app still opens and shows a status. The “No Phone” error only comes up if you try and toggle a switch etc. Does this mean that the sitemap is cached? There does not seem to be any indication when opening the app that the status may be "stale?
I also just checked with Garmin Express and do not see an option to configure the polling interval - so assume the App version has not updated?
Yes, it sounds like you’re still using an older version of the app. I use the Garmin Connect IQ phone app to install and update apps myself - I haven’t tried Garmin Express, so I’m not sure how well it works.
You’re also right about the sitemap being cached. This is done to speed up app startup. The sitemap fetched for the glance view is cached as well, so there’s a good chance (though not a guarantee) that the app launches with an up-to-date sitemap. However, if you switch from the glance to the full app before the glance receives a new sitemap, the app may initially still display the older cached version.
Regarding error handling:
Communication errors currently show up only as toast notifications, which can be a hint that the data is outdated.
If three consecutive communication failures occur, the app escalates to a full-screen error.
There’s still quite a bit of room for improvement:
Better differentiation between temporary and fatal communication errors
Automatically invalidating the cached sitemap after a fatal error
Passing error states from the glance to the full app - currently, the glance just shows the cached sitemap name or “openHAB” and doesn’t indicate errors
For now, I’m prioritizing better error handling and general stability over new features.
I waited a bit responding as I was seeing if I could trigger any of the error messages. It takes a while for me before I can see the new version in Connect IQ. Sometimes killing the app / rebooting the phone helps but the latest is 0.0.5.2 for me now.
As I said, the app works flawless without showing connection errors.
iOS version 0.0.5.2
openHAB 4.3.5 with webhook binding (0.2.0) setup as per instructions