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.