Hi makers,
Most wearables are good at telling when you're asleep. They're much worse at telling when you're awake: if you lie still, many devices count it as sleep. Sleep stages land somewhere in between. And Apple, Oura, Garmin, Whoop and Fitbit all build their scores differently, so the same night can get very different numbers.
Anna D. Zych, PhD, a neuroscientist and Health Science Lead at Momentum, goes through all of this in a webinar that premieres Wednesday, 7 October at 16:00 CET. It covers what good sleep actually looks like, how wearables compare to a sleep lab across ten devices, and how to approach building sleep scoring models.
If you're building anything with sleep or recovery data, it should be a useful hour. Everyone who signs up gets the recording too.
This would’ve saved me so much time on a previous health project, I was making a meditation app that is influenced based on your health data.
@ragsyme A meditation app adapting to HRV and stress scores is a solid use case for exactly this. If you build it again, the stress index and HRV baseline algorithms are already in there.
@ragsyme But it still can help you in your next projects ;)
Thanks for sharing, that'll definitely unlock the industry!
I've been working on Heart Rate calculations based on raw ppg data. Does your open infrastructure include the data processing for this? I figured these are highly protected IPs by the health tech companies...
You're right that PPG-to-HR algorithms are guarded IP, and Open Wearables hits the same wall: we work at the cloud API layer, and almost no provider exposes raw PPG to third parties. Apple HealthKit ships derived metrics only (SensorKit needs research entitlements), Garmin's Health API gives HR and heartBeatIntervals at best.
The exception is Polar (Verity Sense, H10) via the Polar BLE SDK, raw PPG, ECG, and accelerometer stream over BLE. If you're processing raw signals in production, BLE-direct on Polar is the cleanest path today.
Hello, can this be used for react natives based on Expo?
@eva_kuttichova2 Yes we have both Flutter and React Native SDK.
@eva_kuttichova2 Btw, you find source code of both on our Github. Invitation links to try them are located in one of the Discord's channels ;)
@jacksonburch Breathing + HRV + respiratory rate is a nice fit for the data model, all three are surfaced across most providers (Garmin, Oura, Whoop especially). If you give it a spin, drop into Discord with whatever you find tricky, happy to help unblock. Good luck with TryBreathing.
@jacksonburch Jackson - group breathing with live biometrics is genuinely one of the more interesting use cases I've heard today. The latency tradeoffs across providers are real (some are near-real-time, others poll on
intervals) - Piotr or our infra folks can dig into the specifics on Discord. Either way, that sister site sounds like exactly the kind of thing this stack was built for.
@jacksonburch I would suggest to check our docs. We have there a coverage matrix of which data types are supported.
Is there a non-developer way to use this, or is it strictly for people who can set up their own server? Asking as someone who trains endurance athletes and wants smarter recovery data without hiring an engineer.
@nicole67 today it's developer infrastructure, but the better fit for you is a coaching platform built on top of Open Wearables (a few teams are already shipping athlete-management apps on it), DM me what you'd ideally see and I can point you in the right direction.
I have checked alternatives tab here and as far as I could agree on Terra, most of those products don't seem to be in the same category. Do you know any other alternatives to Open Wearables?
@kaliszs Fair observation. The closest direct comparisons (cloud-to-cloud aggregators with unified API) are:
Terra
Rook
Sahha
Junction
Spike API
Validic (enterprise/clinical, older)
All SaaS, all closed-source, all per-user pricing. That's the category. Open-source alternatives in the same lane: honestly, none we know of at production quality. Wearipedia exists but it's research-oriented (data scraping for academic work, not a production aggregator). That gap is part of why Open Wearables exists in the first place. If you've found something we missed, would genuinely like to hear about it.
how do you deal with data accuracy differences across wearables?
@nuseir_yassin1 Two layers to this: normalization handles schema and unit differences so all data speaks the same format before scoring. Sensor accuracy at the hardware level is harder: an optical wrist sensor and a chest strap will read differently, and no software layer fully closes that gap. What we can do is run the same scoring logic on top and let teams tune thresholds for known device biases in their user base.
We cover this topic much more on The Science Behind Wearables: https://thesciencebehindwearables.substack.com/
@nuseir_yassin1 You can set up priorities for providers and devices also.