Question to the history iterator

With the period value in the calls, you can specify either a number of samples or a duration.

OK, got it. Cool. Is there a way to find out the maximum period of the iterator?

Hm, I can't manage to get a four hours heartrate period. I tried:

return Shi.getHeartRateHistory({:order=>Shi.ORDER_NEWEST_FIRST, :period=>fourHours});

where fourHours is:
fourHours = new Time.Duration(14400);

The error message is:
Unhandled Exception
UnexpectedTypeException: Expected an object of type Time.Duration
native function

What am I doing wrong here? Any ideas? Thanks again for your help.

I am pretty sure now that giving a duration doesn't work which means it's a Garmin bug since the example from the API's documentation doesn't work also.

Can anyone confirm or is there a workaround for this?

same.. i've add .value() at and, to start,

fourHours = new Time.Duration(14400).value();

but looks like duration sence lost after that...

Same, but for pressure, when try to shift iteration through "when", "data" remain same...

an idea for timespan, if to iterate through "when" and compare preset moment with last in iter?

var momentNow = Time.Moment(Time.now().value());


var timeSpan = 0;

while(sensorIter.next().when){
timeSpan = momentNow - sensorIter.next().when.value(); // not remember if value() needed here
}
System.println(timeSpan);


Also now playing with watch face. Trying to make bar-diagram for pressure. To show 24 bars with pressure level with 1hr iteratiion...

ok, a few things about SensorHistory, that may not be obvious! First of all, it comes from the firmware, and the FW saves it for the native widgets.
(this is a general post and could vary by device)

With those widgets, the number of samples saved, is actually based on the width of the screen (no sense storing more if the native widget can display can't do more)

The duration is fixed, like 4hrs of HR data, (some devices allow more for other histories)

But using the va-hr as an example, it's 148 pixels wide(its not round or semi-round so no adjustment for that), and needs to display 4hrs of HR data. With math, that means one sample is saved about every 95 seconds ( 4x3600/148). I confirmed that a while back by using the difference between "when" for samples. And also, there are only 148 samples on the va-hr.

What this means, is you might not have samples for a time in the past, so no 24 HR history on the va-hr for example.

"when" is also a bit tricky (or it was in the past - I've not checked), in that it's in "Garmin Time", vs the "Unix time" used in most things. Basically, Jan 1 1970 is "0" for unix time, and Jan 1,1990" is "0" for Garmin time, and there is a 20 year difference if you display it, or try to compare the 2. But if you compare two "when.value()" numbers, you get the seconds between them.

Same found yestarday...
for 5x, for pressure it geaves 4hr history with step 72 sec on simulator. On watch it's less then 4 hrs for abt 10-15 min...
One more "nice' surprise from garmin...
Native widget geaves history for 6, 12, 24 or 48hrs, depends from barometr setting. So for develiper those setting useles... 4hr maximum...
Looks like remain only one solution - to store data manualy for each hour on reseive, or be happy with 4hr history (for pressure observation - useles period... to keep eye on weather need atleast 12hrs data). Same, manual calculation for max/min settings needed, api - useless for this case..

I wasn't sure if on watches like the f5 if it would return 4hr regardless of the setting, or if it would return whatever is used for the native widget, but sounds like it's always 4hrs based on your test.

One thing to keep in mind about trying to save your own 24hr's worth, is your watch face might not even run during a 4hr span (if you are recording an all day hike or something)

You could have a background temporal event, where every 5 or more minutes, it grabs the current value and queues it for return for the watch face (you can't save to the ObjectStore in the background). And when the WF runs it adds that queued data to what it knows. This however, isn't foolproof either, as the background might not run for a period of time due to being preempted for lack of available memory (and it will only run if you're WF is the active WF)

In simulator it geaves 4 hr history - tested and checked. On 5x - less (have to check with yours formula).

var i =0;
var FirstMoment = sensoriter.next().when;
var LastMoment = null;
while(true){
if(sensoriter.next()!=null){
LastMoment =sensoriter.next.when;
i++;
}
else{break;}
}
var timeDiff = FirstMoment.value() - LastMoment.value();
var iterStep = timeDiff / i;
Sys.println(i+" "+iterStep+" "+temeDiff);

geaves 199, 72 and 14328 (+ one iteration on var, will have 200, 72 and 14400

With 24hr, i'm going to try following:
make arey for 24 cells
By chech if present moment = round hour, if yes - get pressure and write it to arey, before writing, move all arey items to step back.
Found min and max values in arey
Draw diagram

Ofcourse it will work only if watchface is in use, and it will need 24 hr for first filling of arey.
But for the moment i do not see beter option, until garmin will provide acces to pressure history used by native pressure widget...

P.S. You are right... Without background - no chance....
Need to make those areys at background with storing reseived data to file, so that WF can read it when active...
Gm.... Not so good...