Rohan Chaubey

Open Wearables - Open infrastructure for wearable-powered health products.

by
Build personalized health products with one API for every wearable. Access wearable data, open health scoring algorithms, and structured context your AI can reason with. Self-hosted, open-source, MIT licensed.

Add a comment

Replies

Best
Sebastian Kalisz

Trivia - the project origin was... standalone MCP server. It's funny, because now MCP server is a part of the Open Wearables, but it's still not 100% production ready. It's a long journey for that technology and in my opinion it's not that awesome as it seemed to be at the beginning.

Piotr Ratkowski

@kaliszs Fair take Sebastian, and honest. MCP was hyped as the universal answer and it's clearly not, the spec is still moving, the tooling is uneven, and "agent reads your data" is harder in practice than the demos suggest. That said, for a narrow use case like structured health context for an LLM, it's still the cleanest pattern we've found. Worth shipping, not worth overselling.

Kamil Żądło

@kaliszs Yeah, that tracks with how a lot of infrastructure-first ideas evolve in practice.

Piotr Pasierbek

@kaliszs haha yeah the origin story is a bit ironic

MCP had a lot of hype and reality is more nuanced. the protocol is useful but it's not magic - the hard part is still the context you feed it, which is exactly why the data and scoring layers matter

the server will get there. the foundation is what makes it worth building on

Grzegorz Frątczak

great idea. I am missing easy way to get data from my garmin watch!

Kamil Maksymowicz

@gregory80pl Garmin is fully supported. Deploy on Railway in about 5 minutes and your watch data starts flowing through the API. GitHub link is in the description if you want to dig in.

Sebastian Kalisz

@gregory80pl We too xd Garmin is a tough one, but we handled it!

Ajay Kumar

I share screenshots of my Whoop app with claude currently and ask it to analyse it based on the screenshot. Let me try using the MCP and ask it, feels like that could be a much smoother experience

Piotr Ratkowski

@ajaykumar1018 You can run the repo locally and setup the MCP server. Let us know your thoughts!

Sebastian Kalisz

@ajaykumar1018 Feel free to use our MCP, but remember - it's still not 100% production ready.

Eva Kuttichova

Hello, can this be used for react natives based on Expo?

Piotr Ratkowski

@eva_kuttichova2 Yes we have both Flutter and React Native SDK.

Sebastian Kalisz

@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 ;)

Jakub Mikołajczyk

Showed this to a founder friend building a longevity tracking app. She said the API coverage alone would have saved them six months of backend work. Congrats Momentum, timing on this feels right.

Piotr Ratkowski

@jakub_mikolajczyk1 Thanks Jakub, that's exactly the use case we built it for. Six months of OAuth flows, schema mapping, and provider edge cases is real time most teams don't have. If your friend wants to compare notes (or just complain about Garmin's docs), send her our way: Discord is the fastest path, or DM works too.

Sebastian Kalisz

@jakub_mikolajczyk1 High five! And thanks!

Piotr Pasierbek

@jakub_mikolajczyk1 six months is honestly conservative for some teams - the provider integrations alone are brutal to maintain

tell her we're here if she wants to talk through the use case: https://discord.gg/openwearables

Joanna Samek
congrats on shipping 🎉 quick question from someone who knows nothing about self hosting: does this require ongoing maintenance or is it more of a 'set it & forget it' situation once it's running?
Piotr Ratkowski

@joanna_samek Thanks Joanna! Honest answer: closer to "low maintenance" than "set and forget."

Once it's running, the main things are pulling updates when we ship a release, watching logs for errors, and occasional database housekeeping. Provider APIs change sometimes (Garmin tweaks something, Oura updates a field), we patch it, you pull the update. Security patches are mostly automated via Dependabot.

Realistically, a small team spends a few hours a month on it. If that sounds like more than you want to take on, Momentum offers managed deployments where we handle all of that for you.

Piotr Sobusiak

@joanna_samek the easiest option is to use one-click deployment on Railway so you don't have to worry about infrastructure so much. At least with relatively low scale this might be the best solution but once your user base grows it might become a bit pricey

PRIYANKA MANDAL
The self-hosted + MIT license approach is a positive signal to teams worried about compliance.
Piotr Ratkowski

@priyankamandal Thanks Priyanka. Self-hosted + MIT removes two of the hardest conversations with compliance teams: where does the data live, and what happens if the vendor disappears. The architecture is HIPAA-ready out of the box (encryption, audit logging, RBAC), though the cert itself sits with whoever operates the deployment, not the software.

Sebastian Kalisz

@priyankamandal Open source community is a real strength! We have 40+ contributors.

Michał Kukuł

As I’m not a developer, is there an easy way for me to test this tool?

Piotr Sobusiak

@michal_kukul sure, probably the easiest way to give it a try is using one-click deployment on Railway - you can check how it works in our docs: https://openwearables.io/docs/deployment/railway

Imtiaj Ahmad
How scalable is this if someone is pulling data from thousands of users simultaneously?
Piotr Ratkowski

@imtiaj_ahmad Very scalable: FastAPI + PostgreSQL + Redis + Celery scales horizontally, and multiple companies run it in production today. The real advantage at scale is the cost model: zero per-user fees, so where SaaS aggregators charge $0.50-2.00 per user per month, you only pay for your own infrastructure. The bigger you get, the better the math works.

Richie O'Halloran

This is great! Next thing we need is standardized API that the vendors commit to adopting. The Bluetooth heartrate profile and Generic Health Sensor profiles were a promising start but haven't lived up to their potential.

Piotr Ratkowski

@richieoh Agreed Richie, the Bluetooth SIG profiles (HRP, GHS) had the right idea on paper but vendors have zero incentive to converge, differentiation and lock-in are part of the business model, so a pragmatic abstraction layer is the only thing that ships in our lifetime.