Finally, there’s an online way of testing the API URL too, thanks to REQBIN.
Just make sure you add the trailing \ to the URL for this test, and then remove it for the correct API URL on success.
There are no confirmations on toggles. I’m not sure how we would do that, perhaps using a custom menu item class, and that’s a whole load of pain given we can currently use one out of a box for the current behaviour.
Confirmations were introduced for scenes and automations.
You could separate the toggle into two items, one for ‘on’ with an optional confirmation and one for ‘off’ with an optional confirmation.
Did anyone else manage to get app working with nabu casa? I checkd URLS, json files on web, and it is working.
Yes we did. We took out a free trial of Nabu Casa solely to find out why others might be struggling. We got it working in 5 minutes. Well, that’s the good news, the bad news is we did not discover why othersa were struggling!
As per the README.md linked above
If you are struggling with getting the application to work, please consult the trouble shooting guide first.
This picture shows what we did: GarminHomeAssistant/Troubleshooting.md at b2461a09e62e6121f5ea48d32e1fb879d2d32361 · house-of-abbey/GarminHomeAssistant · GitHub
I checkd URLS, json files on web, and it is working.
It would be more helpful to know what error messages you were getting when it is not working:
- It sounds lke you have got the configuration JSON file for the menu working - but I’ll state this assumption as your post was more general.
- Did you positively confirm you had the API URL working? That requires a bit more effort, but not much.
In our experience, all the setup issues so far have been silly mistakes the eye did not catch. The only problems we’ve had to take action for are where the app failed to provide the user with a helpful error message, usually because of device specific issues we can’t test without buying every device we support. Hence we rely on the simulator (which is known to deviate from real life).
1 Like
Honestly, I don’t know what helped, but it started working.
Previously I didn’t get any error, glances only showed that API and Menu were unavailable. After entering the application, there was a black screen.
I tried checking the URL several times, both the API and the JSON file, and verified the addresses according to your guide (thanks!).
Since the last time I checked the watch, I haven’t changed anything in HA or Garmin Connect, I only see that in LOGs that HA lost connection with Nebu Casa for a moment, maybe just restarting HA would help? Now I won’t know.
I encountered similar issues as przemyslaw.leszczuk and wanted to share in case it helps others. I also use Nabu Casa for my online connections.
Initially, I had no problems after installing it on my watch (Instinct 2). However, it started randomly cutting out shortly after without any error messages. I checked my links and API access using the tools in the troubleshooting guide (thank you for those!) but couldn’t identify any issues.
Eventually, I realized it seemed to be linked to opening and closing the Garmin Connect app on my iPhone (iOS 17). Things worked fine on my watch until I opened and closed the Garmin Connect app, which is when the issues arose.
Since then, I’ve kept the Garmin Connect app open in the background on my phone, and I haven’t experienced any more problems with the HA app on my watch. I can open the Connect app and check things without disrupting the HA app on my watch, as long as I leave it open in the background.
1 Like
@a_smart_hoome thank you so much for posting this observation. As the authors have not had access to Apple products for testing we would not have had this insight.
As it stands from this report we are unable to offer a technical solution.
Now we have this lead, I’m wondering if Apple phones have settings for apps that allow background data? If so, perhaps changing such a setting would allow the Garmin Connect app to permit the watch Internet access? If not that feels like a major short coming for watch users using Bluetooth on Apple products (and does little to endear me to Apple products…). I would have expected the watch’s Bluetooth access to the phone alone to be sufficient for allowing Internet access.
Your assistance is greatly appreciated.
Wow, worked immediately. And yes, you need some tech skills to achieve this. There are some assumptions in the manual 
Have it working with my Vivoactive4 and Home Assistant Cloud URL/api.
1 Like
Hi @NP_Complete ! One question about the toggle; I have two (light) entities exposed to my Vivoactive4 and when I toggle a light to off, the toggle changes one time back to the ‘on’ state and reverts quickly to the desired off state.
Don’t know how to figure out the lag/milisec “in between change state” though.
You some thoughts?
Please can you expand on this? (Its all obvious to me as I wrote it 
.)
Thanks.
1 Like
I’m going to need a little more to go on here. I don’t get this bahviour.
Did you let the app refresh the initial states of the lights before toggling?
I think you mean, what is the periodic delay between refreshing the state of each toggle. Its a “round robin” exercise. Do one then the next and so on, start over again. The more toggles you have, the longer it takes to go round the whole lot. Each state query takes O(100) milliseconds, but that’s device dependent.
Hi!
I created a GIF to show the symptom; open here
On the gif/video you can see that the entity “Kerstboom” (a single entity switch in HA) works perfectly fine.
But the “Woonkamer” entity (a group in HA, exposed as single entity via the Helper) is the one glitching. I think its due to the processing speed of HA and Zigbee al together, because the group itself is about 14 light bulbs big.
The weird thing about this, when I toggle the ‘Woonkamer’ group in my HA dashboard, all is fine.
EDIT: nope, I was wrong, I have an complete other issue. Sorry! (see below)
That’s really useful to see.
My first impression is that the initial toggle failed, so the menu item reverted the state as if an error prevented the request getting through. But if that’s what happened, I don’t know what caused a second request to be sent and for the final success.
I also noted you had some blue screens with error messages in there. It would be useful to know what they said.
Thanks!
Ahh, interesting! I paused on a blue screen, and the following message is shown: “API-aanroepen te snel, Vertraag uw verzoeken.” In English: API calls too fast, Delay your requests. So, what can be the reason why it is sending so much requests?
That is troublesome as I thought we had cured that issue by chaining the status updated calls so the next is invoked by the previous (as opposed to choosing a delay that only works for new watches and not old ones). But clearly there is insufficient time between status update checks to insert a change request.
Is that a Vivoactive 3 watch by any chance?
This is a Vivoactive 4. Maybe this model (end 2019) is still on a old platform and the Vivoactive 5 (end 2023) is upgraded to the new software platform/api.
(like the Venu3)
I’m just testing a new version, probably the last with new features, which should reduce the memory demand and keep it working on Vivoactive3 devices (hopefully). If that new version (2.1) still has the same problem I’ll look at a specific fix.
Just a thought, if you slow down the toggle button requests, do you get the same behaaviour?
Yes, the same issue if I open the application, wait for a couple of secs, press once at the ‘‘woonkamer’’ and do nothing else.
Hmm, something else, maybe related. I mentioned earlier that the same entity in HA is working (toggle for ‘Woonkamer’ lights: on/off), but acting weird when I use the toggle in my Vivoactive4 application.
I have to explain what is weird then. Of the 14 light bulbs (all HUE/Philips/Signify) are 13 normal bulbs in a socket, and one HUE Bloom (more like a light appliance thing), that Bloom never shuts off when I use the application. More strange, something is flooding my network, because when I wait after the toggle, the Bloom never shuts off but my other lamps are almost in disco mode! And I cannot use the HA toggle until I reboot the Bloom (remove adapter from socket), and I have to do the reboot, because HA does not sending commands anymore on the zigbee network (or something is waiting in HA).
The logs are not clear about that.
EDIT: got it! Well, I found a problem, and it is not related to the Garmin Application.
When a device in a group is not responding, the toggle keeps on the current state eventually, because not all devices in the group responded with some sort of OK back to HA.
There’s some kind of “Group Options” → “All Entities” buried in the GUI somewhere under Helpers. (YAML equivalent escapes me.) That option determines if an entity is “on” when one or all lights in the group are on.