Android Wear Support

[jones139]

User @AroonPro is working on providing a version of OpenSeizureDetector that can use an Android Wear device instead of a Garmin watch. His version of the watch app is here: https://github.com/AroonPro/AndroidWear_SD/tree/SD_AW/BR
We will probably have a separate companion app to deal with communication with the Android Wear watch, which then sends data to the main OpenSeizureDetector app - the same way that Garmin Connect works for Garmin devices.

[jones139]

There has been some interest in this lately, so I thought I should set out where I think we are with AndroidWear support, and what our options are.

I think we have two draft Implementations using different approaches:

Analysis on Watch
User @AroonPro has a version which he is using which (I believe) is doing the seizure detection algorithm on the watch (https://github.com/AroonPro/AndroidWear_SD) and sending the processed data back to the phone for alarm generation (which is the same as we do for the old Pebble watches). I (Graham, @jones139) have not looked at what we need to do to get this working in V5.0.x)

** Analysis on Phone **
User @DylanGriffith has a prototype watch app which sends raw data back to the phone for processing (the same as we do for PineTime and Garmin watches). Version 5.0.x of the Android_Pebble_SD phone app has support enabled for Android Wear messages so we should be able to get this working.

Should we go with one or both of these approaches? Things to consider:

1. How is the battery life on the AndroidWear watches if we send data continuously? If it is causing battery issues, then analysis on phone could be sensible - that is why we did it that way for Pebble watches.
2. Do some AndroidWear devices have their own SIM cards? If that is the case we could avoid needing the phone app at all, and the AndroidWear implementation could be completely separate from the Android_Pebble_SD phone app.
3. Do we want to use Machine Learning algorithms on AndroidWear? If so we should go with Analysis on Phone so we only have to implement the algorithm in one place, otherwise we will have to maintain several implementations for different devices. Also, we are currently looking at using a Neural Network algorithm - can an AndroidWear device handle pyTorch models?

[Note that I know quite a few people are interested in AndroidWear support, so I (Graham) will help include it in the main phone app, but I am not really interested in putting any effort into it myself - I think the main development drive should be in getting a machine learning algorithm fully implemented to reduce the false alarm rate from the system, rather than trying to support more devices, when we know that the low cost PineTime watch works]

[AroonPro]

Yes new galaxy watch have eSim.
Also they have through bluetooth or wifi or router option in phone available.

That now messages are running through the Google cloud.

That is why I really want the ssh connection to be active.
We are too dependant on big tech.

With ssh, it is low profile and secure.

[jones139]

@AroonPro , Are you saying that the communication between the watch and the phone is going via Google Cloud Services? Surely not - that would imply you need an internet connection to have the watch and phone communicate? If that is the case, I'd suggest dropping Android Wear altogether!

[AroonPro]

It is not exactly running through the cloud. That is how I see it works.
With the ssh binding, the direct through approach Will be better.
Through Google messages on wear, it seems to be passed as Google cloud, but handled locally, before the cloud.

For that, I need to examine the docs.
For now, I try to rebuild, with SdData, SdServer, SdDataSource and osdUtil in uk.org.openseizuredetector. openseizuredetector class. Then there is only one point of truth.
However, with @jones139 pase of new versions, I need to push the project into the request. But health and trust issues hold me down.

[jones139]

The doucmentation here: https://android-wear-docs.readthedocs.io/en/latest/sync.html#:~:text=An%20application%20that%20runs%20on,First%20Wearable%20Message
Implies that it is a normal bluetooth communication without any cloud based layer - I suppose the way to check would be to switch off wifi and mobile data and check the watch and phone can still communicate.

[AroonPro]

Like I said.

It also uses the wifi or cloud routing.

This is a clever design

[AroonPro]

Certainly, Our plan is to use the android test harness with real physical data sets as benchmark. Also, have I been working on stripping SdServer SdData and SdDataSource from the android wear and pebble_sd app and moving that into openseizuredetector openseizuredetector Then, no discussion afterwards upon changes upstream in pebble_sd /SdData. Here comes a plus: wear watch becomes osd server. With that, we can use a ssh connection to cloudflare uid openseizuredetector openseizuredetector.co.uk for logging and with the same address as network source display real_time alarms on pebble_sd app. (this is the nuclear future feature, because it requires a certain bandwidth. I.e. Fiberglass/4g+) Met vriendelijke groet, A. A. F. M. (Bram) Regtien e: ***@***.*** m: +31614464152 a: Twentehof 13 5709 KM Helmond Op di 31 mrt 2026, 19:59 schreef Dylan ***@***.***>:

…

Thanks @jones139 <https://github.com/jones139> I've not had much time to look into this in a while. But I'll try to share my experience: 1. Battery was good enough the send interval was increased. Originally I was sending at 25Hz which drained the battery in a few hours. But sampling up to 10s or 30s should be fine for a full day. 2. Yes some do but I don't have one. The implementation I have is fully dependent on the mobile app and I wasn't really interested in building the complete app on Wear. I also don't know the battery usage for doing this kind of computation on the watch. 3. Yes we should use the best/tested algorithm. And yeah that's fine if it's on mobile. I hope that I can get back to testing the AndroidWear app again soon but I stopped testing it because it was constantly sending false positives. And I didn't really get to the bottom of that. I was observing weird cases where an SMS would be sent but I never even heard it beep (and the beep settings were on as I heard them sometimes). All that was making it a problem to test and I didn't really know the codebase well enough to debug why. Possibly it was just my settings. With that being said I think the biggest thing I'd want to know to put the effort into the AndroidWear app is how we can be sure the Machine Learning algorithm inputs are equivalent for Android Wear and Garmin. If all the training data is Garmin and there are some quirks that are different I'd be worried we risk either have false positives or no detection at all. False positives we can learn about but no detection at all seems to be a worse problem and I'd assume we need more data to test that. But maybe you have ideas about how to address this problem? — Reply to this email directly, view it on GitHub <#69?email_source=notifications&email_token=AV6J747SKFQYOACKNGYCN4L4TQBRPA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRTHE4DMMBVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16398605>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AV6J743UGUMB2YZV6XIHGA34TQBRPAVCNFSM6AAAAACW26YBKKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMMZZHA3DANI> . You are receiving this because you were mentioned.Message ID: <OpenSeizureDetector/Android_Pebble_SD/repo-discussions/69/comments/16398605 @github.com>

[jones139]

Hi Bram,
I don't think you need to change very much in the OSD phone app to achieve what you want. If you process the data on the watch and send it to the phone with a flag to make it clear that it is pre-processed, we can handle it like we do data from the old Pebble watches (which also did on-watch processing).

Then the SdDataSourceAW on the phone app just needs to read the message, and determine if it is raw or processed data. If it is raw data, we collate into a 5 second SdData instance and call doAnalysis() to process it. If it is processsed data, we will bypass the analysis part and go straight to generating alarms.

I think the remote data access is a separate issue to AndroidWear isn't it? It should not matter which data source we are using. Maybe we should start another discussion about options for that, as we know a couple of people are using it over VPNs, and I think your idea will avoid the need for a VPN?

[AroonPro]

Hi Bram, I don't think you need to change very much in the OSD phone app to achieve what you want. If you process the data on the watch and send it to the phone with a flag to make it clear that it is pre-processed, we can handle it like we do data from the old Pebble watches (which also did on-watch processing). Then the SdDataSourceAW on the phone app just needs to read the message, and determine if it is raw or processed data. If it is raw data, we collate into a 5 second SdData instance and call doAnalysis() to process it. If it is processsed data, we will bypass the analysis part and go straight to generating alarms. I think the remote data access is a separate issue to AndroidWear isn't it? It should not matter which data source we are using. Maybe we should start another discussion about options for that, as we know a couple of people are using it over VPNs, and I think your idea will avoid the need for a VPN?

This is about it. Where VPN is good, it is always a struggle with naming servers. Re binding through ssh, cloudless to new interface ipv6 at openseizuredetector.co.uk, we have our automatic twin direction, zero config data connection. With absolute privacy and ddos protection. User compartination guaranteed. In this configuration, group access to user database per account with anonymised health data sharing enabled will be possible. —

…

Reply to this email directly, view it on GitHub <#69?email_source=notifications&email_token=AV6J746ZXNKHOKKX6TBPMN34TVNRXA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNRUGEZTAOJRUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-16413091>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AV6J745A6BLOPIPF4A5JPCD4TVNRXAVCNFSM6AAAAACW26YBKKVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTMNBRGMYDSMI> . You are receiving this because you were mentioned.Message ID: <OpenSeizureDetector/Android_Pebble_SD/repo-discussions/69/comments/16413091 @github.com>