Marker and scaling issues with mmol/L on watch

[steffen64g]

This is happening with, but not limited to, versions e68816a-2025.02.18 and 35ec74c-2025.07.04 (smartphones: Samsung S4mini, Sony Z3compact; watches: Sony SWR50).

When switching from mg/dL display to mmol/L in the phone xDrip settings, the markers for carbs, insulin and blood glucose move in a strange way (from somewhere [1/3 height?] in the normal range , the lower range end, and the true value - to lower end, lower end, and zero) only on the watch while the phone display is OK in both representations.

As a side-effect, the shown range also changes (includes zero level on the watch when in mmol/L to show the BG measurement).

I had to switch from mg/dL to mmol/L recently, and the new view doesn't let me distinguish between injections and meals, I would have to through the three-dot menu to see what was what.

If this is a bug (for me, it is), it must have been there for quite a while. Also, mmol/L users seem to be hugely outnumbered by mg/dL ones so this might have gone unnoticed for long.

I took screenshots of the same watch before and after switching - this behavior doesn't go away by multiple switches back and forth - and hope this can be reproduced by someone else, and tracked down to some place in the code.

same phone, same watch, same settings - just the glucose unit changed

[NB: I noticed that the first green marker is missing in one of them - sometimes the watch "forgets" markers, but this is an unrelated thing and has been fixed by re-uploading to watch.]

[Navid200]

This all sounds like Wear OS issues.
I don't know if any developer is supporting Wear OS any longer. I myself don't use a watch.

When I look at the code, I see an entire redundant set of files that are there just for Wear OS. In my opinion, someone has to create a companion app for Wear OS and take care of everything related to Wear OS in that companion app.
Then, only those who need Wear OS, would install that companion app on their phone.
Everything related to Wear OS can then be addressed by adjusting that companion app. This will offload the Wear OS support to that companion app that can be addressed by an interested party.

That's just my personal opinion. I have no idea what to suggest for a Wear OS user who is not a developer.
But, for a developer, this is an opportunity to serve the community and take ownership of a critical component.

There is nothing I personally can do to address this because I don't own a Wear OS device and on top of that, I don't believe Wear OS is currently supported properly in the code with all the existing redundancy in the code.

[steffen64g]

Wear OS 1.5 in many respects is different from 2.0 and later, I agree, but this kind of devices is still well-supported and sustainable (it's even possible to change the battery themselves) so I'd much dislike xDrip no longer talking to it. OTOH with your veto this wouldn't make it into the list of Issues, right?

[Navid200]

This may be a misunderstanding. I'm not suggesting that xDrip would not support Wear OS. I would like xDrip to continue to support Wear OS but in a sustainable manner.

If a developer who is interested in Wear OS, opens a submission to add a communications channel to xDrip for Wear OS, and they create a companion app for it, xDrip will be able to broadcast the raw data to the companion app. Then, the companion app with address everything needed to use the raw data it receives and control the watch to show everything it needs to show.

This will give full control to this developer to make any necessary changes when new Wear OS devices come to the market with no need to get approval from the xDrip team. This is effectively like xDrip outsourcing the support of Wear OS. This means you will still be using xDrip. But, you will also need to install a small companion app on the phone.

This approach will serve everyone:
1- xDrip code and developers: There will be no issues related to Wear OS any longer in the xDrip repository because all of those will go to the companion app repository.
2- Companion app developer: He/She will be able to advance the app without being held back by xDrip submission reviews, which are slow because there are so many of them.
3- Wear OS users: They will have a developer or a team who are focused on Wear OS only and can address their needs much faster than the xDrip team can.

---

All that said, if someone opens a submission today to address Wear OS needs and issues, I will have no objection.
I am just aware that it has been years since a change has been made to address Wear OS issues. What happens in this repository happens because some developer is interested in working on it. I don't know why the support for Wear OS has stopped. I have nothing to do with that. I welcome it.
All I am saying is that considering how much there is inside xDrip, it has become very slow in development. Offloading some of the work to a team with focus on the specific project seems to me to be the best solution.

I am not stopping Wear OS development.
When I see something that needs to be done, I do it if I can. I cannot do anything about Wear OS because I have no experience with it. Not because I have anything against it.

[Steffen-Gr]

While the scaling issue may take a bit longer to resolve, what about using different colors for markers? During the past days, I repeatedly ran into situations where a quick glance at the watch didn't provide information about insulin age, and with the current palette it's too easy to take an insulin shot marker for a carbs one. Luckily I didn't run into a serious low while hanging the laundry (such chores tend to multiply insulin action by a factor of at least 3 for me :/ )
What I don't understand: How would such a bug have passed the years without being noticed? (I'd expect the BlueJay also to be affected - or is there nobody who runs on millimols?)

[Navid200]

BlueJay is not WearOS. It is a full Android watch.