Gear Question - Components of Components

Hi, I’ve got some questions regarding gear and components.
first of all, I really like the fact, that you can do gear for every
sport you create (garmin is kinda limited there) and the fact that there
is a different setup for indoor.

However, the whole thing is not quite where I “need” it to be.

I swim, bike, run, walk, hike and ski (I think that’s it ;D).

So for swimming I’d like to keep track of my trunks (several of them spread
over different locations - I’d like to keep track of how many uses I get
out of them before they break down.), I swim with different goggles and HRM
straps, along with the usual gear (paddles, pull buoys, kick boards, snorkels, fins).

For cycling I own around 6 bikes, a trainer, several pairs of shoes, more
than one cycling computer, different HRM straps, a bunch of lights,
helmets, sensors, power meters, …

For running I keep track of a bunch of pairs of running shoes (indoor and
outdoor), HRM Straps, a Stryd Power Meter, …

For skiing I’d like to track the usage of my boots, skis and again HRM
straps, maybe the helmets.

From what I’ve understood you can currently add one ‘gear’ per activity - which is kinda not actual gear but rather a setup?

The rest is tracked in components? This sounds like a valid concept,
however in order to really keep track of all of the stuff around, the
function of adding components to components is missing.

I’d figure something like this (‘root’ elements are ‘gear’, all below
are components):

  • gravel (mtb, winter shoes, lights, 1030)
    • frame: 3t exploro
      • power meter: garmin rally
      • chain: some
    • wheelset: 650b
      • casette: 12speed
      • speed sensor: garmin
        • battery
    • shoes: fizik winter
      • cleats: rally
    • lights: varia radar
    • lights: ut800
    • computer: 1030+
    • hrm: polar
  • gravel (road, summer shoes, lights, 1030)
    • frame: 3t exploro
      • power meter: garmin rally
      • chain: the same
    • wheelset: 700c carbon
      • casette: 12speed
      • speed sensor: garmin
        • battery
    • shoes: fizik summer
      • cleats: rally
    • lights: varia radar
    • lights: ut800
    • computer: 1030+
    • hrm: polar
  • indoor
    • frame: tri bike
      • power meter: garmin rally
      • chain: some chain
    • trainer: kickr core
      • casette: 11speed indoor
    • wheelset: none
    • shoes: indoor
      • cleats: rally
    • computer: 1030+
    • hrm: polar
  • running (shoes a, garmin hrm, stryd)
    • shoes: model a
    • hrm: garmin
    • power meter: stryd
  • running indoor (indoor shoes, polar hrm, stryd)
    • shoes: model indoor
    • hrm: polar
    • power meter: stryd
  • running (shoes b, no hrm, no stryd)
    • shoes: model b
  • swimming (trunks a, forms goggles, no hrm)
    • apparel: trunks a
    • goggles: forms
  • swimming (trunks b, optical goggles, garmin hrm)
    • apparel: trunks b
    • goggles: optical
    • hrm: garmin
      • battery: cr something
  • skiing (boots, carvelinos, helmet, garmin hrm)
    • ski: carvelinos
    • helmet: ski helmet
    • hrm: garmin
      • battery: cr something

Does that make any sense? Also, some of the components listed here are
no options in the dropdowns. Like running shoes or ski boots - as the gear
is not it, It’ll need to be a component?

And the linking of components to components kinda get’s necessary when
sensors, mounted to wheels have batteries and so on.

Hope to hear some insights or other strategies on this topic.
best regards

1 Like

Wow you have a lot of stuff! I decided to not do a full component tree and just have 2 levels (gear with components) to reduce complexity. It already gets a little complicated with reminders on top of those.

You can add the same component instance to more than one gear item which might help somewhat.

1 Like

I was afraid that the complexity might scare away developers :wink: since this is not implemented anywhere.

I think I’ll track everything in conponents and use gear to group it. But it gets a bit redundant as the casette for example „lives“ on the trainer/wheelset while the rest kinda is linked to the „frame“

Any chance I can help with that? The reminders would probably be tricky as they are especially relevant for the lowest items in the tree - on the other hand: it would reduce overhead for the user as I’d just have to add a wheelset to a „gear“ and implicitly get tyres, tubes, air pressure sensors, speed sensors and all of their batteries - no way to forget anything :wink:

Hi, I’ve played around a bit with different ways to “group” stuff, so what I’m wondering right now is the /api/v1/athlete/{id}/gear{gearID} PUT the right way to update distance/time/counters?

That Way I could just add Gear (setups) and Components (the actual stuff) and use #tag elements in the description to “link” them together → after the fact I’ll just run a daily script against the API that updates the counters for the components.

An excerpt of what I’ve come up with looks a bit like this:

Just with like 5 frames and a shitload of differen “gear” (setups) as I’ll switch and swap different HRM Straps / Bike computers / Shoes → so I’d add a “GEAR” item for all possible combinations as I’m tracking the actual stuff in components anyways.

Yes you can update the counters in that way. Remember though that Intervals.icu will also update them when you complete rides and so on. But your PUT will overwrite whatever is there so that doesn’t matter too much.

Perfect.

I wasn’t planning on linking any components to gear, so intervals.icu can only update the ‘gear’ items which are just ‘setup groupings’ to me - the actual tracking is done in components, which I’ll update manually using the PUT method on the API based on the assigned gear (and the notes within)

I like Intervals.icu so much now because it’s becoming more and more the only one tracking platform for me. It’s absolutely amazing what is possible so far and how the community works. Also a big compliment to you @david!

I am currently using https://www.probikegarage.com/ as an Android app for gear tracking. Here you can manage the whole stuff very well. Nesting is also possible. For example, I nested my wheels there because I don’t change the tire, cassette or disk brake rotor in case of swapping.
For example one of my rear wheels contains tire, disk rotor and cassette.
I also have 2 chains per bike, because i wax them every 500km. the scenario is driving 500km, swap chain to second one, drive next 500km, wax chains and swap to first. The waxing is a service interval, like the reminder-function here on intervals.

I am now trying to map the whole thing at intervals so that there is one less platform again.

1 Like

that app looks interesting, but just as inspiration on how I want to implement that on intervals, i’m not planning on spending any money :wink:

I already planned on how to track this some time back, but now I’ve actually started playing around with api calls in rust, so I’ll probably try that this week.

my plan was:

  • add running shoes as gear (no good alternative)
  • add everything else as component
  • add a “gear” for each “setup” I use and want to set for activities
  • the components are never linked to any “gear” but rather contain information in the description as to what their parent is, relative to time
    • probably some sort of dict in json
  • then my script/something will go over activities and update all components that “match” the “gear” set for that activity

that way I can nest stuff like you described: sensors, cassette, tyre, tube all stay on the wheelset

in the end i’ll have for example my gravel setup (gear: gravel) and the components (frame, wheelset) get matched. both components themselves are parents also so the drivetrain, cassette, … are matched to the whole thing as well.

for more variable stuff (helmet, lights, shoes) i’ll use tags within the activity itself, and the bike computer and power meters should show up in the actual fit file, so those are easy to match.

the shoes for example have cleats matched, …

1 Like