After smartening our car gates and enabling our phones and cars to control them, I wanted to add another access option: our Garmin watches and cycling computers. When going on a walk or bike ride, the phone is often already tucked away in some pocket or backpack, and the Garmin devices would be a neat and easy way to close or open the gates. Particularly, I am using an Epix Pro (Gen 2), my wife a Venu 3S and also we have Edge 530 and 830 cycling computers. So, our requirement for this project was control of the car gates from these devices, including when outside of our home/WiFi and potentially also control of other smart home devices in the future.

The car gates are controlled by a Shelly Plus 1, and are integrated into our openHAB automation server. Both offer cloud-based access from the Internet, but unfortunately neither has native Garmin app for access. When researching alternatives, I looked at a few different Garmin apps.

The first type of app integrates specific home automation platforms, of which I found two:

• Samsung SmartThings is a home automation platform from Samsung that can integrate Shelly and many other devices and has a Garmin app. Unfortunately that Garmin app has not been updated for some time and does not run on my Epix Pro (Gen 2), therefore SmartThings was not an option for us. While it would work well with our Shelly-controlled car gates, otherwise its use would be limited in our environment, since there seems no way to integrate our BTicino devices, neither directly nor via openHAB or Apple HomeKit.
• myQ offers smart garage controls, including physical controls, mobile apps and a Garmin app. It supports different garage door openers, but unfortunately our Shelly Plus 1 is not among them.
• GarminHomeAssistant is an app to access Home Assistant, an open source home automation server similar to our openHAB. But since we are already on openHAB, introducing a second platform into our home only for the Garmin access was not an option for us.

The second type of app enables generic integration of smart home devices via REST APIs. In our case, the Shelly cloud API could be accessed from those apps. OpenHAB also has a REST API accessible via their free myopenhab.org service, however it is not compatible with any of the Garmin apps. This is due to a general limitation of the Garmin Connect IQ SDK, openHAB requires POST requests with “text/plain” content, but Garmin supports only “application/json” or “application/x-www-form-urlencoded” content. Update May 3, 2024: I have written another post on how to overcome this limitation and get openHAB and Garmin to work together.

• MyHomeControl allows configuration of multiple devices and multiple actions, each associated with a HTTP GET or POST request. However the documentation on how to configure POST requests is limited and the developer not really responsive. I was not able to get the app to work with the Shelly API and therefore could not use it for our purpose. Also it is not available for cycling computers but only watches.
  
• APICall also supports multiple devices and actions based on HTTP GET and POST requests, very similar to MyHomeControl. One advantage of APICall is that it also supports direct WiFi from the Garmin device, while MyHomeControl only works when there is a Bluetooth connection to a phone. Also APICall is available for both watches and cycling computers, and comes with much better documentation. With that documentation it was easy to get the app to work with the Shelly API, and thus APICall is the app I choose to work with in the end.
  
• WebRequest/Simple Web Request are both apps that are configured to send a single HTTP GET requests, for example to trigger more advanced logics and integrations via IFTTT. But since Shelly needs HTTP POST requests, and I did not want to introduce IFTTT as additional platform, these two apps were not an option.
• Web Requests Garmin is another app by the author of Simple Web Request, which allows multiple HTTP GET requests to be configured. However, it requires an Android app, and since I am on iOS, it was not an option for me.
  

After looking at all these options, it became clear that APICall is the only viable option to implement our use case.

APICall Setup

First, let’s look at an overview of how the control of the car gates via APICall works. The app runs on our Garmin devices, and executes a REST API call to the Shelly cloud service. Garmin devices access the Internet via the Garmin Connect Mobile app on our phones, either via the cellular connection (1) or local WiFi (2). The Shelly cloud service then triggers the Shelly Plus 1 to either open or close the car gates (3). Note: even if the Garmin device has WiFi, it will use the connection via the phone if available, because the WiFi is not on all the time to save battery and takes some time to connect.

To setup APICall, you first need the Connect IQ mobile app for Android or iOS. There you can install and configure APICall:

Search for APICall, then install it …

… and configure its settings.

In the settings of APICall, you have to enter a JSON string for each action. Below some info on how that JSON string looks like for our Shelly Plus 1, check the Configuration Guide section of the APICall documentation for more information and other use cases and examples.

To generate the JSON string for Shelly, you need to obtain some information from the Shelly device. Here two screenshots from the Shelly iOS app:

First you need the alphanumeric device identifier, as shown in the left screenshot. Second from the authorization cloud key section in the general settings you need the server name and the key itself. Node: identifier and keys are hidden in these screenshots with the white/blue overlays.

The Shelly Cloud API documentation shows how to build the URL and which content parameters to set. The Shelly Plus 1 has only one relay channel and ours triggers the gate operation (open or close, depending on current state) when switched on, and then automatically switches off after one second. Therefore only one action is needed, with channel number 0 and an “on” command:

{deviceName:”Gate”,deviceIcon:9,actionName:”Activate”,actionIcon:40,method:”POST”,url:”https://your_server/device/relay/control”,headers:”{\”Content-Type\”:\”application/x-www-form-urlencoded\”}”,POSTcontent:”{id:\”your_device_id\”,auth_key:\”your_auth_key\”,channel:0,turn:\”on\”}”}

Replace your_server, your_device_id and your_auth_key with the information obtained from the Shelly app. With this configuration, the APICall screen then looks like this:

If you run into issues, it may be helpful to test your URL and content parameters with a tool like Postman. Here a screenshot of Postman with the Shelly call configured. The request needs to be of type POST, and the body contains the content parameters as form-data:

Conclusion

The integration of our car gates turned out more complicated than expected, due to the lack of native smart home apps, and the incompatibility between openHAB’s REST API and Garmin. However, via APICall and the Shelly cloud, our car gates are now accessible from our Garmin devices. While the APICall user interface on the Garmin device is fairly basic, it is doing its job quite well and I am satisfied with how the solution turned out. As always, if you have any questions, feel free to contact me.