Ticket Created
over 3 years ago

CIQQA-1023

Is there a bug in getStressHistory and getBodyBatteryHistory ?

I see some very strange results returned by the recently published getStressHistory function (similar with getBodyBatteryHistory). It is wrong even in simulator, but on a real device it is even worse.

sensorIter = SensorHistory.getStressHistory({ :period => 1, :order => SensorHistory.ORDER_NEWEST_FIRST});

mTime = $.sensorIter.getNewestSampleTime();
// Simulator:
// Returns current date - correct
// Real device Vivoactive 4:
// 2 possibilities: 
// 1. If iterator is empty, returns 30/12/1989 ?!
// 2. If iterator has data, returns correct date

mData = $.sensorIter.getMin();
// Simulator:
// Returns correct value (35 in my case)
// Real device Vivoactive 4:
// 2 possibilities: 
// 1. If iterator is empty, returns 127 (that is stress level 127% ?!)
// 2. If iterator has data, returns correct value

mSensorSample = sensorIter.next();
// Real device Vivoactive 4:
// Often returns NULL

if (mSensorSample != null) {
    mTime = mSensorSample.when;
    // On both, simulator and real device, returns next day but year 2002 !
    // For example, today it shows 27/3/2002 (it should be 26/3/2022)
}

Main issues:

  • On real device often returns empty iterator
  • When use next(), always returns wrong date (year 2002)
  • getMin() returs 127 (%) instead of null from empty iterator

There is a lot more weird behavior, but this is the main issue. I tried a few simulators (different watch models) - it is always the same. I have only one compatible physical watch - Vivoactive 4, and that is the result from it. Let me know if you want a sample code to try yourself.

, would you please take a look?

Thanks!

  • Like I said, the unix vs garmin time shows up at different times and in different ways.  Travis has been down that road before! Data in the sim is "canned" in that you'll always see the same even with different target devices.Here's the va4 in the sim.  bb has a current value of 35, and there are 20 sample.  I calculate my own min/max. and that's the "35 37".  "st:" is the same for stress. /resized-image/__size/320x240/__key/commentfiles/fb5d84b10a5745448a7a45dafc1faa43-f790f1f0-28a7-48a8-a031-ebd5f58757cd/pastedimage1648310111712v1.png One this to note if you've not used getXYZHistory() much is the max number of samples can vary by device, and is often tied to the screen width, as this is the same data used in the native widgets, and there's no sense having 300 samples if the widget only needs 200.
  • [quote userid="3042" url="~/developer/connect-iq/f/discussion/289677/is-there-a-bug-in-getstresshistory-and-getbodybatteryhistory/1397292#1397292"]Another trick you can use with "garmin time" that will still work with "unix time" is look ate the time stamp between two adjacent samples and get the difference - say it's 5 minutes.  So the newest sample is no more than 5 minutes old.  So 48 samples is right about 4 hours.[/quote] It doesn't work with with Stress Level - the interval there is irregular (it varies). But difference between getNewestSampleTime() and first Sample should work!
  • [quote userid="3042" url="~/developer/connect-iq/f/discussion/289677/is-there-a-bug-in-getstresshistory-and-getbodybatteryhistory/1397289#1397289"]"Garmin time"[/quote] Good to know! Strange how it shows correct time for getNewestSampleTime(), but wrong one for all data samples.
  • Another trick you can use with "garmin time" that will still work with "unix time" is look ate the time stamp between two adjacent samples and get the difference - say it's 5 minutes.  So the newest sample is no more than 5 minutes old.  So 48 samples is right about 4 hours.
  • [quote userid="160808" url="~/developer/connect-iq/f/discussion/289677/is-there-a-bug-in-getstresshistory-and-getbodybatteryhistory/1397287#1397287"]BUT, it is linked only with the period, remove period (or put it to null) and no issue anymore. so the issue is due to period if it helps (at least on my side) [/quote] Yes, that is another issue I noticed - if you put period => 1, you get empty iterator (often, not always), but for period NULL you do get data. I guess I can use that workaround for now, hopefully it doesnt use much more battery than period => 1.