Hello @NP_Complete ,
may be you missed this part: “Change the URL to something you can monitor on the server side to see if the call is going through.”
That is how I was able to see if the call was working or not, I checked the logs on the server side. I just did not want to provide a link to my own HA on github so I set it to www.google.com
As to the original purpose I think it is to sync music mostly, but I don’t see anything that would prevent us to use this call for a simple GET.
Yeah, I got that bit. I didn’t change the address because I was already getting reported failures for a realibly good URL. The reported failures gave me little confidence in being able to integrate any such solution since the returned values need to be useable. Also the presence of the Sync progress bar & view are a distraction from the app.
On the latter, it looks like even if the return codes issue can be addressed, work needs to be done to hide the sync progress view, so potential to be a bit hacky.
Odd that Garmin did not provide something simpler and more helpful for plain HTTP over Wi-Fi!
@NP_Complete Hi Philip. I’m having a similar problem accessing my menu JSON file, but I don’t think I have the same issue with the url to file location mapping. I’ve been through all the documentation and troubleshooting, which was great getting me to this point, but nothing I’ve found seems to work in terms of actually accessing the file.
I’m completely new to JSON and just trying to get anything to show up on the dashboard so I can confirm the basic connection is there and then work on setting up my dashboard.
I’m stuck here:
I also can’t get to the menu.json file pasting the https://MY-ID.ui.nabu.casa/local/garmin/menu.json url in my browser - I get a 404 error
Here’s what I’ve done so far - the step I can’t get past is an error message that says “No JSON returned from HTTP request” as soon as I open the app on my watch. I was getting error messages saying something like “check the internet connection” before I think I sorted out the urls to use, so I think I might have made enough progress to get the watch connected to the JSON file, but that’s where I’m stuck.
I’ve generated a long-lived access token in HA and have that in the API Key for HomeAssistant field in the App Settings.
I have [u]https://MY-ID.ui.nabu.casa/api[/u] in the URL for HomeAssistant API field in the App Settings
I have [u]https://MY-ID.ui.nabu.casa/local/garmin/menu.json[/u] in the URL for menu configuration (JSON) field in the App Settings
I’ve created the file /homeassistant/config/www/garmin/menu.json in the Home Assistant File Editor
I’ve added this to my configuration.yaml file and rebooted HA:
http:
cors_allowed_origins:
- https://house-of-abbey.github.io
{
"$schema": "https://raw.githubusercontent.com/house-of-abbey/GarminHomeAssistant/main/config.schema.json",
"title": "Home",
"items": [
{
"entity": "switch.victron_system_relay_0",
"name": "Van Engine",
"type": "toggle"
}
]
}
Could it be related to the Nabu Casa certificate? I saw a post about including these two lines in the HTTP section of the confiuration.yaml file, but I can’t restart HA due to an invalid configuration error with these lines in there and I don’t know how to include the certificate from Nabu Casa there if that’s what I need to do…
Thanks in advance for any help!
That’s where your problem starts. The URL is wrong. No point putting the URL anywhere else until you get that right in the browser.
The URL should work in the browser without any long lived tokens, that part is your next step after getting the correct URL.
- I’ve created the file /homeassistant/config/www/garmin/menu.json in the Home Assistant File Editor
Okay that looks fine.
- I have [u]https://MY-ID.ui.nabu.casa/local/garmin/menu.json[/u] in the URL for menu configuration (JSON) field in the App Settings
That too does not look too bad, it should map across if the domain name is correct. So either the domain name is wrong or the files at that location on your webserver are not publically accessible for some reason.
Essentially, work the problem until the URL works in a browser and forget the watch app until it does.
That’s fot the on-line web editor to work, but that requires a pubically accessible URL first.
That certificate issue requires a little more thought, not sure what that’s about. Let’s park that one for the mo’. Comment out those changes to configuration.yaml briefly. Get your HA instance restarted and check you can reach the URL from a browser. Until you’ve got that sorted you are dead in the water…
Thanks for the quick reply. I agree and understand just getting the url to work is the first step. I’m sure the domain name is right - I’ve pasted the same Nabu Casa ID that is working for the API into that url, and triple-checked the folder hierarchies in HA to the url structure. I’ve always copied and pasted the Nabu Casa ID number to avoid any typos, too. I even tried moving the menu.json file up a folder level in HA to just the www folder, but that didn’t change anything. I did comment out the whole http section in the configuration/yaml file as a first step.
I also confirmed that I don’t have anything related to Trusted Networks or anything like that in my HA configuration - the file just has a few standard things like thermostats, etc. in it.
I did try shortening the url to see if I could access higher folders in HA, and once I got to just https://MY-ID.ui.nabu.casa/local/, I get a 403 Error (Forbidden) instead of the 404 error. Not sure if that at least confirms that the basic domain name is correct at least. This seems like a big clue - I get a Forbidden error at the www (local) folder level, but then 404 errors anywhere below that. But I have no idea how to confirm or address this.
I’m thinking there is some type of setting or configuration I need to do in HA to allow any folders to be accessible this way, but haven’t seen anyone else have issues with that or mention it. I’ve had the Remote Access for HA Cloud turned on since I started using HA, and the cloud access through Nabu Casa has worked for me on multiple devices since I started using it.
Here’s what the More Details about the HA Cloud certificates includes - neither of those match the (working) API Key, which is the long-lived access token I set up following the initial instructions. I can access the API and get the “API Running” message, though, so I’m assuming that url and key are all correct and working.
I also just tried going to the same local network as my HA instance and using the url http://192.168.XX.XX:8123/local/garmin/menu.json - I get the same 404 error with http and a different error with https: (This site can’t provide a secure connection; 192.168.XX.XX sent an invalid response. ERR_SSL_PROTOCOL_ERROR). The same IP address and port opens the HA instance when I’m on the local network.
I tried this link (https://homeassistant.local/local/garmin/menu.json) from the GitHub readme on the local network and got this error: "This site can’t be reached; homeassistant.local refused to connect.; Try: * Checking the connection, * [Checking the proxy and the firewall]; ERR_CONNECTION_REFUSED
I would suspect proxy or firewall issues, but the API connection works fine, as does every other remote connection I’ve tried to make to my HA instance…
I think I figured it out by finding this.
It looks like maybe this line in the Github readme file is out of date? Always putting the json file in the www folder within the config folder in HA is what was making it not work. As soon as I moved the json file to the www folder in HA at “root” (not in the config folder), it’s been working fine…
We have used
/config/www/garmin/<something>.jsonon our Home Assistant’s file system. That equates to a URL ofhttps://homeassistant.local/local/garmin/<something>.json.
Thank you for this report, I have updated the README.md accordingly. Very helpful of you to have solved the problem.
Hey,
I think I need some help troubleshooting.
My watch fails both on the API url and the menu url. When i open the app list, the first 3 second it says “unconfigured” and it changes to “unavailable”. This happens for both the api and the menu.
I have now moved the menu.json to a webhost completely outside my HA setup. I still fails.
I have a “DIY” https/ssl setup with cloudflare.
Its been configured by following this guide: Securing Home Assistant with Cloudflare (hodgkins.io)
From outside i can access my api url fine. Its also been tested with REQBIN.
Other steps Ive tried is to change both urls to my local IP adresses, and setting up a wireguard tunnel from my phone to my firewall at home. The urls with ip still works in my phone browser, but the watch says “unavailable” still.
So now I do not know where to look next.
Any suggestions?
(The watch is a Venu 2)
API url: https://t45.gmx.YY/api. (tried with / at the end aswell)
MENU url: https://gmx.YY/json/garmin.json
(replace “YY” with “no”, just a measure to avoid bots to fetch my urls.)
Thanks in advance.
My problem seems to be related to iphone // Connect app.
After closing and opening both ConnectIQ and Connect. The watch app now works 
Thank @NP_Complete for your help during the weekend
I am running into the same issue on my Fenix 7s. Just tried closing both Connect and ConnectIQ and re-opening, still no luck.
I have verified using the [editor tool](https://house-of-abbey.github.io/GarminHomeAssistant/web/) that my API and JSON file are available on my computer (while on local wifi). Yet, when trying to verify on my phone I see a “Check CORS settings on HomeAssistant server.” for both tests? Not sure what would be different from my phone vs my computer?
I have tried using both hostname urls and direct ip address urls, which fixed a different integration I am using, but still running into the “Unconfigured” → “Unavailable” ui.
When I open the app on my watch, I see an error: “Failed to register Webhook. No Response, check internet connection”.
Yet my phone is connected to the wifi.
Appreciate all the work you’ve done to build and support this app!
IPhone user?
Yup! Running iOS 17.5.1 on iPhone 13 Mini
Did you read all of the previous post?
Yes, I’ve read every doc and suggestion I could get my hands on
We have observed some peculiar behaviours over the last week or so. We’re worried that the fix that webhooks provided has come with a new infrequent ‘feature’ that we can’t catch in simulation. The latest version, 2.20, includes a speculative fix that we theorise might help. Otherwise, we have had success with uninstalling the app and starting again. Not ideal obviously, hence the speculative fix.
In the GHA app settings, scroll to the end to see your webhook ID, then check that ID is present on HA. On HA that’s under the cloud settings (top item in settings) at the bottom of the cloud settings screen. If your webhook ID is absent from that list, then you’ve fallen foul of this new bug.
But I’m hopefull v2.20 will fix this for you without a reinstall.
I am also running scripts and toggling switches with HassControl, so you can use that as well. But this seems a nicer way of doing it for sure.
EDIT: after quite some trouble setting this up - I managed to toggle a switch once but cannot reproduce using the same code - I think I might fall back to HassControl.
This seems at least in parts unnecessarily complex to set up? Especially the requirement to write json. How does HassControl manage to use a group of entitities? Could this be ported here somehow? (some) Groups are now possible to set up in the Web-UI, so this would reduce the likelihood of errors.
Note on sane defaults:
/api will render the api URL. (are there any installations where this is not the case?) This would simplify setup dramatically. Any user setting this up already knows their HA’s url, but this cannot be safely assumed for the API URL. (guess how I know 
)/path/to/homeassistant/www/garmin/ - that way we can safely assume it will be found in ${BASE_URL}/local/garmin/can confirm and expand.
It looks like the people at HA added a failsafe and <homeassistant>/config/www now points at <homeasistant>/www
The JSON file does not need to on the HA instance. Hence location is not assumed.
It does sound like you have contradicted yourself here. Can it be assumed and therefore enough or not?
Besides, by decomposing the URL, it is actually harder for a user to test & confirm their settings as the URL construction becomes hidden inside the app. By using the full URL the setting value can be confirmed externally and then copied & pasted knowing it is correct. I.e. this is actually simpler and more transparent.
Besides, its rather late to change. It would break the settings for existing users! So it’s not worth that in order to satisfy one new user. Sorry.
This is the working principle of the app. Keep the app simple, and put the complexity externally. Textual configurations are often sought in order to simply both configuration and making changes, e.g. changing a file name to try something new.
The app is aimed at those who are comfortable with managing an HA instance, and hence editing YAML files. YAML is 1:1 with JSON, so its an easy conversion. If this is not to your liking there are other apps! We have a user base that appreciates this method of configuration, so it’s too late to change…
I see your points. While I do believe this app would be more accessible with more assumptions on technology and fewer on people, I understand and respect your design choices.
Your work is highly appreciated!