Più smartwatch insieme senza dati doppi: guida alla deduplicazione multi-wearable

Se indossi più di un wearable, i tuoi passi sono quasi certamente gonfiati. Non per un bug: è il comportamento atteso di un ecosistema progettato per dispositivi singoli, usato da qualcuno che ha capito che strumenti diversi fanno cose diverse meglio. Un Galaxy Watch per il quotidiano, un anello smart per il sonno, un Garmin per le corse lunghe, un Suunto per le uscite in barca o in montagna: ogni dispositivo eccelle nel suo contesto. La dashboard, però, deve sapere che le 8.000 passi del mattino non vanno sommate alle 8.000 passi che Garmin ha registrato durante la corsa pomeridiana che passava per gli stessi marciapiedi.

Perché i dati si duplicano: la radice tecnica del problema

Health Connect è un database locale su Android. Ogni app con i permessi giusti può scriverci record di qualsiasi tipo: passi, frequenza cardiaca, sessioni di sonno, allenamenti. Health Connect non sa se due record sono la stessa cosa misurata due volte: non ha un campo "sorgente primaria" e non de-duplica in automatico. Questa è una scelta di design deliberata, non un limite tecnico: il sistema è neutro rispetto alle sorgenti per non favorire nessun produttore.

Il problema concreto: quando indossi Galaxy Watch e Garmin durante una corsa di 10 km, entrambi scrivono in Health Connect. Galaxy Watch scrive i suoi 9.847 passi, Garmin scrive i suoi 10.124 passi (numeri che divergono perché le calibrazioni del sensore sono diverse). Un'app che legge Health Connect senza logica di deduplicazione li somma: risultato, 19.971 passi per una corsa da 10 km. È il doppio. E per la frequenza cardiaca è peggio: le medie vengono contaminate da misure prese in contesti fisici diversi.

Tre pattern di duplicazione che incontro più spesso

1. Record cumulativi sommati: per i passi, alcune app scrivono record cumulativi ("passi totali del giorno fino a ora") invece che record intraday. Se sia Galaxy Watch che Garmin Connect usano record cumulativi, il totale a fine giornata è la somma di due totali, non un totale deduplificato.
2. Sessioni di sonno sovrapposte: Galaxy Ring o Oura scrivono una sessione di sonno 22:30-06:45. Galaxy Watch scrive 22:35-06:40 (stessa notte, finestre leggermente diverse). Un aggregatore che non clustera temporalmente le sessioni mostra due notti di sonno, raddoppiando le ore totali e inquinando le medie di sleep score.
3. Frequenza cardiaca media giornaliera da sorgenti miste: la fascia cardiaca Polar H10 che usi durante il workout scrive 147 bpm come media dell'allenamento. Il Galaxy Watch ha scritto 72 bpm come media a riposo del pomeriggio. Senza taggare le finestre temporali, la media giornaliera diventa un numero privo di senso fisico.

Il setup che sto descrivendo: quattro wearable, quattro ruoli

Per essere concreti, lavoro su questo caso d'uso specifico: smartwatch quotidiano (Galaxy Watch 7) che traccia tutto in background, anello smart (Galaxy Ring o Oura Ring) ottimizzato per il monitoraggio del sonno con sensori di qualità superiore rispetto agli smartwatch, GPS watch da corsa (Garmin Forerunner) per le uscite di running con GPS preciso e analisi avanzata del VO2max, watch outdoor/vela (Suunto Race o Suunto Ocean) per uscite su barche e trekking dove serve log GPS e altimetro barometrico. Quattro dispositivi, quattro contesti d'uso, quattro app che scrivono in Health Connect.

Come funziona la deduplicazione: tre strategie concrete

1. Winner-takes-all per sorgente e finestra temporale

Per la frequenza cardiaca intraday e per i dati di workout, il metodo più affidabile è definire una priorità di sorgente per ogni finestra temporale. Se Garmin ha scritto dati di frecuenza cardiaca tra le 17:30 e le 18:45 (durata della corsa), qualsiasi dashboard seria usa quei dati e ignora i dati scritti da Galaxy Watch nella stessa finestra. Galaxy Watch torna "vincente" dalle 18:46 in poi, quando Garmin non sta più scrivendo record attivi.

In pratica questo si implementa leggendo i record di tipo ExerciseSession da Health Connect: ogni sessione di allenamento ha un startTime e endTime. La logica di dedup usa queste finestre per decidere quale sorgente ha priorità per le metriche dentro quella finestra temporale.

2. Merge field-level per le metriche giornaliere aggregate

Per i passi totali giornalieri, la strategia winner-takes-all non è la soluzione giusta: Galaxy Watch raccoglie passi dalle 07:00 alle 17:29, Garmin raccoglie passi dalle 17:30 alle 18:45. La somma è corretta, non è una duplicazione. Il problema è se entrambi hanno registrato passi nella stessa finestra temporale.

Il merge field-level funziona così: dividi la giornata in slot di 15 minuti. Per ogni slot, tieni solo il record con il conteggio più alto tra tutte le sorgenti (conservativo, assume che il valore più alto sia il più accurato). Somma i massimi per slot: ottieni un totale giornaliero deduplificato. Questo approccio funziona perché due dispositivi che registrano gli stessi passi producono valori simili (il valore più alto è una stima della verità), mentre due dispositivi in contesti diversi producono valori additivi.

3. Clustering temporale per le sessioni di sonno

Per il sonno, il problema è diverso: le sessioni di Oura Ring e Galaxy Watch per la stessa notte si sovrappongono quasi completamente, ma nessuna delle due è sbagliata. Semplicemente misurano la stessa cosa con sensori diversi. La strategia è il clustering: se due sessioni di sonno si sovrappongono per più dell'80% della durata, vengono considerate la stessa notte. A quel punto si applica la priorità di sorgente: l'anello smart vince perché il sensore ottico al dito è statisticamente più preciso per le fasi del sonno rispetto al sensore al polso.

Cosa devi configurare tu: le tre impostazioni critiche

Non tutto può essere automatizzato. Ci sono tre configurazioni che richiedono input dell'utente perché dipendono da abitudini personali che nessun algoritmo può inferire.

1. Definire quale dispositivo è la tua sorgente principale per il sonno. Se hai sia Galaxy Watch che anello smart, devi dirlo esplicitamente. FitMesh Sync te lo chiede durante l'onboarding ("Quale dispositivo indossi di notte?"). Se non lo specifichi, usa Galaxy Watch come fallback perché è il più comune, ma questa è una scelta arbitraria.
2. Disabilitare Google Fit come sorgente di scrittura se ancora attivo. Vai in Health Connect > Gestione permessi > Google Fit e verifica che abbia solo permesso di lettura, non di scrittura. Google Fit deprecato che scrive ancora in Health Connect è la causa numero uno di passi triplicati nei setup multi-wearable.
3. Specificare i periodi di attività per i device specifici. Se Garmin lo indossi solo durante le corse (mai a riposo), il sistema può ignorare i suoi dati di frequenza cardiaca fuori dalle finestre di allenamento. Senza questa informazione, la frequenza cardiaca a riposo misurata da Garmin durante un'attività lenta può inquinare la media di riposo.

Il caso Suunto: dati che non passano per Health Connect

Suunto è l'eccezione in questo scenario. A differenza di Garmin (che scrive in Health Connect nativamente da Garmin Connect Android), l'app Suunto su Android non ha un'integrazione nativa con Health Connect per tutti i tipi di dati. Le tracce GPS e i dati di allenamento da Suunto sono accessibili via API Suunto Sport Engine, non via Health Connect.

Questo significa che per integrare Suunto in una dashboard multi-sorgente serve un connettore separato che legge dall'API Suunto Sport Engine con autenticazione OAuth. FitMesh Sync supporta questa integrazione separatamente: vai nelle impostazioni, sezione Dispositivi, e aggiungi Suunto come sorgente OAuth. Una volta connessa, i dati Suunto vengono uniti al flusso Health Connect con la stessa logica di deduplicazione.

Frequenza cardiaca media "inquinata": un esempio reale

Questo è il problema che noto meno ovvio ma più dannoso per chi usa i dati per monitorare la salute nel tempo. Scenario: esegui una corsa di 45 minuti con fascia Polar H10 collegata a Garmin (dati affidabili per l'allenamento, media 148 bpm). Nel frattempo Galaxy Watch registra la tua frequenza cardiaca ogni 10 minuti in background, vedendo valori compresi tra 145 e 155 bpm (è corretto, sei in corsa). Dopo la corsa, stai seduto per due ore con frequenza cardiaca a 62-68 bpm. Galaxy Watch registra ancora.

Una dashboard che calcola la "frequenza cardiaca media giornaliera" senza distinguere le sorgenti prende tutti questi dati, li somma e divide. Il risultato è un numero che non rappresenta né la frequenza a riposo né quella durante l'allenamento: è la media di cose che non andrebbero mediate insieme. Per questo motivo FitMesh Sync espone separatamente frequenza cardiaca a riposo (calcolata escludendo le finestre di allenamento) e frequenza cardiaca di allenamento (calcolata per tipo di attività), invece di mostrare un'unica media giornaliera.

Cosa fa FitMesh Sync in automatico

• •Rilevamento automatico delle sessioni di allenamento: legge gli ExerciseSession record da Health Connect e costruisce il grafico delle finestre attive per ogni sorgente.
• •Slot-merge dei passi a 15 minuti: prende il massimo per slot su tutte le sorgenti, elimina la sovrapposizione senza perdere i dati additivi (Galaxy Watch mattina + Garmin corsa pomeridiana).
• •Clustering delle sessioni di sonno: raggruppa sessioni sovrapposte oltre l'80% e applica la priorità anello > smartwatch per le fasi del sonno.
• •Separazione HR a riposo vs allenamento: le finestre di allenamento vengono escluse dal calcolo della frequenza cardiaca a riposo.
• •Deduplicazione record Samsung duplicati: filtra i record con lo stesso timestamp e source_package ripetuto (il bug Samsung noto di scrittura doppia).

Limiti onesti: cosa non si può automatizzare ancora

Non voglio sopravvalutare quello che una dashboard può fare da sola. Ci sono scenari che al momento richiedono ancora intervento manuale o che producono risultati approssimativi:

• •Allenamenti di nuoto con Suunto e Galaxy Watch sovrapposti: Galaxy Watch riconosce il nuoto come ExerciseSession (tipo SWIMMING), Suunto registra il suo log via API Sport Engine. Se i timestamp si sovrappongono parzialmente (es. cambio corsia tra una vasca e l'altra), la fusione è conservativa ma non perfetta.
• •VO2max da sorgenti diverse: Garmin calcola il suo VO2max con un algoritmo proprietario (FirstBeat), Galaxy Watch usa un altro metodo. Le stime non sono comparabili: FitMesh Sync al momento mostra le due metriche separatamente, non le fonde.
• •HRV da fascia pettorale durante il giorno vs anello la notte: se usi una fascia Polar H10 per HRV mattutino e l'anello per HRV notturno, i valori sono corretti nei loro contesti ma non confrontabili direttamente. Questo è un limite non del software ma della biometria: HRV varia in base all'ora e alla postura.

In sintesi

• •Health Connect non deduplica: è un database neutro per sorgente, e ogni app scrive indipendentemente. La logica di deduplicazione deve stare nell'app che aggrega.
• •I tre problemi principali nei setup multi-wearable sono: passi duplicati da record cumulativi sovrapposti, sessioni di sonno duplicate da dispositivi che misurano la stessa notte, frequenza cardiaca media inquinata da misure in contesti fisici diversi.
• •La strategia corretta è composta da tre tecniche complementari: winner-takes-all per finestra temporale (HR intraday), slot-merge a 15 minuti (passi), clustering temporale con priorità sorgente (sonno).
• •Due cose richiedono configurazione manuale: quale dispositivo usi di notte, e disabilitare Google Fit da sorgente di scrittura se è ancora attivo.
• •Suunto non passa per Health Connect: serve un connettore OAuth separato. I dati vengono poi unificati nella stessa logica di dedup.
• •La frequenza cardiaca media giornaliera senza distinzione di contesto è un numero senza senso fisico: separa sempre HR a riposo da HR durante l'allenamento.