Zeo Sleep Monitor - Android Data Export

Continuing the discussion from Zeo Sleep Monitor, i’ve updated an App that exports Zeo data from Android, compatible with the above, and have published to the play store


If anyone wants to test it out, i’d be more than happy to make any adjustments :slight_smile:


sweet! Worked for me. i had tried another similar app, but it crashed every time i tried to export.

Now for the complex bit. I’ve been talking with a friend, and we are wondering if there is a way to intercept the raw data from the headband as it gets to the phone, and work with the raw EEG data instead of the ZeoAPI. Thoughts on if this is possible or not?

I’ve thought about that - and tried to decompile the Android app to do so - without any luck.
It think we’d need someone with experience in analyzing the Bluetooth protocol to have any success with this.

The public API seems to just be an interface, and doesn’t have any usable information about how the Bluetooth connection is negotiated.

My biggest concern with relying on the Zeo app is that it might one day vanish or become incompatible with current android phones. It would also be nice to get the raw data :slight_smile:

May i make a feature request for the export App you made? Is there a way to have it export to a google drive sheet? Or have it run automatically on a daily schedule? I was able to export the data last night, got excited, and ended up staying up way later then i should have, tanking my sleep data for last night :sweat_smile:

Very cool.

I would suggest exploring making its functions available to the Tasker App, perhaps as a Plugin, so that it could be scripted and automated as a tool.

I “noticed” the original APK for MyZeo isn’t encrypted or obfuscated in any way. I don’t know if that’s a symptom of the age of the app, or whether it was intentional. Its just a little hard to not notice. – so I wouldn’t worry if the app stops working in later versions of Android (in theory) you “could” recompile it.

I know - I have the same qualms, but we can hope that by the time our current Android devices die, there is a suitable replacement product on the market - hopefully with an open API this time!

https://emotiv.com/ and http://australia.foc.us/quantum-8-eeg/ may come up with something interesting!

I’ve just about given up on working out why I can’t open a Bluetooth socket to the Zeo, perhaps it needs some ‘magic packet’ or some other means of authentication, perhaps like port knocking or something…
I’ve spent hours reading through their code and trying to replicate the connection, with no luck!

I may give it a go on Xcode, but I don’t even have a copy of that app to begin with.

I’ll work on adding export to gdocs, as well as a scheduler.
I had never worked with Android Apps before Saturday, so bare with me :slightly_smiling:

I’ll take a look appears straight forward rfcomm is being used. I assume you got that far and are having trouble eliciting a response “after” your connected?

Hi John,

I don’t know much (anything) about BT sockets, but when attempting to open a socket with the relevant service uuid, the connection just times out. When opening a listening socket there was no data received.

You can use dextojar and then jadx to decompile and have a read over the sources.

Let me know how you go!

A friend suggested running a virtual android device on a computer with a bluetooth adaptor and connecting to the headset that way to test capturing data, but i’ve never done any app development so I dont know what to do…

I got tied up cleaning up the bluetooth stack on my desktop, but found a few surprises. Most of the details are in todays blog entry at johnwillis.com - the short summary is Zeo is broadcasting two service profiles, one for iOS, one for Android. The big surprise though was on any phone that has the android Zeo app running. Those phones are also advertising a “Zeo Android” service.

sorry the forum tells me I can only post one image per reply
there are more in the blog post > Zeo Mobile, bluetooth let mein


Hi John,

Very impressive!
Are you going to persevere in attempting to communicate via BT?

If it helps, the Android BT service that is set up by the app appears to be generated by the class ‘BluetoothServer.java’ and is just an insecure rfcom socket.

All the best with the investigation, I look forward to the next blog posting :slight_smile:

Thanks Nicholas.

Yes I would like to pursue direct BT communication. But I am taking tonight off. Interesting about the BluetoothServer.java class, I don’t know Android well but i think that’s a general class from the SDK. Its a good sign if they reused it… it should be more predictable.

I found a German blogger who also noticed the BT on zeo, but apparently not the BT on a mobile. He also did a hardware tear down… its mostly in German though, but he posts some nice pictures (from 2011). My German’s Texas flavored… but he seemed to be really interested in accessing the raw data, but eventually gave up. He discovered the headband had an MCU with an ADC converter on chip and didn’t feel like hacking the firmware. He also tore down a Zeo dock for the headband but was disappointed to find it was mostly a USB 1.1 hub and charging station.

He also appeared to loose interest in 2013 when the company folded and moved on. Nothing since, and nothing more about BT.

Oder: Warum wir keine Rohdaten vom Zeo Mobile haben können.

Nice teardown post! His comments seem to confirm my suspicions, and the data is processed and converted on the headband before being sent to the phone, which means raw data will be unavailable without custom firmware. oh well =/

It should still be possible to have some sort of open sourced zeo mobile replacement application though, right? It would just have to hook into the bluetooth communication and interpret the pre-processed data from the headband? The headband might even be broadcasting that as the Zeo API?

It looks like a replacement for the Zeo Android app is possible. the key seems to be the SDP advertised UUID128 identifier. There are two of importance. One that the Android Zeo App is broadcasting (which the Zeo Headband “looks” for in order to at least dump its status… and possibly also the sleep records) and One that the Zeo Headband itself broadcasts, though I’m not sure what this is for… I am beginning to suspect the Zeo Headband only accepts incoming connections to update its firmware… or for minor maintenance… like test the LED light or turn it off… or notify it to clear its sleep record database. I just don’t know the particulars.

The problem is generating these UUID128 service identifers easily, there doesn’t appear to be an easy way… yet… the Linux bluetooth overlooked them and the BlueZ team seemed hostile or unfriendly when the subject was brought up… could be just developer grumpiness but its was typical Linux kernel dev style rudeness. Since thats a small marketshare… just would rather not go there. Windows XP did not really support third party development, Windows 7 looks possible. Apple is enthralled with its iAP substitute for all things Bluetooth and doesn’t seem interested in anything not pure Apple… again kind of an attitude problem with standards… so that effectively leaves Android and Windows 7 as the “friendly” to low effort development platforms.

Nicholas, any chance you could publish your ZeoCVS in the Amazon Appstore? A few people who listen to Security Now the podcast are using Amazon Fire tablets. Right now they have to root them to add in the Google Playstore. It would be a lot easier if they could just go to their native Appstore and get the app.

I think the directions are here

Publishing Android Apps to the Amazon Appstore

Hi John,

Looking good, you’re still making progress!
If it helps, this is a snippet from one of the classes in the Android app

public static final UUID ZEO_BT_ANDROID_UUID = UUID.fromString("56b32a76-479b-43d4-99ff-42d79823d0a5"); public static final UUID ZEO_BT_HEADBAND_UUID = UUID.fromString("56b32a76-479b-43d4-99ff-42d79823d0a6");

I think these may be the Bluetooth service identifiers?


Hi John,

Done - not sure how it will go, I haven’t got an Amazon Fire to test on - they’re a bit expensive here in Aus!!

Should be in the store tomorrow :slightly_smiling:

I’m also a SN listener… I think there will be quite a pool of IT-focused people with Zeo’s come of of the woodwork.
We might see some new and exciting apps.

I’ve been working on a new ‘Smart Alarm Clock’ that uses the Zeo headband.
There is one currently on GitHub, but the alarm it uses is just awful, and I don’t love the logic it uses.

If anyone can point me to a nice open-source alarm clock (android-java) that I can fork, i’d be more than happy to incorporate Zeo into it! :slightly_smiling:


There we go, the submission has completed.
Let me know whether it works :slightly_smiling:


1 Like

Nicholas, I got feedback that they could see it, had downloaded it and its working.


Not everyone wants to use them for tinkering, some just want to do health and well being efforts… which I can respect. We’re all an interesting mix… the people interested in the post-Zeo apocalypse. :smile:

On a different subject, Steve Gibson has voiced his interest in a full database share. I looked at the java contract in the open zeo github site… and it exposes five of twelve tables, and one table that is the result of a join of the other tables.

The three options for getting a share of the original database are:

  1. Use a rootable or SuperSU capable older Android - not practical for a lot of people
  2. Recompile the original Zeo app with same signatures as the ZeoCVS - not very secure
  3. Recompile the original Zeo app + Zeo share feature built-in (added to a menu)

I think the number 3 option lower effort and worth a shot.

I know some have used ADB to runas the original myzeo user and skamper away with the database… but setting it up is really a lot of effort and beyond most people.

So that’s why I think option 3 would be best… if possible.

Let me know what you think… or if you have it done really quickly… I’ll be poking around it just to see how hard it is. On the surface doesn’t look all that complex. Its not even understanding the existing code… its just extending existing code with one more menu option… then leaving the invocation up to whatever they already have as a helper.