Multiple smartwatches, no duplicate data: the multi-wearable deduplication guide

If you wear more than one wearable, your step count is almost certainly inflated. Not because of a bug: it's the expected behavior of an ecosystem designed for single devices, used by someone who has figured out that different tools do different things better. A Galaxy Watch for everyday use, a smart ring for sleep, a Garmin for long runs, a Suunto for sailing or mountain outings: each device excels in its context. But the dashboard needs to know that the 8,000 morning steps shouldn't be added to the 8,000 steps Garmin recorded during the afternoon run that went through the same streets.

Why data duplicates: the technical root cause

Health Connect is a local database on Android. Any app with the right permissions can write records of any type: steps, heart rate, sleep sessions, workouts. Health Connect doesn't know if two records represent the same thing measured twice: it has no 'primary source' field and doesn't auto-deduplicate. This is a deliberate design choice, not a technical limitation: the system is source-neutral to avoid favoring any manufacturer.

The concrete problem: when you wear both a Galaxy Watch and Garmin during a 10 km run, both write to Health Connect. Galaxy Watch writes its 9,847 steps, Garmin writes its 10,124 steps (numbers diverge because sensor calibrations differ). An app that reads Health Connect without deduplication logic sums them up: result, 19,971 steps for a 10 km run. That's double. And for heart rate it's worse: averages get contaminated by measurements taken in different physical contexts.

Three duplication patterns I encounter most often

1. Summed cumulative records: for steps, some apps write cumulative records ('total steps so far today') instead of intraday records. If both Galaxy Watch and Garmin Connect use cumulative records, the end-of-day total is the sum of two totals, not a deduplicated total.
2. Overlapping sleep sessions: Galaxy Ring or Oura writes a sleep session 22:30-06:45. Galaxy Watch writes 22:35-06:40 (same night, slightly different windows). An aggregator that doesn't temporally cluster sessions shows two nights of sleep, doubling total hours and skewing sleep score averages.
3. Daily average heart rate from mixed sources: your Polar H10 chest strap writes 147 bpm as the workout average. The Galaxy Watch wrote 72 bpm as the afternoon resting average. Without tagging time windows, the daily average becomes a physically meaningless number.

The setup I'm describing: four wearables, four roles

To be concrete, I'm working with this specific setup: everyday smartwatch (Galaxy Watch 7) tracking everything in background, smart ring (Galaxy Ring or Oura Ring) optimized for sleep monitoring with superior sensors compared to smartwatches, running GPS watch (Garmin Forerunner) for running sessions with precise GPS and advanced VO2max analysis, outdoor/sailing watch (Suunto Race or Suunto Ocean) for boat outings and trekking where GPS logging and barometric altimeter matter. Four devices, four use cases, four apps writing to Health Connect.

How deduplication works: three concrete strategies

1. Winner-takes-all by source and time window

For intraday heart rate and workout data, the most reliable method is defining a source priority for each time window. If Garmin wrote heart rate data between 17:30 and 18:45 (run duration), any serious dashboard uses that data and ignores data written by Galaxy Watch in the same window. Galaxy Watch becomes 'winning' again from 18:46 onward, when Garmin is no longer writing active records.

In practice this is implemented by reading ExerciseSession records from Health Connect: every workout session has a startTime and endTime. The dedup logic uses these windows to decide which source takes priority for metrics within that time window.

2. Field-level merge for aggregated daily metrics

For total daily steps, winner-takes-all isn't the right solution: Galaxy Watch collects steps from 07:00 to 17:29, Garmin collects steps from 17:30 to 18:45. Adding them is correct, not duplication. The problem is when both have recorded steps in the same time window.

Field-level merge works like this: divide the day into 15-minute slots. For each slot, keep only the highest-count record across all sources (conservative, assumes the highest value is the most accurate). Sum the per-slot maximums: you get a deduplicated daily total. This approach works because two devices recording the same steps produce similar values (the highest is an estimate of the truth), while two devices in different contexts produce additive values.

3. Temporal clustering for sleep sessions

For sleep, the problem is different: Oura Ring and Galaxy Watch sessions for the same night overlap almost completely, but neither is wrong. They simply measure the same thing with different sensors. The strategy is clustering: if two sleep sessions overlap by more than 80% of their duration, they're treated as the same night. Source priority is then applied: the smart ring wins because optical sensors at the finger are statistically more precise for sleep stages than wrist sensors.

What you need to configure: the three critical settings

Not everything can be automated. There are three configurations that require user input because they depend on personal habits that no algorithm can infer.

1. Define which device is your primary sleep source. If you have both a Galaxy Watch and a smart ring, you need to say so explicitly. FitMesh Sync asks during onboarding ('Which device do you wear at night?'). If you don't specify, it defaults to Galaxy Watch as the most common fallback, but that's an arbitrary choice.
2. Disable Google Fit as a write source if still active. Go to Health Connect > Permission management > Google Fit and verify it has read-only permission, not write. Deprecated Google Fit still writing to Health Connect is the number one cause of tripled steps in multi-wearable setups.
3. Specify active periods for specific devices. If you only wear Garmin during runs (never at rest), the system can ignore its heart rate data outside workout windows. Without this information, resting heart rate measured by Garmin during a slow activity can contaminate the resting average.

The Suunto case: data that doesn't go through Health Connect

Suunto is the exception in this scenario. Unlike Garmin (which writes to Health Connect natively from Garmin Connect Android), the Suunto app on Android doesn't have native Health Connect integration for all data types. GPS tracks and workout data from Suunto are accessible via the Suunto Sport Engine API, not via Health Connect.

This means that integrating Suunto into a multi-source dashboard requires a separate connector that reads from the Suunto Sport Engine API with OAuth authentication. FitMesh Sync supports this integration separately: go to settings, Devices section, and add Suunto as an OAuth source. Once connected, Suunto data is merged into the Health Connect stream with the same deduplication logic.

Contaminated average heart rate: a real example

This is the problem I find least obvious but most damaging for people using data to monitor health over time. Scenario: you run for 45 minutes with a Polar H10 chest strap connected to Garmin (reliable workout data, average 148 bpm). Meanwhile Galaxy Watch records your heart rate every 10 minutes in background, seeing values between 145 and 155 bpm (correct, you're running). After the run, you sit for two hours with heart rate at 62-68 bpm. Galaxy Watch is still recording.

A dashboard that calculates 'daily average heart rate' without distinguishing sources takes all this data, sums it and divides. The result is a number that represents neither resting heart rate nor workout heart rate: it's the average of things that shouldn't be averaged together. That's why FitMesh Sync exposes resting heart rate (calculated excluding workout windows) and workout heart rate (calculated per activity type) separately, instead of showing a single daily average.

What FitMesh Sync handles automatically

• •Automatic workout session detection: reads ExerciseSession records from Health Connect and builds the active window map for each source.
• •15-minute slot-merge for steps: takes the maximum per slot across all sources, eliminating overlap without losing additive data (Galaxy Watch morning + Garmin afternoon run).
• •Sleep session clustering: groups sessions overlapping by more than 80% and applies ring > smartwatch priority for sleep stages.
• •Resting vs workout HR separation: workout windows are excluded from resting heart rate calculation.
• •Samsung duplicate record deduplication: filters records with the same timestamp and repeated source_package (the known Samsung double-write bug).

Honest limits: what can't be automated yet

I don't want to oversell what a dashboard can do on its own. There are scenarios that still require manual intervention or that produce approximate results:

• •Swimming workouts with overlapping Suunto and Galaxy Watch: Galaxy Watch recognizes swimming as an ExerciseSession (type SWIMMING), Suunto logs via Sport Engine API. If timestamps partially overlap (e.g., lane changes between laps), the merge is conservative but not perfect.
• •VO2max from different sources: Garmin calculates its VO2max with a proprietary algorithm (FirstBeat), Galaxy Watch uses a different method. The estimates aren't comparable: FitMesh Sync currently shows the two metrics separately, not merged.
• •HRV from chest strap during the day vs ring at night: if you use a Polar H10 for morning HRV and the ring for nocturnal HRV, the values are correct in their contexts but not directly comparable. This is a limit of biometrics, not software: HRV varies by time of day and body position.

In summary

• •Health Connect doesn't deduplicate: it's a source-neutral database, and every app writes independently. Deduplication logic must live in the aggregating app.
• •The three main problems in multi-wearable setups are: duplicate steps from overlapping cumulative records, duplicate sleep sessions from devices measuring the same night, contaminated average heart rate from measurements in different physical contexts.
• •The correct strategy combines three complementary techniques: winner-takes-all by time window (intraday HR), 15-minute slot-merge (steps), temporal clustering with source priority (sleep).
• •Two things require manual configuration: which device you wear at night, and disabling Google Fit as a write source if still active.
• •Suunto doesn't go through Health Connect: a separate OAuth connector is needed. Data is then unified in the same dedup logic.
• •Daily average heart rate without context distinction is a physically meaningless number: always separate resting HR from workout HR.