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!
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:
I do agree with an above comment that the base url should be enough and the app can assume that adding /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 )
I’d even be tempted to suggest asking just for the name of the json file, and to document that this file is to be placed in /path/to/homeassistant/www/garmin/ - that way we can safely assume it will be found in ${BASE_URL}/local/garmin/
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.
)