openHAB for Garmin

[vespaman (Micael)]

@the-ninth

Did you install the openHAB app onto your watch using the Connect IQ phone app?

No, I installed it from apps.garmin.com by pressing “Download”, and then it was on my Fenix after a few seconds.
Is this not a supported way of installation perhaps?

Edit: I installed IQ Conncect on my phone, and found the settings there, so I should be good to go, thanks!

This flow is disruptive and not suited to use cases requiring frequent interaction or real-time updates.

In the case of the openHAB Garmin app, the app’s interaction model is based on dynamically fetching and rendering a sitemap. To use WiFi for this:

• The app would need to trigger a sync mode at startup to fetch the sitemap.
• After the app restarts, it could show the UI - but would be unable to perform updates or send commands without triggering another sync cycle.

What would be your use case for having the app connect via WiFi instead of the phone? Could you live with the limitations for your use case?

My use case would be based on the fact that I don’t carry my phone with me all the time, and often loose connection to it. And one dream scenario would be when I arrive home after a long jog, sweaty and exhausted, that I could activate one of the water taps in the garden for a quick cool down. And also, when I’m outside in general, and want to start the lawn mover etc etc.
Inside, it is easier to use google voice to do stuff, so here it is not as important. (I don’t have full bt coverage in the house either, far from).

Could it be a solution to for the app to have full function while connected to the phone, but once outside BT connection, only use wifi for enabling/disabling? No/less polling that is.

I agree, it can be annoying to see the syncing, if this has to be seen, but a decent trade off.

Having said that, I still want to try the app, but maybe it is not as useful for me. I fully understand that I might not be the target user type.
I think I looked at APICall some time ago, but it was a bit too basic IIRC.

[the-ninth (Robert)]

@vespaman

Could it be a solution to for the app to have full function while connected to the phone, but once outside BT connection, only use wifi for enabling/disabling? No/less polling that is.

Let’s explore this idea a bit further.

I think the most workable approach would be for the app to go into WiFi sync mode on startup and poll the sitemap once, and then simply accept the risk that the displayed states may become stale. The likelihood of a state change happening between the user opening the app and navigating to the item they want to control is probably quite low.

Once the user reaches an item and triggers a command, the app could re-enter sync mode to send the command. One open question is how to handle cases where the command is not processed, or where triggering the command results in additional state changes behind the scenes. Currently, the state of a menu item updates immediately after the command’s web request completes successfully. If the backend processing in openHAB then fails or results in another automatic state change, the next polling cycle would eventually correct the displayed state. For WiFi-only operation, we could either live with this limitation or introduce a small delay after sending the command and re-poll the sitemap during the sync phase. Admittedly, this is a bit fragile, since there’s no guarantee when all background processing is actually complete.

An alternative would be to not display state at all when using WiFi, and simply allow commands to be sent. However, this would introduce quite a bit of complexity, both in the UI and under the hood. For example, supporting a toggle action would now require fetching the current state during sync before issuing the appropriate command. Because of that, I lean toward the first approach - it’s simpler and still provides reasonable usability.

For a bit of background: the full-screen widget is currently the only place in the app where WiFi could be supported. When using BLE, the preview glance (which shows the sitemap name) already polls the sitemap - provided the device allocates enough memory to support glance updates. So in most situations, the full-screen widget will already have a fairly recent sitemap snapshot in storage. However, the glance cannot use WiFi, and any background process the app could run would be limited to at most once every five minutes - and that too wouldn’t be able to use WiFi.

Bottom line: after considering the trade-offs, a limited WiFi mode seems feasible. The app would just need to clearly communicate the limitations to the user - for instance, by visually indicating that it’s operating in reduced functionality mode.

I’d be very interested to hear what others think - how important is a WiFi mode to you?

Since my development capacity is limited, it ultimately comes down to priorities. Would you consider WiFi support more valuable than, for example, supporting additional sitemap elements?

[vespaman (Micael)]

@the-ninth

Bottom line: after considering the trade-offs, a limited WiFi mode seems feasible. The app would just need to clearly communicate the limitations to the user - for instance, by visually indicating that it’s operating in reduced functionality mode

This limited WiFi mode is not so much a limitation imho, but I fully understand this might not be on top of the list for everyone. Especially if there are units without WiFi support.
I get that your time is limited, so I’m happy this is is at least considered, however it pans out.

Cheers,
vespaman

[stonke (Kristoph)]

@the-ninth

Since my development capacity is limited, it ultimately comes down to priorities. Would you consider WiFi support more valuable than, for example, supporting additional sitemap elements?

I would not if asked. Some colors(label/values), visibility options or more level sitemaps would be appreciated more I guess.

[Mherwege (Mark Herwege)]

I know these wouldn’t be the typical devices for this. But I have a GPSMap66 device which may be capable for this, and an old Oregon 600 device. As you see, these devices are mainly used for hiking, but I also use them on my bike. And opening the garage door when arriving home from it would be sweet.
I noticed the Domoticz app can be installed on the GPSMap66 device.

[the-ninth (Robert)]

@Mherwege

But I have a GPSMap66 device which may be capable for this, and an old Oregon 600 device.

The GPSMap66 might work - it has sufficient memory, though it uses an older API level than we currently support. I’ll look into it: https://github.com/TheNinth7/ohg/issues/101

As for the Oregon 600: unfortunately, it doesn’t support Connect IQ apps at all, so it’s not an option. Only the Oregon 7 series includes CIQ support.

[the-ninth (Robert)]

@stonke

I would not if asked. Some colors(label/values), visibility options or more level sitemaps would be appreciated more I guess.

Thanks for the suggestions! Could you elaborate a bit on what you have in mind?

Regarding colors - we’re limited to what’s defined in the sitemap configuration. As far as I know, it’s not possible to assign colors there. Or is there a way to do that that I’ve missed?

What exactly do you mean by visibility options?

And for more levels - we already support Frame elements, which let you organize items into submenus. Are you thinking of something beyond that?

[stonke (Kristoph)]

I was thinking about:

Sitemaps

And

Sitemaps

About levels I have tested Frame element + Text element as submenu but when tried another level (Text element under mentioned Text element) it didnt go through.

[the-ninth (Robert)]

@stonke

I was thinking about:

Got it - thanks for clarifying! My current focus is on expanding support for additional primitives (more Switch types, Rollershutter, Dimmer), but I’ve noted your suggestions and will revisit them later.

Tracked here for reference:
https://github.com/TheNinth7/ohg/issues/102
https://github.com/TheNinth7/ohg/issues/103
https://github.com/TheNinth7/ohg/issues/104

[volfan6415 (Zachary Christiansen)]

Just found this thread. I have a garmin 965. I am installing the app and glad to be able to test. Love to see openHAB comming to garmin.

[volfan6415 (Zachary Christiansen)]

Any plans to support buttons? I want to be able to have items for example that always send only one command when pressed. (unlock door, activate good night routine) etc.

i know i can do it with rules and a dummy item but would be nice to have a button option enabled from the mapping function in the sitemap:

Switch item=Alexa_Good_Night mappings=[ON=“Good Night”]

[stonke (Kristoph)]

@the-ninth that support for mappings could be usefull also for Dimmers. I can not imagine comfortable slider on smartwach but implementation of 3-4-5 static values with mappings would be easy.

Switch item=DimmerItemName mappings=[0="OFF", 50="50%", 80="80%", 100="100%"]

Sitemaps

[the-ninth (Robert)]

@volfan6415

Any plans to support buttons? I want to be able to have items for example that always send only one command when pressed. (unlock door, activate good night routine)

Yes, the next version will include exactly what you’re looking for.

• With one mapping, selecting the menu item will directly send the command.
• With two mappings, it will toggle between them.
• With more than two, it will show a small menu for selection.

I’m not sure yet when it will go live, but I’d say by the end of next week at the latest.

[the-ninth (Robert)]

@stonke

@the-ninth that support for mappings could be usefull also for Dimmers. I can not imagine comfortable slider on smartwach but implementation of 3-4-5 static values with mappings would be easy.

A Slider widget will also be included in the next version.

In the Sitemap, the minValue, maxValue, and step parameters define the available range. The widget lets you scroll through these values and select one. Depending on the releaseOnly parameter, the command is sent either during scrolling or only upon confirmation.

Here’s how it will appear on both button-based and touch-based devices:

[the-ninth (Robert)]

Thanks to the rainy weather, I was able to complete v0.2.0. The major changes in this release include:

• Broader Support for the Switch Element:
  All item types are now supported - including groups - and the app handles both on/off switches and defined mappings. (See the Switch section in the user manual for details.)

• Slider Element Support:
  All item types are supported. The app ueses a full-screen, scrollable number picker. For usability, it’s recommended to set a reasonable step parameter to reduce the number of available values. (See the Slider section in the user manual for more details.)

For a complete list of changes, check out the full changelog.

What’s Next

For v0.3.0, the focus will be on:

• Stability: Fixing bugs and addressing your feedback on the new features.
• Scalability: Testing with large sitemaps.
• Caching: Improving the sitemap state caching strategy.

Let me know if you encounter any issues with the new release, or have suggestions!

[the-ninth (Robert)]

I’ve just published a new minor release.

In v0.2.1, the Switch element now respects the item’s command and state descriptions. As with the web-based widget, mappings take precedence. If no mappings are defined, the command descriptions are used to label the actions in the menu, while the state description is used to label the current state. If a state description is not available, the command description will also be used for the current state label.

You may also notice a small UI tweak: on devices that show a vertical focus indicator in the menu, the spacing between the label and the indicator has been reduced slightly. This helps compensate for the horizontal space now used by the action icon (orange right arrow).

View the full changelog

[stonke (Kristoph)]

I’m testing your latest version right now and it looks like everything works!
Although the read-only mode is basically enough for me, I’m tempted by the ability to control items from the watch with your Sliders
Unfortunately, based on the instructions, I don’t fully understand what means “Option 1 from the Sending Commands” section. It says Follow the instruction here: … but there is no clear instruction.
There is a *.jar file that I should copy to the ADD-ON directory right? I’m guessing because it’s not written anywhere.
The second trouble is “Log into the openHAB console” - I understand that the openhabian console is something completely different and I should connect using this description:
The Console | openHAB ?? I have never used that console since 5years.

EDIT: ok, found it myself. Instruction for next newbies:

1. Login normally into openhabian console,
2. Then type:

ssh -p 8101 openhab@localhost

3. Then type YES
4. Then type password (if not changed it is habopen)
5. Then type

bundle:list org.openhab.core.io.rest.core

6. And finally then type line to update bundle (in my case it was)

bundle:update 186 https://github.com/florian-h05/openhab-core/releases/download/4.3.x-command-json/org.openhab.core.io.rest.core-4.3.6-SNAPSHOT.jar

[florian-h05 (Florian H.)]

@stonke

Login normally into openhabian console,

Then type:

sudo openhab-cli console

also works fine and is easier to memorize.

[the-ninth (Robert)]

Another incremental update: v0.2.2 fixes a few bugs and improves how the app handles stale states.

If the state loaded from storage is older than 10 seconds, the app will initially display the sitemap elements without showing their states. The states will appear once fresh data is received. This is most noticeable if your homepage includes elements that display a state. If your homepage consists of frames, the state will likely be refreshed before you even open any submenus.

View the full changelog

[the-ninth (Robert)]

Version 0.2.3 introduces safeguards to protect against out-of-memory errors.

Two key limits have been implemented:

1. Sitemap Caching Limit
   The app now caches the sitemap only if it falls within a size threshold. Beyond this limit, Garmin’s storage functions fail, so the app falls back to loading the sitemap fresh on each startup. When this happens, a “Loading…” screen is displayed until the sitemap is fully retrieved.

2. Web Request Size Limit
   Garmin’s web request function supports JSON responses only up to a certain size. If the sitemap exceeds this limit, the app will display an error: “Sitemap too large.”

The number of sitemap elements supported within these constraints depends on the specific configuration. However, in testing, the following were the largest successful cases:

• With Caching: 20 frames, 60 switches, 5 sliders, and 15 text fields
• Without Caching: 32 frames, 96 switches, 8 sliders, and 24 text fields

At these scales, performance issues begin to emerge. Garmin CIQ apps are single-threaded, and processing large sitemaps can take a second or two - during which the UI becomes temporarily unresponsive. The next step will be to improve performance by splitting updates into smaller chunks and enabling user interaction between them.