Reset glance view battery predictions if charge is detected

[niodice]

The glance view data becomes much less usable after the device is charged. For example, I have my glance views set to 60min and 12h. After a charge, both glance views have inaccurate data until 60min or 12h have passed, at which point they start to produce accurate battery metrics.

Would it be possible in this function - https://github.com/individual-it/BatteryGuesstimate/blob/master/app/source/BatteryGuesstimateApp.mc#L84-L111 - to implement the logic to keep track of when the last charge event was? It would be great if the glance data only gave information based on battery drain, not battery drain and charge

A few ideas of how to implement:

• if lastReading < currentReading, clear all readings, reset circularBufferPosition to 0
• you could consider keeping track of the last reading for which a charge was detected, and then base the calculations off of the data between the last charge position and the circularBufferPosition

[individual-it]

The issue with tracking when the last charge event was is, that this event might not be from charging with the charger, but also from charging by solar. People seem to like to see the detail that shows they gained some charge from solar. Also resetting all readings would render the graph useless.

If I understand you correctly the calculation you would like to see is basically what the graph view shows: https://github.com/individual-it/BatteryGuesstimate#2-graph-view Is that right?

[niodice]

Yeah, that's essentially the data that feels most relevant to have on the glance view itself. I'm guessing that the reason it's only available as you dig "deeper" into the app menus is because it takes more cycles/power/energy to compute it?

Interesting note about the solar charging, I had not considered that.

---

Some random thoughts... Do you have any idea if the documentation for this field is correct?

# https://developer.garmin.com/connect-iq/api-docs/Toybox/System/Stats.html#charging-var
Battery charging indicator. This will be set to true if the device is connected to the charging cradle or cable whether or not the device is fully charged.

I wonder if it'd be possible to, instead of comparing battery percentages, check the charging field. Though, what happens if I only charge for 10 minutes? From what I can tell, there is no event to which you could listen to exactly know when charging starts/ends.

---

I do see some of the complexity around this. Question to you -- do you feel like having the graph-view calculation on the glance is helpful or perhaps ideal, or do you find value based on having the two different methods of calculation?

[individual-it]

I'm waking up the code every 15min (min would be 5min) and checking the percentage of the battery. It would be possible to check the charging var at the same time and do some calculation based on that. But you are right, there is no event. The only events are those: https://developer.garmin.com/connect-iq/core-topics/backgrounding/

If you want to have the same calculation in the glance as in the graph, that could be done easily, but it would take much longer to calculate as its reading a lot of data from memory and that is pretty slow (at least on my Instinct2). But that could be hidden away behind a config switch.

[niodice]

Assuming that that would be slow or energy intensive, I'd probably opt to keep what you have already implemented. I suppose storing the battery readings together in one array might help with performance.

Anyways, I'll leave it up to you whether or not to do anything with this. I thought that it might be simple to implement but the more I read up on it, I'm not so sure :)

[individual-it]

Storing multiple reading in a single array would have various advantages:

• speed of calculating/drawing the graph (it looks to me that the slow part is the reading and not the calculation)
• longer time frames could be stored (with storing data every 15min for 14 days I'm about the exhaust the available memory. I already had to shorten the names of the values: #5)

The disadvantage would be more "work" every 15min. Data would have to be read from the storage, processed and written back. Currently I only have to get the battery value and write it to storage.

So the question here is: what is worse/better from battery consumption?

1. short simple task every 15min & long processing every time the user checks the detailed values
2. more complex task every 15min & faster processing when the user checks the values

I don't know how to find out, how much worse the first option would be in terms of battery consumption