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.
@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.
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.
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?
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)
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.
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.
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?
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.
Thank you for the great work ! It works flawlessly and instructions are very clear … got it up and running in no time. So again, a big thank you !
Submenus are very convenient, I use it to control the lights and open/close portal in my house.
I would strongly encourage implementation of sensor status (ie ext temp) and it would be perfect
We’ve discovered we are on the memory limit for some of the older devices. This means any further development risks us dropping the older devices from further developments.
The general problem with showing status information is the sheer variety that will be requested. The fear is this makes for significant additional code, or non trivial additions to YAML server side adding yet more complexity.
We already have some feint hearted app reviews saying they could not make ot work…
All in all, were nearing the end of what we can add. At what point does it become more realistic to reach for your phone?
And with Reqbin and cmd I get:
“message”: “API running.”
Everything looks fine but wehn I go to the app I get first “Desconfigurado” (not configured) and one second later “Indisponible” (not available).
If I select the app I get :
“No hay respuesta, verifique la conexion a internet.” (no response, chack internet connection)
And …
“URL no encontrada. Posible error de URL de configuracion en la configuracion” (URL not found; URL error on configuration)
Hello, please ensure you are using HTTPS as the Garmin SDK requires it. This can be setup with let’s encrypt for free (I recommend the Nginx SSL Proxy add-on for homeassistant).
.)
