Complication displays permanently null null ()

[zackallan]

After reinstalling the xDrip+ app on my Ticwatch E the complication on the watch face fails to display the measurement values. OS watch: Android Wear 2.8.0 Android 7.1.1 watch: xDrip+ build 8d09da5-2018.02.11 version 1.0.2 OS phone: Android 8.1.0 phone: xDrip+ build 8d09da5-2018.02.11

[gregorybel]

did you try to reboot both watch and phone? is android wear activated under xdrip settings? can you try clicking complication to force update? can you reconfigure (select again xdrip) complication under the watchface settings?

[zackallan]

@gregorybel Thanks for the tips. I did reboot on both the phone and the watch. Android wear is activated as described in the manual. I did reconfigure the complication. Unfortunately these steps did not solve the problem. Clicking the complication does not show any reaction.

[gregorybel]

then need to pass! or maybe you should look at the inter-app settings.

one thing is sure, it works for me.

[ins5736]

I'm running the 2/13 Xdrip nightly/1.58 NSClient as a follower. Data works on the dedicated Xdrip watch faces, but not on the complication.

The complication works for my wife who is running Xdrip as a collector and uploader. We both have Ticwatch e watches.

[jamorham]

Okay I think this bug report is that complication doesn't work on the follower device. It is possible because of how the sync works.

[ins5736]

Yes, that's correct. The complication works perfectly for my wife using the uploader phone.

[zackallan]

It would be interesting how the synchronisation works here. In my case there is no Nightscout involved in the dataflow. xDrip+ on my phone sends the data directly to the watch.

[ins5736]

Sorry for the confusion. I'll start a different issue.

[gitanO0]

Just just looking at getting a Ticwatch e. Is this watch compatible with xdrip+ G5 setup?

[ins5736]

Displays data for my wife, but she hasn't used it for a collector.

[jamorham]

Please try the May 11th Nightly. This should now be resolved.

[zackallan]

Updated to May 11th Nightly and complication still displays "null null ()". But as mentioned above I am not using my phone as a follower device.

[jamorham]

related: https://github.com/NightscoutFoundation/xDrip/issues/325

[jamorham]

@zackallan did you refresh the watchface? It doesn't auto-update on wear 2.0. You need to go in to Apps on the watch and uninstall it and then in to play-store on watch and reinstall it.

[zackallan]

Yes, I reinstalled the wear app. Current version on watch is 0acd72c-2018.05.11

[jamorham]

@zackallan can you describe your setup in more detail, what data source are you using. It must be a different issue to the one I recently fix regarding the complication on watches connected to follower handsets.

[zackallan]

@jamorham I am using Blucon to collect the glucose data. The phone runs the collection service and sends the readings to the watch. The first time I was using xDrip+ on the watch the complication seemed to work properly. But after reinstalling the wear component the bug appeared.

[mbush91]

@jamorham Also receiving null null on my watch-face complication. Currently using a Pixel 2 w/ the dexcom G6 and a Misfit Vapor watch. Version:f20d8da-2018.05.30

Let me know if you need any more info!

[tgessendorfer]

Same here.... Oneplus 6 on Android 8.1 and a Fossil Q Explorist 3 with xDrip+. Using the xDrip Provider on the Smartphone before very nicely but since a couple of weeks I only get "NULL/NULL" on any Watchface. The xDrip Watchface though shows the BG levels nicely and works fine. However I would like to use a different watchface and setup a content area with the BG levels by using the xDrip Provider.

[zip9]

Hello - was this ever resolved? The complication worked fine, but has not since the snooze function was changed. Is there a work around? Thanks

[gregorybel]

Hi all, I have same issue with aaps as data source, I tracked the issue and found a workaorund, see my branch rebase on current xdrip master:

https://github.com/gregorybel/xDrip/commits/gregorybel-workaround-complication-null

Maybe you want to try it and check wether it solves issue for you too. But please note this is only a dirty workaround, not a proper solution.

Maybe this will help somebody else find the correct solution.

Gregory

[RayJayVaughn]

Sorry to say but the workaround does not work for me because I do not have a clue, integrating or reparing it within my installation.

How do I fix it? Which way do I have to take step by step?

I got exactly the same issue as most of the other guys. I am using

• TicWatch or Asus Zenwatch 3 (current wos versions)
• Xdrip+ ( latest release as well as latest nightlies)
• Xdrip Source is share follower (- As a share follower the workaround of calibration does not work)
  • And yes. It is the same issue mentioned in #1404 or #325. The setup / sources might be different but the issue null/null is the identical one.

I would be very pleased if this could be fixed cause this hybrid usage of original dexcom app an xdrip has some advantages. It is a real pity that this hasn´t been solved after years.

Thanks in advance

[CoreyAFraser]

@gregorybel I tried to do a little digging, but being unfamiliar with the project makes this a bit daunting.

However the issues that I think that I'm seeing are these: 1 - In ListenerService.onDataChanged() I'm not ever seeing the path WEARABLE_BG_DATA_PATH ("/xdrip_plus_watch_bg_data") come through. I didn't have time to figure out why thats not happening, though I may take another look. 2 - As a result BgReading.save() is never called and then nothing is in the db for the CustomComplicationProviderService to read from

I believe that the difference for the watch faces is that the bg data that is displayed on the watch faces is just directly transmitted in an Intent, read and then displayed completely avoiding the db.

As to why this seems to only affect when users are using XDrip+ in follower mode, I have no idea.

[gregorybel]

@RayJayVaughn you need to look at this commit

https://github.com/gregorybel/xDrip/commit/b9f13cbf15f711929a6a9ae98c82627c2d37f9c1

modify localy, compile and build.

@CoreyAFraser did you look at my workaround? https://github.com/gregorybel/xDrip/commit/b9f13cbf15f711929a6a9ae98c82627c2d37f9c1

Maybe this can help you finding root cause.

[CoreyAFraser]

@gregorybel I saw your workaround, I believe the reason that its no longer working is what I explained. The syncBgData method is never called due to never receiving WEARABLE_BG_DATA_PATH, so the code you've edited is never called.

I haven't had a chance to debug the phone side of the equation and see why this is never sent.

[gregorybel]

actually the code I have edited is called, otherwise workaround would not work but some reason this check returns false:

if (bgData.source_info != null && bgData.source_info.contains("Native"))

But definitly if you can debug on phone, you might better understand. Good to see that you want to fix this old and annoying issue.

[CoreyAFraser]

Several people have reported that your workaround does not work for them, it did not work for me. I'm just sharing what I found and why things appeared to not work for me.

Is your workaround based on master or another branch? I've been debugging master

[gregorybel]

indeed, I use a version from april 2020 so might be that something else has broken the workaround.

As far as for other peaple, I understood they did not know how to proceed to include workaround, but if you know it and it doesn't work, sorry for that, you need to find another workaround now.

[CoreyAFraser]

If I have time tonight, I'll check on your branch specifically. I might run a diff between it and master to see what might have changed.

I would much prefer to find a resolution in the latest code so that people can stay up to date.

I appreciate you working on this as it would have taken me WAY longer to find where this code was without your workaround.

[CoreyAFraser]

@gregorybel I just noticed the PR title, I think there might be a few bugs here. I'm using Dexcom Share as the source which is different than the bug you said you were addressing.

Other people have reported that if you use XDrip+ as the collector complications work for Dexcom users, but not as a follower.

If you are using 640G, I wonder if the logic differs enough to cause different behaviors? This project is huge, so it wouldn't surprise me if that was the case. It would also explain why the workaround might work for you and not others.

[skavan]

Hi, is there any update on this? I am using xdrip ==>640G==>Dexcom. xDrip watch faces work. but the complication/provider doesn't : null/null. Galaxy Watch 4 Classic. wear os 3.

[skavan]

Hi, is there any update on this? I am using xdrip ==>640G==>Dexcom. xDrip watch faces work. but the complication/provider doesn't : null/null. Galaxy Watch 4 Classic. wear os 3.

To reply to myself -- I downloaded latest nightly, made the adjustment suggested by @gregorybel and hey presto it's working. It's almost certainly related to me using Eversense/640G which feeds off the Dexcom app.

Now if I could get rid of the arrow and color code the text, I would be a very happy chappy.

[JasonJShuler]

If you have a moment to try out the PR - it's working for me.

Root cause is two-fold. Thanks @gregorybel for identifying one issue that caused nulls if you had no calibrations (pretty common with G6). I just gave it a spit-shine 😁

The other is a nullPointerException in BgReading.getByUuid() when it is called with a null parameter. Presently the uuid field isn't populated on the phone for Dex share follow or NS follow. This was causing the BgReading collection to always be empty, so BgReading.last() always returned null.

(The watchfaces work because they are not dependent on the BgReading collection)

We either need to check for nulls and return null, or make sure all the sources populate the uuid field. I assumed we would rather have all the sources function the same - with UUIDs - but if this was incorrect I can switch it to a null check.

[vin]

This seems to be sensitive to which hardware data source is selected. When using xdrip sync follower, it always shows "null null ()". Switching it to nightscout follower made it appear for me.

I've only just started looking at the code and the names of the DexCollectionTypes aren't clear to me yet, but looking at getCollectorServiceClass I think maybe there's just no implementation for an xdrip sync follower? Seems like a good default would be to just get whatever latest BG values the phone app has, no matter which hardware source the phone was using.

[vin]

In my logs I see:

syncBGData new BgReading calibrationUuid not found by byuuid; cannot save! calibrationUuid=null bgData.calibration_uuid=null bgData.uuid=... timeString=2022-08-07 16:07:02

(there is a real bgData.uuid; I just didn't type it in and didn't have an easy way to copy-paste.)

So this does seem like it's failing this check:

if (bgData.source_info != null && (bgData.source_info.contains("Native") || bgData.source_info.contains("Follow")))

here in ListenerService

[vin]

Looks like when we get a "bgs" message from GCM, nothing ever sets the source_info; it's just gets whatever value was set in the incoming gcm message, if any. That doesn't sound right -- I think it should note that this packet came via xdrip sync. Specifically in this case the ListenerService shouldn't care about calibrations. It should just use the BG values it gets through the sync group.

[dreimer1986]

Same problem. Galaxy watch 5 Pro and Pixel 7 Pro. Used xDrip: 05. Nov 2022 build on both devices. Watchface works fine. Complication is null two times. I use Libre Bluetooth as source. Android Wear support and Collection service is active on both devices. Force is disabled as it seems to interfere with the Bluetooth connection to the Freestyle Libre sensor.

[davidmtml]

Just here to mention that I am still experiencing this problem.

[apexcomputersaus]

@jamorham Still having issue on lastest nightly build config: My phone is xDrip follower (my son's phone is collector) xdrip watchfaces are fine, only complication is "null null () /" non xdrip follower watches are fine sent logs in too from my xdrip follower phone

[julien-binard]

Same issue here on pixel watch 2 / Wear OS 4 Add the issue on tic watch c2+ / Wear os 2

using beta version, oop2/libre2 sensor

any fix or way around? that would be nice to be abvle to use any watchface

[vin]

Can we please reopen this? #1846 specifically mentions fixing it for the Nightscout source. But we're still getting "null null" when using the xdrip sync follower source.

[Navid200]

@vin We have no active developers addressing WearOS. There is a lot of outdated WearOS related code in xDrip. WearOS was added to xDrip in a very inefficient way. And the result of it was that as soon as developers who did it left, the other developers have not been able to maintain it.

If we have developers who are working on issues, an open issue helps them keep in mind what else they need to fix. With respect to WearOS, we need new developers and we need a strategy to address WearOS better than it had been addressed originally in xDrip.

I can reopen this issue. It's not going to change any of the problems I pointed out above.

In my opinion, the whole WearOS implementation needs to move out of the xDrip code and into a companion (preferably open source) Android app. Then, all WearOS issues and features can be addressed by the developers of that companion app who should be the users of WearOS.

We currently as far as I know have no WearOS users in the xDrip developers.
They are more than welcome to join. But, if they don't there is nothing we can do about it.

[vin]

Thanks for the context. I asked to reopen it so it doesn't appear to users that the developers believe the issue to be fixed. Your comment here will serve that purpose just as well.

On the other hand, I do see a PR up thread; maybe it would get more attention if it closes an open issue?

[TsterT]

Seems this issue has popped up again at some point. This seems to be the main issue covering the bug. Here is an events log showing an issue on the April 19th update.

[Navid200]

@TsterT Can you test the following two consecutive Nightly releases and tell us which one has the problem?

https://github.com/NightscoutFoundation/xDrip/releases/tag/2024.01.02 https://github.com/NightscoutFoundation/xDrip/releases/tag/2024.01.05

[TsterT]

Thanks, @Navid200.

Jan 2nd release worked, Jan 5th release did not.

I will note after updating from Jan 2nd -> Jan 5th release, my previous glucose level stayed on the complication instead of reading "null" at the next reading. However, the error log shows the same as my screen shot above.

[Navid200]

@TsterT If I give you a test release, can you test? What I mean is do you have a spare phone to set up as a follower of your main phone xDrip and set up WearOS on it after installing the test release I give you? If anything goes wrong, nothing will be affected in your main xDrip.

[TsterT]

@Navid200 No, unfortunately I do not have a spare phone to test with,

[Navid200]

Please try the latest Nightly (https://github.com/NightscoutFoundation/xDrip/releases/tag/2024.06.28).

Do you still see this problem? If yes, please state what your hardware data source is.

[TsterT]

I no longer see the problem. Amazing. Thank you!