#1846 Add Fossil HR Activity Tracking

Merged
ashimokawa merged 16 commits from fossil-q-hr-activity into master 5 months ago
dakhnod commented 5 months ago
There is no content yet.
ashimokawa commented 5 months ago
Owner

@dakhnod

Very cool!

A few remarks and questions:

  • Can can remove the intensity field if you are sure it wont be used, I know you used the common method to add it. But you could also just copy out the useful bits for the Hybrid HR if it really does not support “intensity”.
  • What is variability?
  • It might be better and faster to do a “batch-insert” of samples instead of putting every sample in the database one-by-one.

Anyway, thanks for this great PR!

@dakhnod Very cool! A few remarks and questions: * Can can remove the intensity field if you are sure it wont be used, I know you used the common method to add it. But you could also just copy out the useful bits for the Hybrid HR if it _really_ does not support "intensity". * What is variability? * It might be better and faster to do a "batch-insert" of samples instead of putting every sample in the database one-by-one. Anyway, thanks for this great PR!
ashimokawa commented 5 months ago
Owner

A few more thoughts:

  • Should merge isActive and wearingState
  • shall we map calories to intensity so that it is visible in the charts?
  • What is the deal with maxVariability

It would be wise to properly decide before we merge just because of the fact that that sqlite sucks at redefining a schema (it would be easy with a full blown mariadb or similar)

https://www.sqlitetutorial.net/sqlite-alter-table/

Also if we use the watch for years database grows bigger and bigger, so saving a column, like saying the raw intensity are the calories, might make sense, but since you saw the raw data from the watch, I think you know much better.

A few more thoughts: * Should merge isActive and wearingState * shall we map calories to intensity so that it is visible in the charts? * What is the deal with maxVariability It would be wise to properly decide before we merge just because of the fact that that sqlite sucks at redefining a schema (it would be easy with a full blown mariadb or similar) https://www.sqlitetutorial.net/sqlite-alter-table/ Also if we use the watch for years database grows bigger and bigger, so saving a column, like saying the raw intensity *are* the calories, *might* make sense, but since you saw the raw data from the watch, I think you know much better.
dakhnod commented 5 months ago
Poster

@ashimokawa

  • https://www.firstbeat.com/en/blog/what-is-heart-rate-variability-hrv/
  • i don’t really know how to normalize calories...maybe do a max of the last N samples
  • yeah, i’ll do the batch insert
  • wearingState and isActive are not always the same..TBH i didn’t inspect the behaviour of isActive too much, mut it seems to have its own logic
  • not sure if we should map calories or steps, but sounds like an idea
@ashimokawa * https://www.firstbeat.com/en/blog/what-is-heart-rate-variability-hrv/ * i don't really know how to normalize calories...maybe do a max of the last N samples * yeah, i'll do the batch insert * wearingState and isActive are not always the same..TBH i didn't inspect the behaviour of isActive too much, mut it seems to have its own logic * not sure if we should map calories or steps, but sounds like an idea
ashimokawa commented 5 months ago
Owner

@dakhnod

I see, thank you for the explaination

not sure if we should map calories or steps, but sounds like an idea

Probably we should map calories, but then again it would feel a bit odd to write it to the intensity column. Interpreting it at runtime would need an extra hack because right now normalizeIntensity() only takes the raw intensity as input. There are ways to do this as we did with Huami, but that is also not nice... hmm...

Another thing:

How about putting “isActive” and “wearingState” into one column, then we can do

    @NonNull
    @Override
    protected Property getRawKindSampleProperty() {
        return HybridHRActivitySampleDao.Properties.RawKind;
    }
    
    
    @Override
    public int normalizeType(int rawType) {
        // map at least what we know to NON_WORN etc, no sleep I guess
    }

Kind vs Type sucks, it is the same actually btw

@dakhnod I see, thank you for the explaination > not sure if we should map calories or steps, but sounds like an idea Probably we should map calories, but then again it would feel a bit odd to write it to the intensity column. Interpreting it at runtime would need an extra hack because right now normalizeIntensity() only takes the raw intensity as input. There are ways to do this as we did with Huami, but that is also not nice... hmm... Another thing: How about putting "isActive" and "wearingState" into one column, then we can do ``` @NonNull @Override protected Property getRawKindSampleProperty() { return HybridHRActivitySampleDao.Properties.RawKind; } @Override public int normalizeType(int rawType) { // map at least what we know to NON_WORN etc, no sleep I guess } ``` Kind vs Type sucks, it is the same actually btw
ashimokawa commented 5 months ago
Owner

Another thing to add to the new device tutorial:

If fields are gererated on the fly, the hack I meant was this:

PebbleMisfitActivitySample.java

and the code in

AbstractPebbleMisfitActivitySample.java

you can see how this can be done
In the same fashion we could generate the intensity on a combination of whatever. But then we should not have the intensity column at all.

In GBDaoGenerator.java you see

addCommonActivitySampleProperties(“AbstractPebbleMorpheuzActivitySample”, activitySample, user, device);

This causes PebbleMisfitActivitySample to be derrived from AbstractPebbleMisfitActivitySample, which contains the on-the-fly calculation.

Yes I really need to work on documentation, that code is probably 4 years old or more.

Another thing to add to the new device tutorial: If fields are gererated on the fly, the hack I meant was this: PebbleMisfitActivitySample.java and the code in AbstractPebbleMisfitActivitySample.java you can see how this can be done In the same fashion we could generate the intensity on a combination of whatever. But then we should not have the intensity column at all. In GBDaoGenerator.java you see addCommonActivitySampleProperties("AbstractPebbleMorpheuzActivitySample", activitySample, user, device); This causes PebbleMisfitActivitySample to be derrived from AbstractPebbleMisfitActivitySample, which contains the on-the-fly calculation. Yes I really need to work on documentation, that code is probably 4 years old or more.
dakhnod commented 5 months ago
Poster

i dont really see how we would benefit from putting isActive and wearingState in one column since those fields often differ and somehow display different data

i dont really see how we would benefit from putting isActive and wearingState in one column since those fields often differ and somehow display different data
ashimokawa commented 5 months ago
Owner

@dakhnod
The idea was to acces both values in normalizeType() without the way I described my in my post above.

isActive is probably “is running/exercising”, like the “active minutes” displayed as widget? So if you sum up all isActive minutes we will get the same value as on the watch?

@dakhnod The idea was to acces both values in normalizeType() without the way I described my in my post above. isActive is probably "is running/exercising", like the "active minutes" displayed as widget? So if you sum up all isActive minutes we will get the same value as on the watch?
dakhnod commented 5 months ago
Poster

@ashimokawa how exactly would you put two different value in one column? split them into bits?

@ashimokawa how exactly would you put two different value in one column? split them into bits?
ashimokawa closed this pull request 5 months ago
ashimokawa deleted branch fossil-q-hr-activity 5 months ago
The pull request has been merged as 11d1fd08bd.
Sign in to join this conversation.
No reviewers
No Milestone
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This pull request currently doesn't have any dependencies.

Loading…
There is no content yet.