Possiblity to add polling interval for states to save battery

[house-of-abbey]

Possiblity to add polling interval for states to save battery

[WebSpider]

Additionally, it may be worth suggesting to the home-assistant project to allow polling of multiple entities in one api call?

[philipabbey]

Good news, there is a convenient way to make a round of updates before a single longer pause. This will be the final implementation now being worked up.

[philipabbey]

The polling is necessary and only occurs when the application is open. It therefore does not occur in the background and use battery unnecessarily, only when necessary. Therefore there is nothing we can nor should change here.

Therefore:

Would it be possible to add an option to change this, for the case of battery efficeny?
No. The app would not be responsive to changes when open and would not save any more battery on quitting.

I've seen a drop in battery time on my Fenix 7X since installing the app, and i guess it's because of this, but this is all just assumptions, and the app may work a whole other way.

Are you using the background service to report battery level? You can already adjust this interval in the settings.

My watch battery on a Venu2 has not got worse since using the app (actually 2 apps, the beta channel you can't see and the released are both installed).

You should be able to verify the watch app's interactions with your Home Assistant via the logs and see if the App is doing too much work.

You can also set the app to close after a timeout of inactivity via the settings, i.e. make sure you don't leave it running in the foreground and consuming battery life. Presently this problem appears to be localised to you, so I am going to assume you have some settings to optimise for now.

[erlendsellie]

I see that i may have been a bit vague in my description here. Sorry about that.

By "continuously" i meant when the app is open. As you point out, polling is done when the app is opened. I like having this app open pretty much all the time when i am at home, and then i suppose there is done a lot of polling, unnecessary (for my use case, as i mainly just execute scripts and such).

I was trying to propose a feature like a battery saver option for when the app is left open, which would not poll Home Assistant as often.

The app is really responsive and good as-is, but like i said, it can take a toll on the battery life if left open.
You have made great settings to avoid this like inactivty timeout, but my feature request would be this battery saver option, which would decrease polling and batch polling to when the app is interacted with like a button is clicked or something.
I understand that this would make the app seem less responsive, but for some users it's maybe not that important to know if a light is on or off at the moment.

Again, sorry for not being clear when first submitting the issue. If this feature request is off the table, that is completely okay, but there is no shame in raising it.

Thanks again for a great app. I've been through several before i found this, which is by far the best, and in active development.

[philipabbey]

Thank you for this explanation, I understand your use case better.

The thinking here is that the watch application will only ever be open briefly not persistently

So this is a deviation from the original planning assumptions. It is worth noting that each menu item has to be updated with a separate API call. There is no batch update option. The obvious solution to slowing down the individual polls is to add a delay between each item being updated. However, when the application first opens, there must be an entire round of updates, and it would be bad to have that round slowed down. We do have a counter iterating through the list of updatable menu items, so we would know that the first round has been completed. Then we would need to enable a timer to add delay between each of the next updates. The timer calls a 'callback function' to take action, so that means inserting a timer where the calls are currently chained, but only if we've done the first round of status updates. There's also a low limit on the number of timers available on some devices we support adding a possible application failure mechanism. We are also trying to limit code changes presently as older devices using the widget version of the application are running out of memory, and more code means a reduced menu definition.

So the request sounds possible, but carries some risks for less capable devices.

[philipabbey]

One option we have here is to drop further development of the widget version and free us to add new features to the application version. This is because it's the widget version that is currently constraining us via memory usage.

For this feature, a "persistent mode", the widget can't use it as it naturally exits after a set period anyway.

@Someone0nEarth any comment?

[Someone0nEarth]

One option we have here is to drop further development of the widget version and free us to add new features to the application version. This is because it's the widget version that is currently constraining us via memory usage.

For this feature, a "persistent mode", the widget can't use it as it naturally exits after a set period anyway.

@Someone0nEarth any comment?

I would suggest to clone the repo for the widget version and set the clone to a maintenance only mode (only bug fixing, no more features etc.). We could even then remove the glance code etc. from this repo. And than we remove the widget code from the app-repo. And removing the dual build solution.

People on older devices should be still able to run the app version, if they want the new features. And people on newer devices still can use the app version starting from the glance, if they want to have a "widget behavior".

What do you think?

[philipabbey]

I too considered this path forwards, so I agree with you. This means either partitioning the source code within the current repo or a new Github repo, and significant effort to split the code, amend and re-verify, so all in all a fair bit of work.

[Someone0nEarth]

Created a separate issue for the partitioning of the source code.

[philipabbey]

Additionally, it may be worth suggesting to the home-assistant project to allow polling of multiple entities in one api call?

That's a kind offer! Thanks, but you might find your idea has tough competition in the current the backlog. Let us know if you get anywhere with it and we'll try to find some time to change the operation of the GarminHomeAssistant app.

[philipabbey]

I think the only convenient way to reduce the polling rate is to add time between each item's update. This is due to the way in which the timers are asynchronous, so I can't just "sleep 10" on wrapping from the end of one round of checks to the start of the next round.