Acknowledged

:nativeNum field is ignored by Garmin Connect so accessories can't be integrated properly

Currently, when writing fields to FIT data that correspond to native fields, with the :nativeNum field populated, they are shown in Garmin Connect as ConnectIQ fields.

Why is this a problem?

Whilst Garmin's support of hardware accessories is pretty comprehensive, there will always be gaps.  For fitness equipment, for example, indoor bike trainers are supported, but treadmills are not.  Devices lke the NPE Runn implement ANT+ FE-C, which the latest Garmin watches claim to support, but they don't support FE-C Treadmill devices, so incline and elevation are not incorporated into workouts.  When developers implement apps or data fields to read the FE-C Treadmill data and store it in FIT contributions, these data can only ever show up as Connect IQ fields, which Garmin Connect doesn't do anything with.

As such, elevation gained on a treadmill does not count towards the 4-week elevation gain used to calculate Hill Score.  This is particularly important in the winter!

What should the solution look like?

When FitContributor data are provided with the :nativeNum field populated, the data should be stored in the correct native field.  Garmin should provide a list of supported native fields that will be correctly incorporated into workouts, and details of how each data field contributes to each activity.

  • Thanks for the reply. I think including the data in related totals is the value-adding part here, and would reduce customer confusion - as a customer, I was certainly confused as to why the elevation on my treadmill runs didn’t count! So it would satisfy my need if you went for this solution.

    You’ll know the underlying data model better than I do so you’ll know whether this is feasible, but maybe an alternative would be to import data into native fields but indicate when native data has been provided by ConnectIQ apps by including the IQ logo next to the field? That’s probably a bigger effort though. Maybe in addition to the “fitContributor” permission you could add an extra permission for native field contributions, which would enable more thorough reviews of apps wanting to contribute native fields. I’ll stop now as that’s probably enough scope creep for one day. ;)

  • > It doesn’t have to be full support of every field

    I thought some fields were actually supported? Or did I hallucinate that

  • This behavior is by design, like has already been mentioned. The decision was made to not allow Connect IQ apps to override "native" activity data to avoid customer confusion. I understand and generally agree with your argument here, and the same argument has been made before in the past, but I don't anticipate this changing unless we can come up with another solution. Just off the top of my head, maybe Garmin Connect could handle :nativeNum intelligently by keeping the CIQ field data graphed separately but including the data in related totals (e.g. elevation gain you mention in your example).

    I'll pass this along to see whether it's something that can be revisited for future enhancement.

  • I know Garmin won’t let you do it right now. I’m asking for a change to that as I consider it a bug: the harm done by not supporting :nativeNum is greater than the potential harm done from apps that let you fake data.

    It doesn’t have to be full support of every field - I’ve seen elsewhere some discussion around faking distance, for example - but there are plenty of fields where it would make sense, and there’s no need for Garmin to support overriding already-populated fields. I’m sure they could even somehow make it so that the native values are only incorporated when apps are downloaded from the store, meaning that they could go through the approval process and hence be vetted to avoid “cheating”.

  • If I understand correctly what you are trying to do then IMHO you won't be able. Garmin don't let you to write their official values, because that would enable people to fake all kinds of activities, etc. For the same reason they won't use your field as input even if you set :nativeNum. 

    To be honest I spent lot of time to find the "matching| nativeNum-s to my fields, and then at some point I just removed all the nativeNum-s from my code to save on the code size because I didn't see any advantage having them set.