Need to connect to transmitter before we can start sensor #3078
-
|
After 20230328 a change was rolled out to make sure there was a valid timestamp for transmitter days resulting in "Need to connect to transmitter before we can start sensor". I believe this timestamp happens shortly after a TX is activated. And the rationale was to make sure a TX was ready to take a sensor start command (and importantly avoid potential "stuck" commands in the xDrip TX queue). While I never suffered from a stuck command in my life... I seem to reliably get blocked from starting a sensor by this countermeasure, permanently. I have to roll back to 20230328 every time I change my sensor as a workaround. I have an Anubis and I factory reset it after every use (have two Anubis and alternate to overlap, sleeping the outgoing TX to save battery). For whatever reason TX days stays at NaN (or "/6214") until after I start it, making this a race condition in my situation. I can't start because of the block, and I can't get unblocked because of the start limitation. I know my TX connects to my phone because it takes a battery reading and the "Last Connected" seconds rolls over. Yet because the timestamp doesn't update I'm check mated.
|
Beta Was this translation helpful? Give feedback.
Replies: 13 comments 29 replies
-
|
After you start by rolling back, how long does it take for transmitter days to show 0? Will it not do the same if you don't roll back? |
Beta Was this translation helpful? Give feedback.
-
|
I just recreated the problem by resetting the transmitter without removing the pairing from the phone. Let me run another test. |
Beta Was this translation helpful? Give feedback.
-
|
This time, I didn't use forget device. This time, I enabled |
Beta Was this translation helpful? Give feedback.
-
|
I'm running a third test. |
Beta Was this translation helpful? Give feedback.
-
|
This time, after resetting the transmitter, I forgot device in xDrip before activating the transmitter. |
Beta Was this translation helpful? Give feedback.
-
|
This is my understanding of what happens. Bluetooth pairing is a 2-way process. When there is a pairing established (pair request approved), xDrip stops looking for a transmitter to pair with. The allow OB1 unbonding, I believe, was put in place for exactly this situation. But, it caused more harm than help. So, we are telling everyone to disable it. The way I see it, you can enable allow OB1 unbonding if it does not cause frequent pair requests for you. I can see that others may get locked up the way you were using recommended settings. Please let me discuss this with others before we can see what we need to do next. |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for looking into this. I had tried various manual unbonding already. Before I reset at the end of a sensor (with the Anubis tool), I always forget device with xdrip (and disable collector). I will double check next time post Anubis tool (in android OS BT paired devices since Anubis tool has no such feature). What if we flip it on its head? Why not use a battery read as the gate for your readiness check? I'll test your other requests too. Other thing to note is I swear this only happens with one of my Anubis. Could be a coincidence but I'll keep an eye on it. |
Beta Was this translation helpful? Give feedback.
-
|
I don't think it is going to change anything if we switch to battery. |
Beta Was this translation helpful? Give feedback.
-
|
If that's not the case, meaning if xDrip can indeed read the battery voltages without a pairing in place, then voltages being present is not a valid representation that we have a link. |
Beta Was this translation helpful? Give feedback.
-
|
My screen shot has a battery reading but no transmitter days. My hunch is a
connection has occurred and it's G2G. Hence when I use an older version
without the check, I progress without issue.
I don't fully understand the other stuck command issue though. I'm guessing
I'm vulnerable to it somehow.
Maybe don't have a hard gate, but instead, auto clear any stuck commands
after a threshold and prompt user start has failed?
…On Tue, 12 Sept 2023, 8:52 am Navid, ***@***.***> wrote:
If that's not the case, meaning if xDrip can indeed read the battery
voltages without a pairing in place, then voltages being present is not a
valid representation that we have a link.
If we don't have a link, starting the sensor could cause a start command
getting stuck in the queue.
—
Reply to this email directly, view it on GitHub
<#3078 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AGERF22TUAKAKRIF5JJDGJDXZ52YTANCNFSM6AAAAAA4TCRTN4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***
com>
|
Beta Was this translation helpful? Give feedback.
-
|
Making people wait on every sensor change (while good intentions) is quite a large inconvenience e.g. night time replacements. I'd rather chance my luck with a stuck interaction and try again in the rare occurrence that it happens. |
Beta Was this translation helpful? Give feedback.
-
|
@Navid200 Going through a changeover now. Tried each of the below, waiting for 15-20 minutes between trying each.
As before I get a battery read so I'm convinced a connection happens. It just feels like a race condition with this Anubis. |
Beta Was this translation helpful? Give feedback.
-
|
Rolled back versions and it started instantly (without the gate obviously) but as soon as the start command was issued the TX timestamp populated in status with a 0 days. @Navid200 any chance you can bury a setting to disable the gate so I can be done with this? Been slogging away all year :) Changeovers are stressful enough. |
Beta Was this translation helpful? Give feedback.
-
|
When I recreated this problem, after I forgot device, I got a pair request on the next read cycle. After the pair request was approved, waiting for one more read cycle, I was able to start sensor even though transmitter days was still showing blank. The last change I made to this behavior was on June 24, 2023. #2757 But, the block on start when transmitter days is unknown was actually added on April 11, 2023. #2746 So, it became part of the stable release on May 3, 2023. If this was a problem with xDrip, causing people to get locked, we should have been getting reports from others by now. I am asking other developers to look at this (thanks for reporting) and advise what we should do. |
Beta Was this translation helpful? Give feedback.
-
|
I saw a similar situation on my Anubis when starting up after a factory deep-sleep. Like Navid, I regularly factory sleep my transmitter before starting it up again after some weeks. I think most users just stick with a single transmitter, replacing the battery as needed, but not using the factory sleep functionality. In my case, I installed the factory-slept transmitter, paired successfully, but then immediately lost pairing and data acquisition due to a battery level report of '0'. I didn't check the transmitter days, but I would expect it was blank like Navid. In my case, I was able to get started by completely removing and re-pairing the transmitter after waiting 30 minutes for the battery data to show up, but I expect there is some weirdness in how Anubis behaves regarding transmitter days and battery levels after factory sleep wakeup. |
Beta Was this translation helpful? Give feedback.
-
|
Discussion on the Anubis page and I have tagged the dev who chimed in https://www.facebook.com/groups/anubisg6/posts/843692667413110/ |
Beta Was this translation helpful? Give feedback.
-
|
@Navid200 would you please be able to source the Variant 1 20230328 apk for testing since it has aged off the repo? Come to think of it... Running main + variant may be a contributing factor so will keep an eye on that. I do housekeep properly though by forgetting devices and disabling collection at appropriate times. ie never have both apps competing for the same TX. |
Beta Was this translation helpful? Give feedback.
-
|
I don't have a backup for variants, sorry. |
Beta Was this translation helpful? Give feedback.
-
|
Would you happen to have an old phone in the house for a test? If it starts, you can then disable collection on the old phone and the regular phone should then be able to connect I hope. |
Beta Was this translation helpful? Give feedback.
-
|
@Navid200 yes I can try this next time with my old S8 |
Beta Was this translation helpful? Give feedback.
-
|
This is what I suggest assuming you overlap one day: Say you have TX1 on your main phone. Next day, the sensor on TX1 ends. Peel off TX1 and its sensor from the other arm. When you get to day 10 on TX2, repeat everything again replacing TX1 and TX2 in the instructions. |
Beta Was this translation helpful? Give feedback.
-
|
I have been able to recreate this problem. In the meantime, you can do what you did, temporarily install an older xDrip to start. |
Beta Was this translation helpful? Give feedback.
-
|
xDrip has a persistent storage that contains information about a transmitter. After a transmitter is hard reset, the timestamp of the transmitter goes back to 0. If you perform a hard reset using xDrip, the persistent store data is also flushed from the transmitter data. As a result, on the next contact, xDrip will ask for all the data from the transmitter and loads the persistent store with updated values. If you use a different app to hard reset a transmitter, the data in the xDrip persistent store (the timestamp) will be incorrect. If you always use xDrip to perform a hard reset, you will never experience the lock situation. |
Beta Was this translation helpful? Give feedback.
-
|
@Navid200 were you talking to me? I thought you implied I could try that to clear the persistent storage. |
Beta Was this translation helpful? Give feedback.
-
|
@old-square-eyes No, I was not talking to you. You can see I tagged someone else. |
Beta Was this translation helpful? Give feedback.
-
That makes sense. Is there any other way to clear the transmitter storage other than the hard reset function? |
Beta Was this translation helpful? Give feedback.
-
If you mean any other way to clear the xDrip persistent storage content related to the transmitter, I can think of the following, most of which are destructive! 1- If you clear the cache and storage content related to xDrip in your Android storage settings, that will do it. But, that will erase the database. So, that is a big no no. 2- If you uninstall xDrip and do a fresh install, that will do it. Again, that will erase the database. Again, a very bad idea. 3- You can use a temporary phone just for starting the sensor. After you start the sensor, you use your main phone to get readings and upload to Nightsocut etc. And you uninstall xDrip on the temp phone. None of those is a recommended practice. The easiest and simplest approach would be to use xDrip to perform the hard reset. |
Beta Was this translation helpful? Give feedback.
-
|
Okay, I'll take this to the developers of the other app that's doing the hard reset and see if they want to update their recommendations. Thanks! |
Beta Was this translation helpful? Give feedback.
-
|
I am doing a swapover now. Hard Reset Transmitter doesn't help to recover from the stuck state. It just says "Hard reset maybe failed". I have been in the stuck state for over an hour. Hard reset has been attempting for most of that time. |
Beta Was this translation helpful? Give feedback.
-
|
I know, I am sorry. |
Beta Was this translation helpful? Give feedback.
-
|
@Navid200 I was able to start the transmitter on my old phone, with a newer app version. So that (I guess) confirms it was something left over in local DB storage per your previous comments. |
Beta Was this translation helpful? Give feedback.
-
|
A new xDrip Nightly is supposed to address this: https://github.com/NightscoutFoundation/xDrip/releases/tag/2023.10.17 Please use it, or any after that, to address the problem. You still need to remove the transmitter from the list of previously paired devices on your phone. Otherwise, you will see deep sleeping error and experience malfunction. And you can hard reset using xDrip. But, you don't have to. This is addressed regardless of how you hard reset. |
Beta Was this translation helpful? Give feedback.
-
|
Awesome. Can't wait to try it. |
Beta Was this translation helpful? Give feedback.
-
|
Fist changeover went without a hitch. Thank you for seeing this through @Navid200 |
Beta Was this translation helpful? Give feedback.
-
|
You are more than welcome. |
Beta Was this translation helpful? Give feedback.
A new xDrip Nightly is supposed to address this: https://github.com/NightscoutFoundation/xDrip/releases/tag/2023.10.17
Please use it, or any after that, to address the problem.
You still need to remove the transmitter from the list of previously paired devices on your phone. Otherwise, you will see deep sleeping error and experience malfunction.
As long as you remove the hard reset transmitter from the list of previously paired devices, the behavior will be identical to that of a brand new standard transmitter.
So, you will need to approve a pair request. Then, you will need to wait for one or two consecutive read cycles after which, you will be able to start sensor.
And you can hard rese…