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!

  • The 127 seems to indicate an invalid body battery sample, and I've also seen -1 for the same with stress.  Both seem to have a good/reasonable value if the watch is worn for a few minutes and a newer sample is taken.  This could just be a case where "invalid value" needs to be documented - say of you take off the watch for a time. 127 is the max for a signed 8 bit value The 2002 vs 2022 sounds like an issue that has haunted CIQ for many years and gets corrected quickly. You can use a hack to correct it today. What's commonly called "unix time", is the number of seconds since 00:00 UTC Jan 1, 1970 and CIQ uses that.  Well, Garmin wasn't around in 1970, so internally, they track time as the number of seconds since 00:00 UTC, Jan 1, 1990 - "Garmin time".  So to correct for this until it's fixed, you add 20 years worth of seconds.  I know  remembers this one!  That's why you see Dec 30,1989 - when adjusting for time zone, the value in "garmin time" is 0.
  • hi, I noticed this issue also using the same code as here: developer.garmin.com/.../SensorHistory.html 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)