Supporting WearOS users who use xDrip

[Navid200]

I am not the lead developer of xDrip.
I use xDrip as a diabetic and I have made contributions to the xDrip code.
I am posting here on my behalf only representing myself.

What capabilities will a WearOS watch user miss if they use xDrip and GlucoDataHandler instead of using xDrip's native WearOS support?

How practical would it be for you to add such capabilities so that such a user will get similar capabilities?

[pachi81]

Hi Navid,

I used xDrip+ a couple of years and it is such a great software! Thank you for all you have done being part of this diabetic management tool.
After I had to use Libre 3 and liked the one minute interval (I would not have expected before, but at least in the very low section, it is just great not waiting 5 minutes for the next value), I could not use xDrip+ anymore and Juggluco also had problems. This was the reason creating GDH.

Related to your question. It is hard to say, as I have not used the xDrip+ Wear OS integration the last years, but as xDrip+ for example provide such a great alarm manager and the possibility to input data in the watch, it is hard to add such features to GDH without also supporting all these features.
For me personal GDH can be used for showing data on watch. If users need to interact more with the system, they have to use xDrip+ on watch.

But at least for showing values on watch, there could be some improvement in the data communication between xDrip+ and GDH.
It would be great if we can improve this. At the moment GDH supports the xDrip internal broadcast, the Broadcast Service API and the pebble-webservice endpoint (for IOB data).
The biggest problem I have, none of these interfaces provides COB* or Basal** values. If users want to show COB in GDH, they have to use Nightscout.

What do you think, what functions users will need for xDrip+ in the Wear OS version, which may be compatible with GDH?

Best regards, Michael

* the Broadcast Service API sometimes provides a statusline (from AAPS?) including the COB
** showing Basal will be added in one of the next GDH versions

[trizt]

One of the issues that happen to me with the xDrip wear was that when I installed it on my watch, the watch had an older version of wearos and everything worked fine. In the end of last year there was an update that pushed out the new OneUI8, things keept on working until xDrip managed to get the upgrade of the wear app and ended in an retry install loop as the Android API level requirements changed and I had to uninstall it and now I can't install the wear app and according to Navid there is no one working on the wear app.

I tried to use the juggluco wear app, but for some reason it disables the phones connection to the sensor and do not fetch any data itself, so suddenly I can be without current values.

I had a short run with the wear widget, it works but require a bit more actions to see the data.

I have now the GlucoDataHandler installed, with the DMM Watch face.

For me the feature I miss dearly is the ability to input carbs from my watch.
I would have loved if there had been an option to read the pen with the watch and send the insulin doz to xDrip... (don't worry, I'll wake up from my dream in a short moment)

[pachi81]

Thank you for the information. That is exact the problem, I can not handle (at the moment).
If I will provide an input of carbs and insulin data, the user will expect, that I show the data in graph, upload to Nightscout and forward to xDrip. And maybe they will also expect to calculate IOB and COB...
That is such a big feature, I think it will take several months to implement, as I only have a short time for developing...
And I still have a very long todo list.
So it may be implemented in the future, but I doubt, that it will be this year.

[Navid200]

There sometimes are alternative approaches that can resolve problems.
Just as an example, could there be a different existing channel you can use to communicate with xDrip for example the same way Nightscout does?

If needed, we may even be able to create a new com channel for this purpose or enhance an existing one.

There is a channel for MiBand for example.

I mean instead of spending time to create something, you may just need to use an existing mechanism by using an alternative path.

[pachi81]

No I do not want to create something new. I also prefer using an existing one. That is the reason GDH already supports internal broadcast, Broadcast Service API and pebble interface.
For example, the pebble interface of Nightscout provides COB, xDrip does not. Is there a reason for?
I think the Broadcast Service API can also provide COB, as it already provides IOB, statusline and other information.

[Navid200]

I can make changes to xDrip if I know what's missing.
I will look into adding CoB to broadcast.

[pachi81]

I think you need to change the Broadcast Service API as the normal broadcast also not provides IOB.
That is the reason, I implemented the Broadcast Service API.
I really prefer the Broadcast Service API as it also provides graph data, so I think this should be the solution for communication.
Or is there any other channel, which provides such information? Graph-values, IOB, COB, slope, ...?

At the moment, I ask myself, why I never request such a change in xDrip+
Maybe I thought that this is just a fix format, that so many apps are using, that any change is impossible.

[pachi81]

@trizt and @Navid200 I have a question:
How is the input of carbs and insulin implemented in xDrip+ Wear OS app? Using watch tiles?

Just a thinking: I use the watch tiles for input in GDH (just copy from xDrip) and try to only provide them, if xDrip+ Broadcast Service API is enabled. We use the Broadcast Service API to send the input from GDH to xDrip+ for calculation and xDrip+ sends COB and IOB to GDH for showing on watch. Not sure, if it is possible (especially to provide a tiles only, if a special setting is set).

Just a thinking... What do you think about?

[trizt]

I'm just an end user at the moment and far from a java coder, so haven't really looked at the source code, then Navid has more insight there.

I think the xDrip wear app was made a long time ago, before tiles, when installing it on the smart watch you got 4 application icons (was a bit confusing as they all had the same icon), think it was still one app, but provided different parts of it (kind of like how things work in busybox and symlinks in Linux), the watch face I think just called on the application indicating that you wanted to do treatment input.

[pachi81]

Thank you! I asked you as user, as I'm not sure, how it looks like.
Is there any screenshot.
I also have used it a couple of years ago, but still not sure about.
I think AAPS provides also some input possibilities.

[trizt]

reading the documentation there seems to been one tile, just I never seen it when testing watch faces. The screenshots I'm not so sure about are fully correct as it's not always how it looked like on my Samsung Watch 5.

For example when confirming the treatment, the documentation shows

while it looked more like this for me

As I can't reinstall the wear app, I can't take screenshots or check features, so we hope the docs are up to date.