You have to publish your JSON menu file on a webserver (that you control) so that the watch can request it. Therefore you are also in control of what the URL is that has to be entered in the settings. Because everyone’s circumstances are a little bit different, this can’t be prescribed for you. However, you can get some ideas from the Trouble shooting guide.
I appreciate some users will try this app without developer skills, but it is aimed at those familiar with setting up a Home Assistant with all its YAML files. So this could be a tough gig then!
BTW I don’t like the look of your URL it does not start with “https://” and includes the port “:8123” which is just not going to work with Garmin’s SDK which enforced HTTPS. That’s something beyond my control and cannot be fixed (easily). Please see the troubleshooting guide for how to check your setup. If that is not understandable, then you might need to consider using a different HA watch app, sorry.
This is using deprecated functionality that has yet to be retired and will form the basis for re-instantiating the functionality of a new “info” menu item type.
This app continues to be my number 1 go to on daily basis. I think this app is the reason why I stay with garmin as having HA provides all the “smart” behavior I need in a watch while keeping great battery life and great sport stats.
Thanks again to the devs! Please, do not drop this project.
“Starting in February 2024, developers submitting apps for the first time who want to have their apps visible in the European Economic Area will need to verify their identity with Garmin.”
Obviously we now know this does not just apply to “submitting apps for the first time”, but for existing apps too. I’ve done the registration form Connect IQ | Developer Registration | Garmin. Not sure how long this will take. So we’re waiting for them… I only found out after submitting the update.
I feel rather stuffed by Garmin. They could have given me advance notice so that I could have been prepared in advance of the update. I do not have time to monitor Garmin announcements and would not have known where to look. Garmin made no effort to contact me about this change affecting my application, not even with an automated email. Some of us developers do it for fun in our “spare time”, for no money and solely to be helpful to the community so should not be expected to have picked up on this change through osmosis.
I’m really sorry that some users have been denied access, but hopefully only briefly. It is out of my hands for now. Perhaps it is reassuring that so many have contacted me, but I fear the annoyance may put people off using it (Garmin that’s on you…)
Thank you all for reporting this as I now know I have been adversely affected.
Thanks,
I’ve managed to install HA to my wife venu2s with this.
@NP_Complete I’ve one coment though…either on my venu 2plus or her venu2s, I feel that the app is slower than before…in terms of loading the entities and much more slower to refresh the state of the toggle when pressed in the watch. Why is it?
I share your observation. The app used to update one item at a time, so the status updates would trickle in. Now we group them altogether in a single large request for efficiency. It means they all get updated at the same time, but in one go. So we hope it is quicker to complete all the updates, but the first few would appear to be delayed.
This change was made around the time we added templates to every menu item, and the trickle of updates was taking a while.
@NP_Complete So you mean everytime you click on a toggle, it is updating of all of them at once and that’s is why the status delays to be refreshed?
In any case, ux was way better before. You know I believe the watch is to have the main ítems the more you use so…not sure optimization is that important for a few elements?
I am saying that without knowing at all how the app works so please don’t take it bad.
The use of templates for all menu items, including groups, significantly increased the number of status updates, and slowed the responsiveness or update rate.
The change also simplified the need for a “round robin” approach, taking each menu item in turn and requesting a status update. If we did not manage the rate and timing of each update we ended up with communications stack overflows. After all its only a watch with limited working memory, not a PC with GB. So the communications class API was not setup for what we threw at it.
Its not impossible to revise the decision, but a significant coding change with some issues to mitigate. I would expect the response time to improve with fewer menu items.
To be honest… Personally I am not happy with the experience anymore when this app is the one that made me keep Garmin for the last years…
It is just not confortable to use it as this… I checked my parameters but they are default… “0” for the delay. If you have any recommendations to improve behavior let me know… or maybe you can publish a “lite” version of the app (“previous version like”) for the ones that do not want fancy features but responsiveness?
Anyway, thanks for the follow-up and your response, appreciated.
No, my Venu2 is not that slow. I initially agreed with you because I think there is a slight difference in response, not a major difference as in your video. The app is not responsible for the round trip delay from watch to phone to Home Assistant and back. Maybe spend some time figuring out if that round trip time can be improved?
Okay, you have choices here. But firstly I’m not taking responsibility for your decision to keep a Garmin watch. The software is offered “as-is”. If you don’t like it, don’t use it. Its not like you paid for it! So on this subject please be respectful of the following:
I have a day job, its not as a software developer. I just do this as a hobby.
That means I do it in my “spare time”, when I should probably be doing more domestic chores or spending time with my family.
You paid £0.00, so you get a full money back guarantee. You can have your £0.00 back.
Or maybe not, sorry. As I’ve explained above, I don’t have time to maintain multiple versions of the app under different branches of the source code. We have offered the app we want to use to the community in case others value it too. We have included ideas from others to enhance it, which is how we got to this point. We have gratefully accepted code offered by others via pull requests on GitHub. So this leads me to the following suggestions you might like to consider:
Raise an issue on the Github respository. It may attract others to comment either in favour or cautioning against. It may attract other developers who think they can solve the problem and are motivated to contribute to help out.
Install the Connect IQ SDK locally on your PC and build the historic version you prefer. Then you can control which point in the development history you want to choose and you can load that on your watch. This is what I do for pre-release testing using a different application ID. Check the version history and try building a previous release from the version tag.
Swap to using the Widget version which is more limited due to the constraints imposed by older devices, but may offer you increase responsiveness.
Issue a pull request for a new version where you have coded a solution to the more responsive UI problem and we’ll take a closer look on a local test. If it represents an improvement we’ll be happy to credit you for your efforts.
Right now, I’m spending too much effort (more time than I can really offer) fielding user concerns about regional availability, and trying to figure out how to get Garmin’s support. It is not a problem of my making but I have to deal with the consequences all the same. Something of a shock that I did not appreciate from Garmin. So there is even less effort (read negative time) available for development.
I hope one of these options is acceptable to you. Sorry there is no paid support option for this software.
@NP_Complete
Now I feel you took my comment in the wrong way…
I really appreciate your job and efforts for the community and I was meaning to say that your app combined with garmin was one of the main reasons for me to keep garmin because the only “smart feature” I need is the HA.
When I use my HA through browser or mobile app I have absolutely no round trip delay… but this behavior is there when using either venu 2 or venu 2 plus peered with android and/or iphone… not sure what to check then…
That being said, thanks for pointing me to the direction of the SDK. I didn’t know I could do that… I’ll investigate how to install the SDK and how to push a specific app to the device to run an older version of the app and see if this improve things.
Again, sorry for the misunderstanding, I’ll try to investigate on my own from now on and certainly try to get github support as suggested.
Bluetooth connection, distance between watch and phone? I do find the responsiveness varies. Sometimes quick, sometimes slower. I have not identified the factor that causes the difference.
No, it must be something different… phone is close to phone.
Where can I find the versions of the app in github? I have tried to look for them but not sure how to identify them…then another challenge will be to push it to the watch, no idea
yes, there’s a table with versions number and description but apparently no “package” I can download for specific version right?
Probably some concepts missing for me and need to understand the project code structure. Maybe common folders for all version except some of them…? I need to investigate this… I am not familiar with it. How to download specific version and how to push it to the watch.
