Feature Request: Automated Bluetooth Reset for External Broadcast Data Source Connectivity Issues

[Electrik-rich546456]

Hello xDrip+ Developers and Community,

First, I want to express my deep appreciation for the incredible work you do. xDrip+ is a vital tool for many, and I understand and respect the project's commitment to open-source principles and maintaining independence from proprietary sensor technologies, particularly concerning direct sensor communication and decryption. This approach is crucial for the project's integrity and legal standing.

I'd like to propose a feature that I believe aligns with xDrip+'s goal of improving data reliability, without infringing on the principles you uphold.

The Problem:
Users who rely on external applications (such as Juggluco, or other third-party bridges) that send glucose data to xDrip+ via Android broadcasts (e.g.,640G / EverSense, glucodata.Minute) sometimes experience data loss. This often occurs due to underlying Bluetooth connectivity issues on the sensors, which can cause the external app to stop sending its broadcast. When this happens, a manual toggle of the phone's Bluetooth (off and then on) frequently resolves the problem and re-establishes the data stream from the external app. However, this manual intervention can be disruptive, especially during the night if hypo unaware and living on own.

Proposed Feature: Automated Bluetooth Reset for External Broadcast Data Sources
I propose adding an optional feature to xDrip+ that would:

Monitor for the absence of incoming data from a configured external broadcast data source (e.g., if the glucodata.Minute broadcast is not received by the 640G / EverSense data source).

If no data is received for a user-configurable duration (e.g., 3-5 minutes), trigger a system-level Bluetooth off/wait 5/on cycle.

Why this aligns with xDrip+ principles (and avoids legal concerns):

No Proprietary Code Integration: This feature would not involve xDrip+ directly interacting with or integrating any proprietary sensor protocols or decryption algorithms. It would simply react to the absence of a publicly broadcast Intent that xDrip+ is already configured to receive.

Standard Android API: Toggling Bluetooth is a standard Android system function, available via public APIs. This is a generic system action, not specific to any sensor or proprietary communication.

Connectivity Improvement: The goal is to improve the reliability of data reception from an already configured and accepted external source by addressing common Android Bluetooth stack issues that can affect any app relying on Bluetooth.

User Control: It would be an opt-in feature with a configurable timeout, allowing users to decide if and how it impacts their device and battery.

Benefits:

Significantly improves data reliability and consistency for users of external broadcast data sources.

Reduces manual intervention and improves user experience, particularly during sleep.

Enhances xDrip+'s robustness as a central data hub, even for externally sourced data.

I believe this feature would be a valuable addition that helps users maintain consistent data flow without requiring xDrip+ to delve into the complexities or legal sensitivities of direct proprietary sensor communication.

Thank you for considering this proposal. I look forward to your thoughts and any feedback.

[Navid200]

xDrip already has a Bluetooth watchdog.
Are you sure it does not work for Eversense?

[Electrik-rich546456]

OK,

The other app fails. Instead of asking the other app to restart Bluetooth, you are asking xDrip to do it.

I am trying to address the xDrip issues and requests that I can. I have to prioritize because we are not many and we are all busy. Helping another app is really not something I can categorize as high priority.

Yes as i said xdrip manages its collector oop2 if no data comes in so why cant it do the same if a diffrent collector is used? ?

[Navid200]

There are not many Libre developers who support xDrip. If one is willing to open a submission, it will be considered like any other submission.

I cannot open a submission if I cannot test it myself. Unfortunately, I cannot work on Libre-related matters because I have no access to any Libre sensors. Even if I get a Libre sensor, it is not going to be practical considering I use Dexcom.

[Electrik-rich546456]

There are not many Libre developers who support xDrip. If one is willing to open a submission, it will be considered like any other submission.

I cannot open a submission if I cannot test it myself. Unfortunately, I cannot work on Libre-related matters because I have no access to any Libre sensors. Even if I get a Libre sensor, it is not going to be practical considering I use Dexcom.

I can happily test the code i dont think im good enough of a coder to create this function myself so please open a submission

[PhilTU]

Yes as i said xdrip manages its collector oop2 if no data comes in so why cant it do the same if a diffrent collector is used? ?

As far as I know OOP2 is not a collector, it is a co-processor for decoding the Libre data, applying a form of algorithm and returning glucose and raw values to xDrip+. You see the sensor MAC and the "Connecting" etc messages in xDrip itself, and GATT settings and the like https://xdrip.readthedocs.io/en/latest/use/bluetooth/ all live in xDrip+

I don't believe (from using it and testing new versions) that OOP2 is restarted by xDrip+ when there are issues with connectivity. This doesn't mean your idea is without merit but I think it's not a valid comparison.

There are parallel scenarios where xDrip uses "companion app" and other data sources to receive values from other apps that are managing sensors on the same phone, if the data flow into xDrip+ stops should the Bluetooth also be toggled in those situations ?

[PhilTU]

@PhilTU I'm sorry to say that due to your limited experience please believe me when i say that juggluco does not handle it very well at all. For example today the sensor has disconnected 3 times. Every time i have to manually turn off bluetooth for at the least 5 mins and at the most 30 mins to regain the connection to the sensor.

different phones and OS react differently, I haven't used juggluco for a couple of months but previously (android 9) I found it handled disconnections adequately. Disconnections are common with Libre but I hadn't noticed a crowd of people complaining about reconnection at https://github.com/j-kaltes/Juggluco/discussions

[Electrik-rich546456]

Are there any developers that are using fsl2+ ?

@Navid200 said > I cannot test it myself. Unfortunately, I cannot work on Libre-related matters because I have no access to any Libre sensors.

So if any one can take a look at this problem that would be greatly appreciated ?

[Navid200]

I have to add to that statement that I don't believe a Bluetooth watchdog is the best approach and should be avoided if possible.
I used to have a phone that was not great. While driving and using my phone as a GPS, it would stop all of a sudden because Android Auto shuts down without Bluetooth and will not automatically recover upon the resume of Bluetooth.

That's just an example. Shutting down Bluetooth should be a last resort.

As I stated already, if an app needs this last resort, it should be that particular app to do the shut down and restore. In this scenario, xDrip does not even use Bluetooth. So, clearly it is the other app used as the collector that is failing.

So, let's say you take all of that into account and say that you still want xDrip to do that and let's say you are a developer and decide to make the change. You will be adding a setting to xDrip that could mess up proper operation if enabled when not needed. So, you say that's the point of the setting. I understand. The problem is this xDrip is meant to be used by the masses. We always have to worry about how a new setting could possibly confuse an inexperienced user.

I give you an example. As an xDrip user, I want this PR to be approved:
#441
But, as a developer who supports users and is aware of how many times people mess things up by using incorrect settings, I cannot approve that PR.
Similarly, it will be a mess adding the ability to xDrip to shut down Bluetooth needing to identify exactly why there are missed readings considering xDrip is not the collector.

[Electrik-rich546456]

I understand your example however it is still not possible for you to make the changes and put it in a fork or branch that would allow further development or help discover more info on this issue?

maybe some extra logging version of xdrip to see what happens when "restart collector" is pressed.
I mean maybe just adding this new function to that button as you say only as a last resort.