Direct connect between Pixel Watch 2 and Dexcom G6 not working via xDrip

[t0st]

Hey there!

I bought a Pixel Watch 2 for my kid to replace the bulky mobilephone he needs to take with him for the cgm readings atm.

At first the mobile phone with android 14 paired successfully with the dexcom g6 sensor and also the cgm readings were displayed on the google pixel watch 2 (with wearos 4) without problems.

But as soon as the setting "Force Wear Collection Service" gets enabled the readings stop and the watch cannot properly create a connection to the sensor.

I already tried to shutdown the phone, restarted the watch multiple times, resetted the watch multiple times but the connection can't get established.

Is there anything I can do to fix this? I read somewhere that ppl were able to connect their pixel watch 2 with xdrip to the g6 sensor a few months ago, did something change here in the meantime?

Im currently running the lastest build of xDrip, version aee9315-2024.09.19.

Thats the log part the comes from the watch during trying to create a connection to the sensor:

eng.nobody.20240912.034222
aee9315-2024.09.19
Disabled
===

Log data:

ALL

2 ^ 2024-09-21 13:14:06 ^ wearjamorham listener ^ syncBGData existing BgReading calibrationUuid not found by byuuid; calibrationUuid=null bgData.calibration_uuid=null bgData.uuid=075ea54a-cfb0-45ad-8243-d1037a98858c timeString=2024-09-21 12:29:36
1 ^ 2024-09-21 13:18:32 ^ wearOb1G5CollectionService ^ Enable bluetooth and try again com.polidea.rxandroidble2.exceptions.BleScanException: Bluetooth disabled (code 1)
5 ^ 2024-09-21 13:18:33 ^ BluetoothHeadset ^ Bluetooth Audio disconnected: Google Pixel Watch 2 XXXX
94:45:60:A1:D7:0A 1f00
2 ^ 2024-09-21 13:18:34 ^ wearOb1G5CollectionService ^ Trying to Turn Bluetooth on
5 ^ 2024-09-21 13:19:45 ^ BluetoothHeadset ^ Bluetooth Audio connected: Google Pixel Watch 2 XXXX
94:45:60:A1:D7:0A 1f00
2 ^ 2024-09-21 13:19:50 ^ wearjamorham listener ^ syncBGData existing BgReading calibrationUuid not found by byuuid; calibrationUuid=null bgData.calibration_uuid=null bgData.uuid=075ea54a-cfb0-45ad-8243-d1037a98858c timeString=2024-09-21 12:29:36
2 ^ 2024-09-21 13:24:23 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @3
2 ^ 2024-09-21 13:24:23 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @4
2 ^ 2024-09-21 13:24:24 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @5
2 ^ 2024-09-21 13:24:24 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @6
2 ^ 2024-09-21 13:24:24 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @7
2 ^ 2024-09-21 13:24:24 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @8
2 ^ 2024-09-21 13:24:24 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @9
2 ^ 2024-09-21 13:24:25 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @10
2 ^ 2024-09-21 13:24:25 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @11
2 ^ 2024-09-21 13:24:25 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @12
2 ^ 2024-09-21 13:24:25 ^ wearjamorham exec ^ 13:24 Task deadlock on: sendData! @13
2 ^ 2024-09-21 13:24:44 ^ wearjamorham listener ^ syncBGData existing BgReading calibrationUuid not found by byuuid; calibrationUuid=null bgData.calibration_uuid=null bgData.uuid=075ea54a-cfb0-45ad-8243-d1037a98858c timeString=2024-09-21 12:29:36

It seems like the log message "Task deadlock on..." comes from here:
https://github.com/NightscoutFoundation/xDrip/blob/master/wear/src/main/java/com/eveningoutpost/dexdrip/utilitymodels/PlusAsyncExecutor.java#L90

and the qsize got reduced to 2 for watches instead of 10 like on the phone but i cannot say if thats the root cause or there is anything else.

[t0st]

Ok I reset the watch, deleted xDrip and made a fresh installation. The watch still won't connect to the g6 sensor but now I get this errors in my log:

aee9315-2024.09.19
G6 Native
===

Log data:

ALL Search: 


2 ^ 2024-09-23 18:44:49 ^ wearOb1G5StateMachine ^ authentication notification  throwable: (CHECK_AUTH) com.polidea.rxandroidble2.exceptions.BleDisconnectedException: Disconnected from MAC='XX:XX:XX:XX:XX:XX' with status 0 (GATT_SUCCESS) 2024-09-23 18:44:49
2 ^ 2024-09-23 18:44:49 ^ wearOb1G5CollectionService ^ Error count reached: 25
2 ^ 2024-09-23 18:44:49 ^ wearOb1G5StateMachine ^ Could not read after AuthRequestTX: com.polidea.rxandroidble2.exceptions.BleDisconnectedException: Disconnected from MAC='XX:XX:XX:XX:XX:XX' with status 0 (GATT_SUCCESS)
2 ^ 2024-09-23 18:44:51 ^ wearOb1G5StateMachine ^ authentication notification  throwable: (CHECK_AUTH) com.polidea.rxandroidble2.exceptions.BleDisconnectedException: Disconnected from MAC='XX:XX:XX:XX:XX:XX' with status 0 (GATT_SUCCESS) 2024-09-23 18:44:51
2 ^ 2024-09-23 18:44:51 ^ wearOb1G5CollectionService ^ Error count reached: 26
2 ^ 2024-09-23 18:44:52 ^ wearOb1G5StateMachine ^ Could not read after AuthRequestTX: com.polidea.rxandroidble2.exceptions.BleDisconnectedException: Disconnected from MAC='XX:XX:XX:XX:XX:XX' with status 0 (GATT_SUCCESS)
2 ^ 2024-09-23 18:44:46 ^ wearOb1G5StateMachine ^ Could not read after AuthRequestTX: com.polidea.rxandroidble2.exceptions.BleDisconnectedException: Disconnected from MAC='XX:XX:XX:XX:XX:XX' with status 0 (GATT_SUCCESS)
2 ^ 2024-09-23 18:44:46 ^ wearOb1G5StateMachine ^ authentication notification  throwable: (CHECK_AUTH) com.polidea.rxandroidble2.exceptions.BleDisconnectedException: Disconnected from MAC='XX:XX:XX:XX:XX:XX' with status 0 (GATT_SUCCESS) 2024-09-23 18:44:46
2 ^ 2024-09-23 18:44:46 ^ wearOb1G5CollectionService ^ Error count reached: 24
2 ^ 2024-09-23 18:39:47 ^ MissedReadingService ^ Aggressively restarting collector service due to lack of reception: backoff: 240
2 ^ 2024-09-23 18:34:51 ^ wearOb1G5CollectionService ^ Switching to scan always mode due to connect failures metric: 0
2 ^ 2024-09-23 18:33:47 ^ MissedReadingService ^ Aggressively restarting collector service due to lack of reception: backoff: 180
2 ^ 2024-09-23 18:27:47 ^ MissedReadingService ^ Aggressively restarting collector service due to lack of reception: backoff: 120
2 ^ 2024-09-23 18:15:47 ^ MissedReadingService ^ Aggressively restarting collector service due to lack of reception: backoff: 360
2 ^ 2024-09-23 18:15:07 ^ wearOb1G5StateMachine ^ authentication notification  throwable: (CHECK_AUTH) com.polidea.rxandroidble2.exceptions.BleDisconnectedException: Disconnected from MAC='XX:XX:XX:XX:XX:XX' with status 0 (GATT_SUCCESS) 2024-09-23 18:15:07

Edit:

I also tried to build the apk on my own.. the gradle build succeeds and the apk has aprox. the same size as the nightly (15.3 mb) but the apk fails to get installed on the phone...

Ok I managed to build and install the apk (forgot to sign on the first try).

I discovered that the wear device uses another endbyte for the authrequest message:
https://github.com/NightscoutFoundation/xDrip/blob/master/wear/src/main/java/com/eveningoutpost/dexdrip/g5model/AuthRequestTxMessage.java#L19

Does this mean the wear device tries to use the first bluetooth channel of the sensor instead the second like the phone?

Edit2: ofc. this means the alternate bt channels gets used. Is the decision to use it crucial to any feature in xdrip, afaik there isn't a state where both phone and wear device are both connected simultaneously to the sensor right?

[Navid200]

No one has addressed WearOS issues and requirements for a very long time.
Direct collection of WearOS from Dexcom has never been a success. I have seen claims of some watches collecting once every 10 minutes instead of 5.

There are very small phones that some parents send their kids to school with.
There is BlueJay. But, it is very large and heavy for a child. https://bluejay.website/shop/product/bluejay-u2-28

I don't have a solution for you. I'm just telling you my limited knowledge of what is available.
BlueJay is fantastic. It doesn't just work with G6. It also works with G7. If it was smaller and lighter, it would be a godsend.

The problem is that it is not supposed to just work. It has to work reliably. BlueJay does.

I mean let's say you figure out a way to improve WearOS direct collection. What will you do when your child switches to G7?
I'm sorry I don't have any suggestion.

[t0st]

No one has addressed WearOS issues and requirements for a very long time.
Direct collection of WearOS from Dexcom has never been a success. I have seen claims of some watches collecting once every 10 minutes instead of 5.

Ok that explains alot, seems like most of the grown-ups dont mind missing this feature because they have their phone in reach almost every time.

There are very small phones that some parents send their kids to school with. There is BlueJay. But, it is very large and heavy for a child. https://bluejay.website/shop/product/bluejay-u2-28
I don't have a solution for you. I'm just telling you my limited knowledge of what is available. BlueJay is fantastic. It doesn't just work with G6. It also works with G7. If it was smaller and lighter, it would be a godsend.

Well bluejay does not sell any watches in the last months, the old ones are sold out and the new ones are still in beta state.

The problem is that it is not supposed to just work. It has to work reliably. BlueJay does.

Isn't that the case with every feature of xDrip? I mean in the end (and ofc, everybody reads and agrees to the disclaimer at the start of xdrip but anyway) lives depend on it. At least lives get more comfortable with it.

I mean let's say you figure out a way to improve WearOS direct collection. What will you do when your child switches to G7? I'm sorry I don't have any suggestion.

Well there's a pretty simple answer to this question: make direct connect also work with g7 sensors ;-)

I can confirm that I got a first pairing and bg state from the watch after changing the bt channel.
There also appeared a few other errors in the log file. I'm gonna try to fix these and then we test the reliability of the connection. Now that the watch also has LTE we will also test the upload feature to nightscout (if we succeed in all previous steps).

[t0st]

Ok, it seems that the direct connection from the Pixel Watch2 (WearOS 4) is now working reliably with a few changes in the wear code.

I had to update a lot of classes to reflect the changes of the last 3-5 years.
I also had to tweak the "automata" switch case to prevent the watch from unbinding. Otherwise, the user has to manually confirm the pairing every 5 minutes via the pairing dialogue.

We'll be testing the feature with our watch over the next few days/weeks and if everything goes smoothly, I'll provide a PR for it.

I'm also going to implement the nightscout upload feature directly from the watch, as this is crucial for us as parents.

[thepartisan]

You are gold! My son has to switch from Libre to Dexcom due to transition to a pump and the old solution with libre+juggluco on a Pixel 2 LTE w/o phone was just perfect. Knowing a phoneless setup is also possible for Dexcom is relieving. In case you need a set of eyes for review or fixes, let me know.

[t0st]

Nice to hear! I finished the nightscout upload feature on the wearos app a few days ago and we successfully tested it without major issues this weekend!
I'm gonna commit the code to my fork later and clean it up to get it ready for a PR.

[thepartisan]

We just received our first dexcom G7. I've built your PR but unfortunately it seems there is still work to be done for G7. I've played around for a few hours, but scanning via watch never seems to find anything.
Migrated a few spots that seemed G7-relevant from 'app' changes to 'wear', but without success.
Do you have a hint for me where to start? Would I need to cherry-pick all the OB+ changes for G7, too?

Do you get some pairing popup on your watch for G6 or is that supposed to happen automatically?

[t0st]

Unfortunately, after more extensive testing, we found a problem. Uploading to Nightscout only worked sporadically when the phone (bluetooth) or a known wifi was nearby. Over LTE, the upload was very erratic and only succeeded every few hours at most.

I am now implementing several checks for an active network and prioritising the cellular network so that the upload is done every 5 minutes as usual.

Unfortunately, the problem is still difficult to analyse because if I want to see the log data on the phone, the bluetooth connection immediately takes over the transfer of the upload data to nightscout and no longer the cellular network directly.

I am currently working on a small display view of the log data directly on the watch, so that a connection to the mobile phone is not necessary.

[t0st]

Ok, it took a lot of work, but in the end it works as I want it to.

Originally it could only connect to the nightscout host when xdrip was started on the phone. Unfortunately, prioritising and re-establishing the cellular connection on the clock did not work.

I found out that the data packets which are sent from the 'cell phone xdrip app' with the flag “urgent” via wear data-api to the watch virtually wake up the lte connection again.

Since the data packets sent via the data api are sent to all nodes, I have now used this mechanism as a workaround:

• First the connectivity gets checked
• If no network is available a new networkconnection gets established via NetworkManager (cellular or wifi with internet capability only)
• Right after this we send a packet from the watch with the "urgent" flag and read it ourself on the watch using the "onDataReceived" method (a kind of "SelfPing" or "SelfWakeup")

And it seems to work fine! Even when the xdrip application is completely deactivated/removed on the mobile phone, the watch now sends data to nightscout every 5 minutes! We will be monitoring the battery consumption over the next few days, so it may be possible to tweak things a bit.

[t0st]

@thepartisan sorry for the late reply.

The following steps work reliably for me and succeed every time to get the watch paired correctly:

• Enter your settings in your xDrip phone app (Sensor type, Transmitter SN, Nightscout Url, Alarm Thresholds etc etc)
• Make a first pairing to the sensor via PHONE
• After this paring enable Android Wear Integration, Enable Wear Collection Service , Force Wear Collection Service and Only use Wear settings
• The first BG reading from the Phone should get syncec and displayed on your watch, the watch now also knows the mac of your sensor and the collection service on the watch starts
• Switch to the "System Status" screen on your xDrip phone app and swipe right to see the status of the collector and your watch
• The status should tell you that your watch tries to bond/get glucose values of your sensor
• On the first time it sometimes takes 15 - 20 min to get the first reading via watch, be patient

If this does not work then enable log sync in the wear settings of your xDrip phone app and insert the following logging tags:

wearjamorham exec:d,wearOb1G5CollectionService:d,wearOb1G5StateMachine:d,jamorham exec:d,Ob1G5CollectionService:d,Ob1G5StateMachine:d

Save the log and add it here, maybe I can identify the issue then.

[t0st]

Update: our Pixel Watch 2 received the WearOS 5 update two weeks ago.

xDrip is still working reliably and the Battery lasts longer with the new OS version. Also a bug got fixed that sending of data to Nightscout was not possible after a networkswitch from LTE to Wifi or vice versa. This works really smooth now and the battery lasts approx 14hours (2-3 hours longer as on WearOS4!!) which is long enough for our usecases.

I'm update my branch to the latest master and test if the selfping workarounds are still needed on WearOS5 or can get removed (this should reduce the battery consumption of the app even more).

[Jakko3]

Hey @t0st, thank you very much for settings this up. That's very promising!

I'm helping a friend with the same setup (Pixel Watch 2 on WearOS 5, G6 sensor). I built and installed the current state f6c6778 of your pull request #3719 on the phone and thereafter on the watch by "Wear Installer 2" app. Transmitting BG data from the phone to the watch works. However, the stand-alone "Force Wear Collection Service" doesn't connect the watch with the sensor. I tried to follow the recommended procedure (https://xdrip.readthedocs.io/en/latest/smartwatch/wear/#recommended-sequence). The following log picture (click to enlarge) shows the output after checking "Enable Wear Collection Service" and shortly threafter "Force Wear Collection Service". In the picture I anonymized the transmitter ID, it consists of six characters/digits, they match with the transmitter ID shown in the status page. I didn't check "Only use Wear" but the devices (phone, watch, sensor) were close to each other, so it shouldn't matter to my understanding.

Unfortunately I don't have a device to debug myself, just having the logs and trying to follow the plain code. The current state of the wear-specific file "Ob1G5CollectionService.java" in your pull request is:
https://github.com/NightscoutFoundation/xDrip/blob/f6c677894da470cb7d511b8b0d6d52e89e6e6ca2/wear/src/main/java/com/eveningoutpost/dexdrip/services/Ob1G5CollectionService.java

For logging we disabled level "Mid", this floods the log by sendMessagePayload Sent request messages, you seem to have it raised by one level in ListenerService.java. Still there is lots of spamming by message New thread: sendData, which seems to come from PlusAsyncExecutor.java, but we kept as many log levels active as possible. The log capture starts when we checked "Enable Wear Collection Service". I don't know why the initialization happens twice, possibly because we checked "Force Wear Collection Service" a couple of seconds later. Looks like the initialization passes successfully, it goes from INIT to SCAN in function automata(). There it first processes useMinimizeScanningStrategy() but it needs scanning and therefore goes into scan_for_device(). It passes through this function, issuing log line Scanning for: Dexcom[...]. I don't properly understand how the scanning works but I assume the scanSubscription = new Subscription(rxBleClient.scanBleDevices(... runs in the background, supposed to go either through onScanResult or onScanFailure. However, in the log nothing happens for the next five minutes until the wake-up call comes and repeats the procedure. Same after another five minutes. The log picture shows 10 minutes only but we waited longer without noticing any change in behavior.

Actually up to the scanning it looks good. But it doesn't seem to be able to find anything or maybe is unable to connect to anything. Or maybe something wrong with the filter for devices. Accordingly it's also unable to populate a MAC address, I guess.

Next thing I did was comparing the wear-specific file "Ob1G5CollectionService.java" with the regular file "Ob1G5CollectionService.java" in app/src/main/java/com/eveningoutpost/dexdrip/services. There are several small differences but I didn't spot anything specifically suspicious. I stopped investigation on the differences of those two files... though I can pick it up again if it's worth.

Do you have an idea what's going wrong? Or any debug suggestions? Is there any specific WearOS settings in the watch to enable for allowing it to pair with the sensor? Also maybe it's worth to mention that the firmware version of the sensor in xDrip+ is "unknown" in the current state of the pull request (but would be available in latest nightly commits). Besides that, your pull request was written and tested for WearOS 4, is it supposed to run on WearOS 5 without changes?