Connect IQ App Battery Issues

Former Member over 8 years ago

So I got my app finished(functioning the way I want, at least), with a bit of a problem. It uses up more battery than I'd like...A little over 1% an hour, I think? While it's running, anyway. Which wouldn't be a problem if the main purpose/idea was to have it running the majority of the time. At any rate, I wanted to ask if anyone had any pointers/tips to reduce battery usage/what uses battery up the most in CIQ apps/etc.

To give a brief overview of what the app does...It's essentially a "watch-face"-app(It's a CIQ-app, not a watchface, just essentially acts like one), that does some things in the background. So essentially, it has a timer that ticks a function every minute(60000 milliseconds). This function, every minute, uses the Sensor(with permission), to get the current heart rate/bpm, and increments a counter if it's not null. Every time the counter ticks to 30, it stores the average in an array using setProperty(...). There are 7 of these arrays, 1 for each day of the week, and another 7 for the timestamps for those heart rates.

I was thinking it wouldn't drain very much battery since the "bulk" of the work only happens once every 30 minutes, but it seems I'm mistaken. Do set/get properties really take up that much battery? Is it because I'm using the Sensor permission? Not really sure what takes battery in CIQ apps. I can elaborate more on what the app does, if needed, but any general advice would be appreciated.

Thanks

jim_m_58 over 8 years ago

Assuming you are on a device with WHR, and you are using setEnabledSensors() for SENSOR_HEARTRATE, that takes the WHR out of 24/7 mode and puts it into real time. That alone will burn more battery. Also, if you use enableSensorEvents(), that will be called every second. (this shouldn't burn much battery, as you probably do do much there)

If you are storing the arrays in the object store (the same call is used with app settings, but not the same thing), those arrays are actually only written to mass storage space when the app exits. (it's in the .str file for your app)

If you are using something you can see with app settings, you're writing to mass space every time you change them. (it's in the .set file for your app)

(if you're not sure, you can hex dump the file and see what is where...)

Former Member over 8 years ago

Could you elaborate a bit more on what setEnabledSensors() for SENSOR_HEARTRATE does, exactly? Like the difference between 24/7 mode and real-time. I remember putting that in the code while testing some stuff looking at the Sensor sample app, and I forgot to remove it. I'm not using enabledSensorEvents. I'm only getting the heartrate/bpm using Snsr.getInfo().heartRate, once every minute, so I don't need real time/second-by-second heartrate. I removed setEnabledSensors( [Snsr.SENSOR_HEARTRATE]) for now since it seemed to get the heart-rate just fine without it, but I'll need to wait a bit to see if it reduces the battery drain by a noticeable amount.

jim_m_58 over 8 years ago

First, make sure you look at the API guide in the SDK.

if you are using Snsr.getInfo().heartRate, you need to have it,. It's how you "turn on" the HRM, so there will be a value. (real time mode - every second)

you can get the HR history (WHR only) using getHeartRateHistory (In ActivityMonitor or SensoryHistory), which is the 24/7 readings, and every couple minutes apart without enabling sensors, but if you want to grab a current reading whenever, (with Snsr.getInfo().heartRate), you need to enable the Sensor.

Former Member over 8 years ago

I guess that was a bit hasty, I did remove it and it still did record heart rate, but the battery drain was still the same..so I guess it's turned on automatically if I try to use getInfo().heartRate or something. Thanks for giving me the idea of using the history though, I think I'll just ditch using Sensor in favor of using History, which might not be their exact HR at that moment it's gotten, but the closest one should be sufficient, since it seems to be more or less per minute from what I can tell, but either way it should be fine since the battery drain is a much bigger concern.

OttawaDeveloper over 8 years ago

related question: for the GPS there is a warm up time for the sensor to start working. Is there any warm up time for the HR sensor?, especially if it was not used for some hours before. That is might there be a delay of about 60 sec before the sensor starts giving data in var sensorInfo = Sensor.getInfo(); var heartRate = sensorInfo.heartRate;

I did call setEnabledSensors( [Snsr.SENSOR_HEARTRATE] ); prior during app.initialize to start sensors.

jim_m_58 over 8 years ago

With GPS, there will be a time to get a fix. With HR, it can kind of depend a bit, based on the watch, if you're using WHR or a external, etc, as far as long long it takes to "get going"...

You also may want to look into using enableSensorEvents() so you'll not have to look for Sensor.getInfo() yourself. The callback will be done when there's data for your app and you'll not need to look.

OttawaDeveloper over 8 years ago

thanks Jim.
Someone is having this issue testing my app on VivoActive HR, built in wrist sensor.
I had called setEnabledSensors, but not enableSensorEvents. I can try that.
Based on the docs i figured that setEnabledSensors, with me polling on a timed loop would work.

But then enableSensorEvents allows you to pass null for callback. If you have no callback(listener), what does that function do? or is it also needed to get the sensor running?

Might redo with callback as you suggested - but a bit puzzled by enableSensorEvents anyhow.

jim_m_58 over 8 years ago

if you want to see it works and time and you have a va-hr, install my Hike2 app (store link in my sig). Start the app, and you'll see the HR on the bottom line really quick.... The Tempe may still take a minute or two :)

I use a callback function in this one, that can grab the data the app needs when it's available...

enableSensorEvents with a null function is how you turn it off... You no longer want the callback.

Brandon.ConnectIQ over 8 years ago

The other thing to consider is that an app updates the screen once per second, like a watch face in high power mode. That's going to drain a lot of battery power, too, which is why we have limited watch faces to once-per-minute updates in the past, and have only recently introduced 1Hz updates.