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!

Parents
  • 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.
Comment
  • 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.
Children
No Data