Zeo Mobile, The hackening

The first nights sleep was rather easy to collect. While the data produces nice charts. The next step was to see how to download the data from the android phone. Here is how to do that.

The Android application connects to the headband over Bluetooth. The raw data is post processed via an FFT into a "profile" of 30 second and 5 minute bins which are used to produce the charts. This data is recorded in a dataset per sleep session called a sleep record in a SQLite3 database file on the Android device in the protected path: 

Prior to Android 6.0 "Marshmallow" it was rather easy to install and then grant limited "root" access to Apps permission to access an Apps data directory using something like the SuperSU application. However as of Android 6.0 that path is much more difficult to enable.. and carries significant security risks if achieved.

Rather the preferred method is to construct an App which "requests" access to a co-installed Apps data store and explicitly "grant" it permission to do so.

The OpenZeo sample projects demonstrated how to do this:

Essentially it is intended to use the Android feature set to access the Apps sqlite database and returns the results of a query intending to save it to the local file system and or share it through other APIs with a user.

Unfortunately the sample program has a few problems and crashes.. however the compiled APK does run on Android 6.0 up to the point at which it attempts to share data.

This is likely a symptom of the age of the App since it was originally compiled to work on probably the Android 4.0 KitKat platform.. a lot has changed since then.

During the Android 4.0 "era" the ADT Eclipse plugin was loaded into an install of Eclipse and the Android SDK provided libraries a build environment and AVD (android virtual device) to complete a development environment.

During the Android 6.0 "era" this has been replaced with Android Studio.

In both cases, the best option is to install "git.exe" such that the original OpenZeo GitHub sample project can be cloned directly and brought in as a Project and compiled. In some cases "Warnings" must be disabled in order to allow the project to compile. It can then either be run on the AVD virtual device, or side loaded into an actual Android Device.. if the device is Android 6.0 it will request access to the MyZeo Apps datastore upon installing which must be granted. It should be noted that (1) it assumes the MyZeo App will be installed and (2) that the MyZeo db has at least one sleep record to access.

Another "successful" method is to use a different Android device which has Android 4.4 Kitkat installed and for which "#SuperSU" (in the GooglePlay store) can be used to allow a file browser app like "ES File Explorer" (in the GooglePlay store) to travel to the:


directory and copy it to a  directory where it is more easily accessed or can be uploaded or synced, ES File Exporer has a 'built-in' Remote Manager > it is an FTP server -> Settings > Network >V - Remote Manager (works well with WinSCP if you 'remember to select FTP'). You can then browse the Android device from a desktop or any wireless device on your network to retreive the file... scary huh?

Then using a Windows program like [sqlitebrowser-3.8.0-win64v2.exe] the data can be browsed and exported.. or other sqlite tools can be used to work with the data.

A final method would also be to install the Android ADB and use the Android Backup command to take a backup of the apps and their databases and store them offline. Then use a program like BackupExtractor (on GitHub) to retrieve the App database file from the backup.

I believe all things being equal its probably best to modify the ZeoCSV example app to export records to a file on a regular basis and email, replicate or copy those to a central repository as individual sleep records.

The OpenZeo project also documents the format of the SleepRecord such that all of the fields available from the sqlite database are defined and easily interpreted.

Sleep Record Field Definitions

The sad thing so far, is that, this is an [intermediary] method of accessing the Zeo data, post processed. The actual EEG data was turned into this format before it was stored in the sqlite3 database. While that is probably the most useful for most people. The pre-processing means the device is still a highly sought out commodity and a single point of failure. We can only hope that the company that bought the intellectual property returns to the market at a similar price point, or that other IoT devices are brought to bare on the problem.

The Zeo bedside model had been "opened" such that raw EEG signal data could also be obtained.

Since the headband unit both transmits in "buckets" during the night and "deluge" mode in the morning to round out a sleep record. It is probably where the FTT analysis is conducted. IoT devices are becoming more powerful all of the time and its often only a sketchup away from providing FFT services.

Observing the bluetooth signals would be an interesting study.

In the [other] direction.. where to put all of this data.

A couple of Cloud services come to mind, for free and cost, Ubidots, AWS and they offer enhanced algorithmic processing of the data that appears in a dashboard.. very similar to the previous Zeo dashboards.

Dashboards as a Service is more or less a commodity business these days.

It might be worth mentioning there are many formats for the data file:

1. EEG raw
2. XML post processed
3. sqlite2 post processed
4. sqlite3 post processed
5. pseudo-CSV, XML export format from various Apps (definitely post processed)
6. whole Spreadsheets of imported source data post processed
7. emails of results

The decoder/viewers from various sources appear to only work with "their variant" and its often not well documented which format they use. On the whole the XML formats appear easier to read and are often what you see in "print" on the web, this is because binary blobs are just not webshop "photogenic".. whatever the format the data is in it is usually not that difficult to figure out.. just put your Sherlock hat on and start puzzling it out.

Another thing to consider is the product has gone through two to three design "re-fits" or releases, so there is a lot of information available on the web that only applies to the earlier models. 

Essentially, the Bedside model went through a period when the data was safe guarded and encrypted, which for the time was probably a good idea. But then they seemed to re-think this and opened it up, retro-fitting the older gear with firmware upgrades to store the data un-encrypted.. hence the three firmware upgrades you see floating around. 

The Mobile version was a redesign with the same goals and similar interfaces, but as far as I can tell it "never" encrypted your sleep data, hence no need for firmware upgrade to get the un-encrypted data for study.

While the iPhone, iPad apps are gone, as far as I can tell they also used the sqlite database, although it may have been version 2 (I don't have access to the iOS apps so I can't confirm).

The Android apps just used the Google APIs which used a local sqlite file per apk stored in the apps private directory on the phones file system, which has become harder and harder to access.. and now its better to use the APIs put in place to support cross-app accessing their datastore.. rather than pilfering the db files outright.

If you attempt to compile the Android sources on the Github projects with Android Studio or Eclipse ADT beware the platform SDK the source expects. android-8 was "2.2 Froyo" if you don't have the SDK the source is expecting as available in the compiliation environment it will fail with many mysterious class undefined errors and warnings. I succeeded in recompiling the old code and running it on Android 4.4 and Android 6.0 but it wasn't totally obvious at first. Most of the code was checked in around 2013... we're talking "Stargate Ancients" here .. in cell phone terms.. that was a "looong" time ago.

I have a full day today, but this evening I'll see if I can throw together a little YouTube video of how to compile the Github apps in Eclipse ADT and Android Studio.. if someone else doesn't preceed me. Jimmy Neutron I'm not.. but I found it a little difficult to navigate Googles new Alphabet soup.. it looks like they sent out a few Gravity Waves of their own when they ripped apart ADT last year.

Zeo – In Depth Product Review - Pictures of the Bedside model and Sensor Pads
Zeo Sleep Manager Review  - Pictures of the Mobile model, Box and Cradle