I have been tinkering with a solution to access openHAB from Garmin devices, via the Webhook HTTP binding. Unfortunately the standard REST API of openHAB is effectively incompatible with any Garmin software, since the Garmin Connect IQ SDK does not allow the type of POST request required to send commands to items.
However with the Webhook binding it is possible to provide a simple HTTP GET interface and control openHAB via various Garmin home control apps that support such calls.
I have described the solution in detail on my blog:
Thanks for your Garmin/openHAB integration investigation. It looks like your goal is/was to use a Garmin device to issue commands to openHAB but while that could be useful, we already have personal devices (phones) that do a decent job of this.
I’m wondering if Garmin watch integration could happen in the other direction. I want to:
schedule openHAB to download my collected metrics from my watch automatically.
detect when my Garmin watch can connect to my local wifi or bluetooth for presence detection.
read battery levels, etc.
Do you think this could be doable? Without having to go through Garmin’s servers?
Yes, exactly. I had some specific use cases where I prefer the control from the watch over the smart phone. But you are right, that just makes things a little bit more comfortable, it would work via the phone as well.
I did not investigate this in detail, but here is what I know:
There are some APIs for accessing Garmin data, but they do go through the Garmin Connect servers.
The WiFi connection of the watch is only enabled on demand, so I think it won’t help you much in terms of presence detection. Here I think really the phone would do a better job, because it is constantly connected. If you are using UniFi there is a binding for that, but I am sure something could also be done with other WiFi systems.
Theoretically there is a way for custom Garmin apps to interact with custom phone apps, which could be used to bypass Garmin Connect servers, but you’d need to write an app for the watch (I did that, and it was painful) and an app for the phone.
It’s great to hear about your experience with the Garmin SDK, even if it was a bit of a challenge. I agree that using the phone for presence detection seems more reliable given its constant connectivity.
The idea of developing a custom app for both the watch and phone sounds promising, albeit complex. Have you thought about any specific features you’d want in that app? It would be interesting to see how it could enhance the integration further!
Personally, I’d be interested in an app that provides a generic way to control and display the status of various items or points. It could be built around a non-semantic structure, where you simply place everything you want to control or monitor directly on the watch.
The first major challenge is that this would require a server-side component, since the existing APIs aren’t compatible with the Garmin SDK. In practice, this would likely mean developing an openHAB add-on or similar integration.
Another interesting challenge is the wide variety of Garmin watches. Older models are quite limited in terms of memory and processing power. Additionally, the user interface paradigms differ: some watches are primarily touch-based, while others rely on physical buttons.
Last but not least, while the Garmin SDK is decent, it has its shortcomings and bugs. UI functionality in particular lags behind what’s available in native apps on more recent Garmin devices. It’s quite clear that third-party apps are not as deeply integrated into the Garmin ecosystem as they are, for example, on Apple devices.
Such an app would be really great — long time ago I had the goal to look into this myself but I am busy enough developing openHAB, I guess its not realistic to also work on an app myself.
I would recommend to probably build it around sitemaps. You don‘t need to support all sitemap elements, but using sitemap elements would allow you to have the Items and their representation configured in openHAB and get all needed data with one GET call. If possible, you can subscribe to the SSE events or poll the data.
What‘s the problem there? Is it the type of HTTP requests, media type or something else?
I haven’t done a thorough analysis, I was only looking at sending a command. openHAB expects the command as raw content of the request, but Garmin can only send form-encoded or JSON. I am sure many of the JSON-based APIs would work, and only some would need a kind of proxy service to bring them in line with what Garmin can do.
For my purpose I then used the Webhook binding to create an URL that can send commands to any item. But I don‘t think that is stable enough to base a whole app upon.
The command REST endpoint can be adjusted to support JSON as well. As the payload type is determined through headers it should be able to support multiple „formats“ for the same endpoint.
I can check that.
That would be great. Even without a dedicated app, it would open up openHAB to existing generic Garmin apps. There are two home automation apps, APICall and myHomeControl, that basically let you configure devices and commands bound to REST API calls. myHomeControl has a bit of a nicer user interface, but APICall is better documented and supported.
Yes, sitemaps look promising. Polling the data would work, with the Garmin SDK you can define a timer that regulary makes a web request and then updates the UI.
What is the difference between polling page data and subscribing to events? I tried to figure it out from the API Explorer but did not really get it.
It would make life easier to limit the app to Fenix 7+, Epix2+, Forerunner 955 and x65, venu2+ and vivoactive3m+. Devices prior to that are quite limited in terms of memory available to apps.
It itches me to work on an openHAB app, though I am also not sure if I really have the capacity right now. Btw, here is the app that got me into Garmin development: https://evccg.the-ninth.com/
I actually have a license for the latter, but never used it that much because I always had to setup create some type of webhooks. Back then I wasn’t involved in development and didn’t consider adding the missing functionality to openHAB.
You cannot really check that from the API explorer, I think Swagger is not able to display SSE in real time.
You can check the network tab and you’ll see that with event subscription events are send in real time from the server to the UI, usually Item state changes. Currently the UI is using SSE, but we also support WebSocket.
When using polling, you won’t have real time events, if something changes you won’t notice until the next poll.
OK, understand. There is no support for anything like that with Garmin, so polling is the only option. But with a low polling interval I think it could work well enough. Garmin CIQ apps run only while they are open, so when the app is not, the polling would not put any load on the system.
(side note: there is support for background services, but those can run only once every five minutes)
One more thought on that: I know the Garmin SDK can send JSON payloads, but I haven’t tested whether the mentioned apps support it. Sending the command as a URL parameter in a GET request would definitely work across all of those Garmin apps. Would it be possible for openHAB to support that for this API as well?
About sitemaps:
Is this a feature that’s here to stay? It seems like pages are a competing UI option now, and the iOS app also seems to focus on pages rather than sitemaps.
Sorry if this is a basic question - I’ve mainly been using openHAB as an integration server for my home automation setup, and so far I’ve only used the UI for configuration purposes.
Yes, sitemaps has been there from the very beginning and is still continuously developed and extended with new features.
The iOS app might lack some of the newer Sitemap features, Pages are easier to implement due to basically being a webview rendering Main UI. Pages need no additional development effort for the app devs, Sitemaps do so it takes a bit longer to implement new features there.
Great! I’m currently experimenting with sitemaps and exploring the API a bit more.
I have another question: Does the openHAB REST API support a query parameter to limit the JSON response to specific fields? I couldn’t find anything like that in the documentation. The server I’m working with right now supports jq-style filters for that purpose.
That said, it’s not a showstopper — it would just mean the app might be limited to newer Garmin devices due to the size of the JSON that has to be handled.
Garmin’s communication module behaves differently depending on whether the watch is paired with iOS or Android.
On Android, only HTTPS calls with a valid certificate are supported.
On iOS, both HTTPS and unencrypted HTTP calls are allowed.
For Android users, the most practical solution would likely be to use myopenhab.org or another openHAB Cloud instance. For authentication, basic authentication would be the simplest method to start with. Garmin also supports OAuth2, so if the openHAB cloud service supports it, OAuth2 could be integrated later.
iOS users could alternatively connect directly to a local openHAB instance, either via the local network or through a VPN like Tailscale.
What do you think about this approach?
Another related thing:
All communication routes through the paired phone. Although some watches support Wi-Fi, the Wi-Fi connection is not permanent (to save battery). This means that relying on Wi-Fi would result in significant delays, as each REST API call would require establishing a new Wi-Fi connection - severely impacting speed and user experience.
The app now supports frames and switches. Server URL and sitemap name can already be set in the app settings. And the status is updated in the background at a very tight interval.
