Comments (12)
Additionally, it may be worth suggesting to the home-assistant project to allow polling of multiple entities in one api call?
from garminhomeassistant.
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.
from garminhomeassistant.
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.
from garminhomeassistant.
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.
from garminhomeassistant.
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.
from garminhomeassistant.
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?
from garminhomeassistant.
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?
from garminhomeassistant.
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.
from garminhomeassistant.
Created a separate issue for the partitioning of the source code.
from garminhomeassistant.
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.
from garminhomeassistant.
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.
from garminhomeassistant.
Related Issues (20)
- Help text for web-based configuration editor
- Add option for skipping url and menu screen when loading widget or application HOT 2
- Feature Request - allow installation on Garmin Edge Computers HOT 3
- Bug fixes to 2.6
- Newline character HOT 1
- Question: Internal http access not working HOT 3
- Splitting widget and app code HOT 7
- Allow turning off vibration HOT 3
- Venu 3 - application doesn't start HOT 32
- Request to add toggle functionality for covers HOT 4
- Add 4 more devices
- Cache 'has' results
- Confirm on toggle
- Examples
- Look for memory usage efficiencies HOT 4
- Confirm on type "tap" not working HOT 1
- Enhanced web editor
- Add GPS reporting to the background service HOT 2
- Copy button and fix auto complete in template
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from garminhomeassistant.