Thank you, nice update. Unfortunately I cannot find anything on the wifi feature on the manual (Garmin App | openHAB), so was wondering how long and often does it keep using the wifi when BLE isn’t available? My concern is obviously the battery of the Garmin device so would perhaps wish to clearly configure it to “Never use wifi unless I explicitly allow it for this session”.
If it already behaves nicely and stops using wifi as soon as I close the app on Garmin, then there are no issues - would still perhaps want to configure the connection mode and select between “BLE”, “BLE+Wifi”, “Wifi”, or something similar
Please note that the stable docs on www.openhab.org don’t get updated automatically if there is a new release of any of the apps. Instead, an automated PR with the changes is created and has to be merged by a doc maintainer. I’ve just done that, so the docs should become available in a few minutes.
next.openhab.org always contains the latest docs sourced from the Garmin app repo, so there are the docs for the beta version.
Sorry, when I released the new version and wrote my post, I forgot that the documentation was not yet available in the stable docs. @florian-h05, thanks for taking care of it!
And you can easily select the value, it’s sent to the item, and pressing the Back button doesn’t cause any crashes - so once again, you did a great job.
The app crash was reported through Garmin crash reports and appears to have occurred on an Edge 1040. If the affected user happens to be reading this, I would be very interested in understanding exactly how it happened.
My understanding is that automatic color mode changes are time-based, which would mean the app was running exactly at sunrise or sunset. The color mode can also be changed manually, but not while the app is running.
Some background: positive error codes are HTTP status codes, while negative ones are Garmin-specific. The Garmin error codes are documented here. Another useful starting point is the connectivity section of the documentation.
-300 indicates a communication timeout, so it looks like the server is not reachable. Could you share a few details about your setup, for example whether you are using a local network or VPN, and possibly also the URL and sitemap name you are using?
Basically, the watch uses the phone for network connectivity whenever possible. So if you can reach the URL from your phone, it should also work on the watch.
I am not entirely sure how the default openHAB certificate works, but typically you would need a domain name and obtain a certificate for that domain from a provider such as Let’s Encrypt.
For Android users, the most straightforward option is to use myopenhab.org, as it already provides a valid certificate. There is also a section in the documentation covering this: Using myopenHAB.
A missing or invalid certificate would result in a -1001 error, so it is unlikely to be the cause of the issue you are seeing.
Technically, the Wi-Fi connection does not require a certificate either. However, if a phone connection is available, the app will not fall back to Wi-Fi. I could change that behavior so the app also falls back to Wi-Fi in case of a -1001 error. However, due to Garmin platform constraints, Wi-Fi mode is limited, as described in the Wi-Fi section of the documentation. For that reason, I think using myopenhab.org is still the better option.
Thank you for your answer and moving my post to the correct discussion.
Using myopenhab.org I can successfully connect. That’s great.
I was trying to use my local OHs address like “https://my-oh-server:8443” (no VPN)
This is of course working on the phone directly, after ignoring the certificate warning.
So I guess it is related to that. It seems it is needed to issue some kind of (public) valid certificate. Maybe I can add my default OH certificate to my Androids certificate store or something like that, I’ll check if that is possible.
Interesting. So far I have only seen -1001 when there is no certificate, but it may well be that under certain circumstances the behavior is different and -300 is returned.
Does this change in any way if you use the IP address instead of the host name?
Let me know if you manage to add the certificate to the local store. If that works, it could be an interesting option for many users, and I could include it in the user manual.
It seems there is no easy way importing just the certificate.
Android needs a certificate incl. private key. This makes no sense to me as the PK in general has to reside on the server, not on the client…
Is there anyone using the local OH-Server URL without special certificates configured?
Maybe there is a possibility to add an option to let users bypass certificate warnings?
I also tried IP-Address with same result.
Unfortunately, these are fatal errors. Web requests to servers without valid certificates simply fail. I this is enforced by Android, since Garmin does not seem to have the same restriction when paired with iOS.
But I liked the idea that my watch is only be able to connect to Openhab when I’m at home, not from everywhere. If the local option doesn’t work, I may use myopenhab or try to use an official certificate. However it is not possible to issue an official certificate for a local domain. I think the only way is possibliy to create a self signed cert (with private key), configure it in OH and try to import it to my Android phone. If I ever get bored, I might give it a try and let you know
Wifi option is also not prefered for different reasons.
Thanks for your help anyway
I have just uploaded v1.2.3 to both the stable and beta apps. It fixes crashes during view handling that were reported via the Garmin ERA system.
The crashes were reported for a Vivoactive 5 and Fenix/Tactix/Quatix 8 devices between March 28 and April 10. If anyone here experienced these crashes, please get in touch. I would like to better understand the situations in which they occurred and confirm that the issue is now resolved.
I have just uploaded v1.2.4 to both the stable and beta apps with the following changes:
Optimized glance memory consumption
Added support for the newly released Forerunner 70, 170, and 170 Music models
Added support for older models with sufficient CIQ API level and hardware resources: Approach S50/S70, D2 Air X10, D2 Mach 2, D2 Mach 2 Pro, Instinct 3 AMOLED, and all 1st Gen MARQ variants
If anyone is still looking for a way to access openHAB over HTTPS on Android without using myopenHAB.org, I recently tried a different approach that works very well for me.
I use my gateway’s built-in DNS server (UniFi in my case) to provide local hostnames for my internal services. I then added step-ca as a local certificate authority, which allows me to issue trusted certificates for internal services. I issued a certificate for my openHAB server and imported it into openHAB.
The only prerequisite is installing the root certificate of your local CA on each client device. That’s a simple one-time task. After that, all certificates issued by your CA are trusted. While there is no automatic renewal (at least in my current setup), you can issue certificates with a longer validity period. I chose two years, so renewing simply means issuing a new certificate and importing it into openHAB every couple of years.
In my setup, both openHAB and step-ca run as Docker containers on my Synology NAS. The initial setup wasn’t particularly difficult, but there are quite a few steps involved. There are plenty of tutorials available online, and the AI chatbot of your choice will also be quite knowledgeable about the topic. Overall, it took me about an hour to get everything up and running.
The result is well worth it. I can now access openHAB, my Synology, the UniFi web interface, and other internal services via HTTPS without any browser security warnings. It even works with my Garmin watch once the root certificate is installed on the paired phone.
My Synology also runs Tailscale. By configuring Tailscale to use my local DNS and advertising my home subnet through the Synology, I can use the same local hostnames (e.g. openhab.dts.home) from anywhere while connected to Tailscale. This means I don’t have to remember different hostnames or URLs depending on whether I’m at home or away.
The basic steps are:
Choose a local DNS namespace
Decide on a local domain (I use dts.home) and assign meaningful hostnames, e.g. openhab.dts.home.
Configure the corresponding DNS records in your local DNS server. In my case this is UniFi, but Synology or any other local DNS server works just as well.
Install step-ca
Install step-ca (I run it as a Docker container on my Synology).
Initialize the CA using step ca init.
Choose a name for your certificate authority (e.g. Home Internal PKI).
Create a DNS record for the CA itself, for example pki.dts.home.
Configure the CA
Adjust the default certificate validity to something appropriate for your environment (I chose two years).
Back up the entire step-ca directory, including the configuration, database, certificates, and private keys.
Install the root certificate
Install the root certificate on every client that should trust your local certificates.
On Windows, import it into Trusted Root Certification Authorities.
On iPhone/iPad, install the certificate profile and enable it under Certificate Trust Settings.
Repeat the process for your other devices.
Issue an openHAB certificate
Use step-ca to issue a certificate and private key for your openHAB server (openhab.dts.home in my case).
Configure openHAB
Convert the certificate into the Java keystore format expected by openHAB.
Replace the existing keystore in the openHAB userdata/etc directory and restart openHAB.
(Optional) Configure remote access
If you use Tailscale, run it on your server or NAS and advertise your local subnet.
Configure Tailscale Split DNS so that local hostnames such as openhab.dts.home resolve correctly even when you’re away from home.
This allows you to use the same URL regardless of whether you’re on your home network or connected remotely via Tailscale.
