OpenYou

End of Openyou.org

2018-06-05T19:48:12-07:00

OpenYou hasn't really been a thing since 2012, but the project never really got a proper closure.

Fixing that now.

I'll be archiving all of our repos (outside of emokit, which is now community maintained) on github. The website and repos will stay live as long as I'm still using services that make it easy to keep them up.

If you're interested in what I'm up to, my personal site is at kyle.machul.is.

Please do not contact me about bugs/issues on the open source OpenYou projects, as I don't really work in the open source health tech space anymore and do not have time to resume maintenance of them. Most of them refer to hardware that is no longer produced, and I do not have time to update them to new hardware. If you are interested in taking over maintenance, please feel free to fork them, and if you would like me to add links to the forks, feel free to reach out via one of the contact methods on my personal site.

I hope the project was useful while it existed, and look forward to seeing how others hack health tech in the future.

Thanks,

Kyle Machulis

Ex-OpenYou Maintainer

Zeo Firmware and Raw Data API on OpenYou github

2013-06-11T13:42:20-07:00

It appears Zeo, which declared it was shutting down in March, has taken a scorched earth policy in terms of developer firmware and libraries. All zeo websites are gone, and the sourceforge has been cleared out. I still had versions of the firmware and raw data API kicking around on my harddrive, and managed to fork the android project before the github account disappeared. I've thrown all of this on the openyou github account.

Zeo Firmware: http://github.com/openyou/zeo-firmware

Zeo Raw Data API: http://github.com/openyou/zeo-raw-data-api

Zeo Android API: http://github.com/openyou/zeo-android-api

Since most developers are used to looking for these kind of libraries on github, that seemed the best place to store them right now even though I certainly have no plans of doing any upgrades to them. The master branches will most likely stay as copies of the final versions so that others can have a reliable base to fork from.

For developers that want web accessible documentation, SleepStreamOnline (a project done by a Zeo intern a few years ago) is still around, and has web documentation for the raw data API available. Assuming this ever goes down, developers should also be able to generate their own version from the Raw Data API code using sphinx.

OpenYou Github Organization

2012-10-21T15:57:20-07:00

I've finally gone ahead and moved most of my health driver repos, as well as the repo holding the openyou.org blog, to the OpenYou Organization on github. Over an indeterminate amount of time in the future, I'll be flipping the READMEs, and possibly the licensing, to reflect OpenYou also.

The hope here is to get more community involvement in drivers for health equipment. Up until now, the repositories have lived on my personal github account, which, while great for my coderwall badges, means that I'm primarily responsible for support. Ask anyone who's emailed me actually asking for support, and you'll find out how well that's gone so far.

While I do get and try to service pull requests on my drivers, sometimes it takes me weeks or months, or else I do things out of order and end up conflicting people's patches. My hope with moving these to an organization setup is to allow developers that are interested to help out with maintenance of these projects.

I'm already starting to see this in action, as there's now a developer on the emokit project working on porting the C library to HIDAPI. I'd like to get battery power and signals in soon too. There's a bunch of stuff to be done on things like libfitbit and libomron too.

Moving this stuff forward shouldn't depend on the amount of free time I have. If you're interested in becoming a developer with commit rights on one of these projects, file an issue in the project you're interested in working on.

OpenYou Projects Update

2012-05-28T21:32:22-07:00

It's really amazing how quick a year can disappear by.

Due to personal circumstances that involved finding a new job, hacking some robots, being in Make Magazine, etc... It's been a quiet year at OpenYou so far.

So, an update!

libfitbit

http://www.github.com/qdot/libfitbit

I'm still seeing pull requests to libfitbit! The library has become somewhat more stable, though we're still plagued by issues with the base station locking and not communicating until it's unplugged/replugged. I'm not sure if this is an issue with the fitbit base station or with my python ANT library. It's something I hope to look into soon.

I'd also like to get a Fitbit Ultra at some point, to get altimeter readings into the system.

emokit

http://www.github.com/qdot/emokit

As of today, Emokit for the Emotiv EEG sees a major update, at least in terms of protocol documentation. We now have access to the sensor quality levels and battery power levels, the two portions we'd been waiting on in order to finish the library and release v1.0. I've created a protocol document that's available in the github repo, and would like to get this pressed into code ASAP.

In less new-featurey but important maintenancey issues, I'm also planning on moving the library to HIDAPI, which should solve a lot of the crossplatform issues reported in the repo. I'd also like to finish the OpenVibe bindings, which I got started but then fell off on due to above mentioned circumstances.

libfuelband

http://www.github.com/qdot/libfuelband

I've been permaloaned (Sorry Barry I swear I'll get it back to you) a Nike Fuelband to work on. I did some initial proof-of-concept code a while ago, which found some dates and what I believe are steps recorded down to the second (the highest granularity I've seen in a consumer pedometer thus far).

The unfortuate news is that there seems to be no good way to access the LED array, which was my original goal. However, the factory wipe mechanism looks like it may be a firmware reload, which would be super handy for possibly building my own LED access functions.

So, that's it for now. I'll hopefully be posting more about some of the patent battles in health technology this year soon, as things have really been heating up.

Speaking at SF Data Mining Meetup - March 6, 2012

2012-03-05T14:40:09-08:00

Contrary to evidence otherwise, I'm not dead, just got busy with life outside blog/qs land for the past 8 months. Am now working on returning to former productivity levels, starting with a new release of emokit and openvibe bindings ASAP, then maybe taking another look at libfitbit and the fitbit ultra.

Before that's all done though, I'll be speaking at the SF Data Mining Meetup March 6th at the Trulia offices. It's me and one of the people from Basis. I think it may already be sold out, but watch the page to see if more spots become open.

libfitbit Hangups

2011-08-07T19:34:29-07:00

First off, hello to everyone who found us through the MIT Tech Review article or Ubuntu Community talk! Been a bit slow around here lately, but hoping to get things booted back up.

It seems the most requested thing at the moment is a finalized version of libfitbit. Currently, we're at v0.0.1, which was released in February and hardly worked. There's been a lot of progress since then, and we are now able to replicate full communications with the tracker. There's really just one problem left with the library, and that's the subject of today's post.

So, unless you're into specifics of the implementation of the ANT protocol, you can probably skip the rest of the post. However, if you're interested in helping me kill the last bug before I can start making distributable, read on.

I recommend having the ANT Protocol Specification open while following along, as I'll be talking about packet types quite a bit. Also, if you have any comments, please leave them on the github issue about this problem.

UPDATE: And, 2 hours after I post this, I fix it myself. I wasn't resetting the USB device correctly, which meant we were getting weird configuration conflicts from the last session run. Fixing the device reset clears this, and libfitbit will now retreive information multiple times without having to completely un/replug the key. I'll write up a "rest of the things I need to do" post tomorrow to let everyone know what's next.

Whenever libfitbit connects to the tracker, the first transfer after plugging in the USB goes fine. We start communications with an ANT reset message, and we always get back a 0x6F package (Startup Message) with a payload of 0x00 (POWER_ON_RESET), which is what we expect since we just powered on the ANT stick. We then continue on through establishing a communications channel, running a beacon signal to find the tracker, and other steps as laid out in the fitbit protocol document.

The problem comes in on the second run of a libfitbit based utility. We try and reset the device, but instead of getting back a 0x6F packet, we usually receive something that looks like a bulk data receive packet, like we would expect back from a bank transfer. Further executions the utility will result in the same, until the point where the receive command from the reset completely times out, and continues to do so. The only way to fix things at this point is to unplug/replug the ANT stick, at which point things work fine again, for one round of communication.

The actual fitbit client doesn't have to deal with this due to the fact that it grabs the device right when it starts up, and doesn't let go until shutdown. I suppose I could try stopping and restarting the service with the base plugged in while watching an analyzer, and that may be my next step.

This bug is the major thing holding up library development right now. Until this is fixed, I can't reliably run multiple sessions with the fitbit, and having to replug the USB stick isn't a viable solution. I'm pretty sure I'm missing something about how connections should end or restart, but progress on this one is slow so far.

Withing Scale Network Hijacking

2011-06-06T22:01:19-07:00

The Withings Scale is a pretty simple piece of hardware. Set it up on your wifi network, weigh yourself, and it instantly sends your weight to the Withings website.

Now, as Withings isn't really taking and analyzing a ton of data, it's (apparently) fairly trivial to pull all the needed data from their website. However, there are those who aren't completely happy with that solution, and who also don't want to deal with the slow flash interface.

The people at Proxilium decided to reverse engineer the network protocol, doing a full trace on the communications between the scale and the home website, and extracted all of the data the scale sends to the website. Not only that, he shows how to set up alternate DNS rules to route off calls to the website to a local webserver, so you can have your own data store. Neat!

libfitbit Development Update

2011-05-26T22:20:12-07:00

There's been a lot of interest in libfitbit lately, so here's a quick update on where I am with development.

Web client is now completely working. Was stuck on ANT burst sends not working, which are used to update the device time and stats like height and weight. Putting in a sleep between burst sends seems to have fixed it. Because, much like putting a bird on it, putting a sleep in it fixes everything.
Tested the fitbit with the Garmin ANT Stick, works fine. Hoping to test with Suunto stick within the next week, the goal being to have multiple ant antennas on multiple machines, all which can communicate with any ANT hardware.
Can get per-minute Step Count and Active Point Score from the fitbit

This is close to getting us to a v0.1 release, which I'm hoping will happen next week after the Quantified Self Conference. I'm also working on documentation and making a couple of useful utilities, such as a linux daemon for web service uploads (yes, I realize I'm doing fitbit's work for them, and no, I'm not real thrilled about it either), and dumping data to json/xml.

In terms of what I'd like to see for versions after that:

Finish the data format protocol. There's still a couple of packets I'm not sure about, and I haven't figured out how events (sleep, etc...) work yet.
Dividing out the ANT protocol class and ANT antenna classes into their own library, so they can be shared between multiple device libraries. I'm moving toward this with the current design, but don't want it holding up the v0.1 release
May a C version? I'm not exactly motivated about this since python works fine for me right now, but if the need arises, it could be nice to have around. The ANT people have actually said they have little linux experience on staff, so I wouldn't be expecting their support on the library side soon anyways. Definitely an ownable area for anyone looking to start up an open source project, and there's a ton of code already out there...
Whatever else people are looking for. Let me know in the github issues if you have requests.

libomron Verified Working with BP791IT

2011-05-25T16:31:12-07:00

I've received from email from an OpenYou reader who purchased the BP791IT, which is the updated version of the HEM790IT Blood Pressure Monitor from Omron.

They've verified that this blood pressure monitor does work with OpenYou's libomron library. So, go forth and purchase, knowing you can still pull your data off of the device on any platform libomron supports (which is anything libusb supports).

Please note that I've been getting a few issue reports with getting libomron working on OS X, having to do with the kexts not causing the device to detach from the HID Manager correctly on 10.6.7+. These reports have been rather intermittent, but if you experience any issues, please get in touch with me via email or file a bug report on the github site.

Upcoming Speaking Engagements

2011-05-13T20:12:12-07:00

This summer is shaping up to be a busy one...

I'm speaking at Maker Faire. Twice, even!

2011-05-21 3:30pm - OpenYou.org Presentation, Health 2.0 Stage
2011-05-21 6:00pm - OpenKinect Presentation, Main Stage

Then there's the Quantified Self Conference on May 28-29th, 2011, at the Computer History Museum in Mountain View, CA. There's no central presentation, but honestly, I probably won't stop talking at any point during the 2 days, as I have a table at the expo, plus will be helping out with the health hardware session and the hackathon.

On June 23rd, I'll be doing a presentation on the OpenKinect project at NetExplorateur Zoom 2011 in Paris.