connection loss (no automatic reconnection)

[atomphil]

Description of the issue:

Watchdrip enters the status "Authorization failed, sleep" and automatically stops connecting to the watch. If you manually stop the service in Watchdrip and start it again, the data is sent to the watch again without any problems. These very annoying interruptions happen several times a day, often when I was in another room of the flat for a short time, but sometimes also just like that when the watch and smartphone are actually close to each other. It also often happens that the connection breaks in the evening or at night and I only notice it the next morning.

Version 0.1.3:

before and after restarting the service:

Version 2.0.3:

behaves the same way, but shows the value and the time of the last sync with xDrip.

at the watchface:

• highlighted with red are the data from Watchdrip
• highlighted with blue are the data from Libre 3 App using Free Three and Gadgetbridge (live data, every minute)
• Bottom left corner is the battery level of the smartphone via both FT and WD as an activity indicator.

four hours later:

What could be better:

It would be good if Watchdrip continues to try the connect every 5 minutes for a certain period of time. After that, the interval of connection attempts should be increased to save power.

Suggestion for a retry interval:

• first hour every 5 min
• 2-3 h every 10 min
• more than 3h every 30 min
• more than 24h -> stop trying -> sleep

This improvement would handle short stays out of radio range or one-time failed connections without manual intervention, and would also take into account a forgotten watch at home without putting too much strain on the mobile phone battery. This would make the data on the clock much more reliable (I often notice the connection failure late) and eliminate the annoying manual restart of the service.

---

My wearable devices are:

Amazfit Bip S and Bip S lite

My Android version:

LineageOS for microG 18.1 (Android 11)

affected WatchDrip versions:

0.1.3, 0.2.0.x

[atomphil]

The commit of May 5, 2023 seems to have fixed the problem. The connection to the clock runs much more reliably since then, even if you were out of range for a short time. 👍