Switching over to look at the [ zeo android ] service on the Mobile app using linux, sdptool retrieves:
I tried connecting to the [ zeo android ] service with rfcomm from linux.
Each time the Zeo Android app on the mobile device indicated a state change in the Headband and then a loss of connection as something closed the connection. Presumably the Zeo Android app.
This leads me to think that the [ zeo android ] service is actually a server waiting to hear from the Headband with concise reports and state changes.
Reversing this state of affairs, it should be "possible" to setup a similar service on a PC to listen for reports from the Zeo Headband, and thus receive whatever it has to communicate.
[One Step Beyond ]
Tried connecting a 'Serial Over Bluetooth Link' driver to the Zeo Android service on the mobile app, which produced a COM6 port on the PC. Then used PuTTY to open the port, and this is what appeared:
Further the Zeo App indicated a Headband was now connected:
The Zeo Android app [ Diagnostics page ] indicated it was the Windows PC connected, but apparently part of the connection proctocol from Zeo sends its status, which the Zeo Android app decoded as not very useful.
Closing the PuTTY connection to the Zeo Android app Serial port on COM6 immediately changed the Headband status:
So it appears the [ Zeo Android ] service is the 'Headband' service, and it appears we can 'fake' a Headband module connecting over Bluetooth by using a Windows, Linux, or OSX connection.
A little more investigation.
Bluetooth development on many platforms is at various stages of ease.
Linux has tools for starting a listener on a particular RFCOMM channel and connecting that to a device in its /dev inventory. The BlueZ stack which was in then out, then in again, in the Linux Kernel has commandline tools for changing the SDP service record for a service.. but lack an important feature. UUID16 for a service can be changed with the Linux tools, but not a UUID128.. which is what the Zeo App on Android is using.
The reason is because the Bluetooth SIG organization recommends using UUID16 for commonly defined bluetooth services that everyone provides with their default bluetooth development "stacks" but also recommends creating a unique UUID128 "waay out there" so as not to accidentally collide with someone elses service. So if your developing on your own and inventing the latest Bluetooth service application.. they would appreciate it if you do it in "another solar system" please.
The Linux command line tool sdptool will let you define UUID16 even UUID32 or a string, but not UUID128. The reasoning went something like "well that's kind of fringe, and don't bother me.. I'm busy writing code.. " -- really it wasn't as nice as that.. but .. yeah.