Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Final Release? #2

Closed
dhermanns opened this issue Apr 6, 2019 · 40 comments
Closed

Final Release? #2

dhermanns opened this issue Apr 6, 2019 · 40 comments

Comments

@dhermanns
Copy link

Hi!

Is there a final release already?
@nightscout-dl
Copy link
Owner

Hi @dhermanns

v2.1-alpha.3 is the last I have done - 9 months ago. My T1D had been using releases on the project releases page. Most people are on the 1.0 download, but the newer ones should improve stability/sanity.

I would love people to try it - I'm very, very, happy to and will fix the software where bugs are found.

My T1D was moved to a newer Medtronic device - one of the more crypto-d-to-the-hilt ones - so we're on the mainstream Nightscout project now (which is a huge upgrade in terms of software quality) using Medtronic's own USB carelink reader - but which doesn't have the 10M+ range of our old home-brew devices.. (sigh).

Hence I can no longer test my work on my own user - so it's not had the degree of testing I need to call it a final release.

But.. I do have a few archives of message data, and a USB-USB null modem to generate fake messages or replay old ones :-) so I can do a reasonable amount of testing, and with consent I can turn on remote logging to test too for any user that is willing to work with me on any issues.

Let me know if you need anything.

Best wishes
David

@dhermanns
Copy link
Author

dhermanns commented Apr 7, 2019 •
edited
Loading

Hi David,

thx for the fast reply. I tried to use this release:
https://github.com/nightscout-dl/MedtronicUploader/releases/tag/v2.0-alpha.3

But it seem to stop uploading after a few hours. The latest version isn't installable on my Nexus 5 with Android 6.0.1 Device:
https://github.com/nightscout-dl/MedtronicUploader/releases/tag/v2.1-alpha.3

It simply stops installation of the apk. Any ideas?

@nightscout-dl
Copy link
Owner

Hi -

I saw intermittent stopping of uploading in the past, which was one reason I booted out the unsupported and old USB library and used a new more debuggable one in the latest version.

I've rebuilt with a fresher JDK and Android Studio today, in the hope that this supports the Nexus 6 better.. it's on the github releases page.

Can you give that a try?

@dhermanns
Copy link
Author

Thanks a lot. I have a Nexus 5. But I got the same effect: After installing the Alpha5, it immediately says "not installed" and that's it.

Mabye due to the old Android 6.0.1?

@dhermanns
Copy link
Author

I rebuild the APK for Android 6.0. Installed fine now. It shows a received blood glucose of 0 right now. I calibrated and it says I should wait 15-20 minutes now. Is this behavior intended?

@nightscout-dl
Copy link
Owner

nightscout-dl commented Apr 7, 2019 via email

@dhermanns
Copy link
Author

Yes - works fine now :-). Great work. Your Repo should be the one that is referenced in the nightscout doku. Arbox0 seems to be abandoned.

I will see next night how stable the uploader is now ;-).

Why did you introduce the calibration time period?

@nightscout-dl
Copy link
Owner

@dhermanns - When you rebuilt the APK - presumably a change to min/max/target sdk version - which one made the difference (all of?). I will commit the change to make this go back to an earlier one (perhap 4.4, which still has > 5% usage - some people will want to use an old phone for their nightscout).

I introduced the calibration period for a couple of reasons.. I should've I'd wrote down why I chose what I did as I don't recall exactly now.

  1. I could not understand what the previous code was doing or what it was intended to do (see
    commit ) - and figured cleaner code that did one thing and was clear was a better path.

  2. I read that the glucometer is usually about 15 minutes ahead of the abdomen-mounted CGM in terms of glucose level - so what you read now on the clicker at the finger is equivalent to that in the CGM 15 mins later. On reading the original code, it might've been trying to do that anyway but I couldn't tell. I figured the initial values you see from the CGM are not calibrated accurately so better not show at all.

However, it probably doesn't do any harm to consider the readings in 0-15 mins as "good enough" with the actual glucometer at that 0 mins point, so I think it's safe to remove this delay in posting the data.. however the calibration value should still be set at 15 mins point with the CGM reading gathered around 15 mins in..

Thoughts?

@dhermanns
Copy link
Author

The master has the same problem for me: it stops uploading after at most 2 hours. If I open up the App again, it shows the latest readings just fine. But looks like the App just can‘t upload anymore. But I have to press Stop/Start Button to make it upload again.

No errors in the console...

@dhermanns
Copy link
Author

And yes - I changed the target SDK to 23.0 if I remember correctly.

Repository owner deleted a comment from dslarm Apr 8, 2019
@nightscout-dl
Copy link
Owner

Great.

Do you mind if I turn on logging - you won't notice it, and don't need to do anything, but I can then collect the logs from the app (on bugfender.com which has been really really helpful, even my relative with T1D was a flight away from me so logging has been critical). I ask because it means the logs will contain your device IDs (which are hardly secret on that version of medtronic transmitter) and URL - these will be in my private bugfender account for a week.

@dhermanns
Copy link
Author

No problem- let’s give it a try!

@nightscout-dl
Copy link
Owner

Great, it's on, so just try to use as normal and please comment in this ticket as soon as it stops logging.

@dhermanns
Copy link
Author

So you have the remote debugging activated on your branch version? So my self compiled version contains it, right?

@nightscout-dl
Copy link
Owner

Yes, the debugging is activated, I'm seeing logs, so just let me know when it stops working.

@dhermanns
Copy link
Author

I did an auto restart every hour. So it works rock stable now ;-). I will disable it during the day and let you know when it hangs again.

Thanks for your help so far! 🙏

@dhermanns
Copy link
Author

I disabled the restart today. It seems to hang now. The last value I got was from about 7:40am.
I think the problem occurred between 8am-9am. But can't say that exactly, since my child was at school at that time ;-). When he returned at 1pm, the uploader wasn't working anymore.

@nightscout-dl
Copy link
Owner

HI -

Ok - what I see is connection time-out at 07:38 central Europe time.
After that, no radio transmission is received until 12:57 - was your son and the android device separated at school? -

After 12:57, it tries to connect and gets connection time out again, and again, almost all afternoon. It first succeeds again at 19:41.

So, is there a phone connectivity issue? Or the website hanging? Or maybe we have some other issue like too many open connections (if it's not properly disconnecting after sending data, say, I don't know how possible that is.. will do some investigating).

2019-04-11 11:58:02.012 +0100 BST W UploadHelper  :-1 a   Unable to post data
2019-04-11 11:58:02.015 +0100 BST W UploadHelper  :-1 a   org.apache.http.conn.ConnectTimeoutException: Connect to /*.*.*.*:1337 timed out
2019-04-11 11:58:02.016 +0100 BST W UploadHelper  :-1 a   	at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:126)
2019-04-11 11:58:02.017 +0100 BST W UploadHelper  :-1 a   	at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:149)
2019-04-11 11:58:02.018 +0100 BST W UploadHelper  :-1 a   	at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:169)
2019-04-11 11:58:02.018 +0100 BST W UploadHelper  :-1 a   	at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:124)
2019-04-11 11:58:02.019 +0100 BST W UploadHelper  :-1 a   	at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:366)
2019-04-11 11:58:02.02 +0100 BST W UploadHelper  :-1 a   	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:560)
2019-04-11 11:58:02.021 +0100 BST W UploadHelper  :-1 a   	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:632)
2019-04-11 11:58:02.021 +0100 BST W UploadHelper  :-1 a   	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:658)
2019-04-11 11:58:02.022 +0100 BST W UploadHelper  :-1 a   	at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:621)
2019-04-11 11:58:02.044 +0100 BST W UploadHelper  :-1 a   	at com.nightscout.android.upload.UploadHelper.postDeviceStatus(UploadHelper.java:239)
2019-04-11 11:58:02.045 +0100 BST W UploadHelper  :-1 a   	at com.nightscout.android.upload.UploadHelper.doRESTUploadTo(UploadHelper.java:159)
2019-04-11 11:58:02.046 +0100 BST W UploadHelper  :-1 a   	at com.nightscout.android.upload.UploadHelper.doRESTUpload(UploadHelper.java:106)
2019-04-11 11:58:02.047 +0100 BST W UploadHelper  :-1 a   	at com.nightscout.android.upload.UploadHelper.doInBackground(UploadHelper.java:34)
2019-04-11 11:58:02.047 +0100 BST W UploadHelper  :-1 a   	at com.nightscout.android.upload.UploadHelper.doInBackground(UploadHelper.java:72)
2019-04-11 11:58:02.048 +0100 BST W UploadHelper  :-1 a   	at android.os.AsyncTask$2.call(AsyncTask.java:295)
2019-04-11 11:58:02.049 +0100 BST W UploadHelper  :-1 a   	at java.util.concurrent.FutureTask.run(FutureTask.java:237)
2019-04-11 11:58:02.049 +0100 BST W UploadHelper  :-1 a   	at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:234)
2019-04-11 11:58:02.05 +0100 BST W UploadHelper  :-1 a   	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1113)
2019-04-11 11:58:02.051 +0100 BST W UploadHelper  :-1 a   	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:588)
2019-04-11 11:58:02.052 +0100 BST W UploadHelper  :-1 a   	at java.lang.Thread.run(Thread.java:818)
2019-04-11 11:58:02.053 +0100 BST I UploadHelper  :-1 a   Finished upload of 9 record using a REST API in 30204 ms

@nightscout-dl
Copy link
Owner

nightscout-dl commented Apr 11, 2019 •
edited
Loading

I've just made another couple of commits - better exception handling for those timeouts (and removed some overly verbose logging), but I don't see it likely to fix the problem.

Looking at the log I saw earlier - it really does look like a persistent web timeout - it's giving it a full 30 seconds before erroring each time.

I'm wondering if you're using Wifi or mobile. There's an option of "wifi-hack" in the settings - it seems to turn wifi on and off every now and again - but I have no idea why this hack was put in, or when, and everyone seems to say it's not needed. I didn't have much luck with Google.

@dhermanns
Copy link
Author

dhermanns commented Apr 12, 2019 via email

@dhermanns
Copy link
Author

dhermanns commented Apr 12, 2019 via email

@nightscout-dl
Copy link
Owner

nightscout-dl commented Apr 12, 2019 via email

@dhermanns
Copy link
Author

I saw that the used Apache Httpclient is deprecated and updated the uploader to the new HttpURLConnection logic.

Hopefully this brings more stability to the upload.

@nightscout-dl
Copy link
Owner

nightscout-dl commented Apr 13, 2019 via email

@dhermanns
Copy link
Author

No - same problems. The app runs fine for 60-120 minutes. At some point, we get SocketTimeoutExceptions every time the app tries to send to the nightscout backend :-/ .

@nightscout-dl
Copy link
Owner

Thanks. OK - I will not be able to work on this for a few days, but my theories are (a) configuration - some Android thing that needs to be set to retain Wifi/network access; (b) resource exhaustion ; (c) and a long-shot.. the Nightscout website actually not accepting connections.

If you have a moment - can you do something simple like add a HTTP request to GET a known reliable webpage like www.google.com - immediately before the POST to the Nightscout site. If that get fails/time outs after two hours, the problem is certainly (a) or (b).

@dhermanns
Copy link
Author

Good idea - I will see how I can drilldown the problem a bit...

@nightscout-dl
Copy link
Owner

Hi - have you managed to triage the connection problem yet? I'm thinking we could have some doze mode issue https://developer.android.com/guide/background - as you mentioned your device is Android 6.0, or just some other sleeping/network issue; there's nothing in the logs that provide any evidence for this though - but if we add a few network/device status calls/listeners we might be able to rule it out/in..

@dhermanns
Copy link
Author

No - not yet :-/. I did some more experiments. It‘s not just an Android 6 issue. It happens on another Android 8.1 phone exactly with the same SocketTimeoutExceptions.

I changed a few more things like using ip addresses, http instead of https. Deactivated ipv6 in my router. But still the same.

@nightscout-dl
Copy link
Owner

nightscout-dl commented Apr 27, 2019 via email

@dhermanns
Copy link
Author

Ah ok. It definitely varies. Sometimes event after 15-30 minutes. But the display is always off.
So it could be dozing. I disabled battery saving. But I will try to configure to keep the screen all on and see if that helps.

@dhermanns
Copy link
Author

I managed to keep it up for 24h without a restart now. I think the point was activating the „Wifi Hack“ Switch in the uploader.

But I changed a couple of other parameters. I will reset them and see if it’s still stable.

@nightscout-dl
Copy link
Owner

Hi
I've just committed the recommended steps to whitelist the app against battery optimizations - https://developer.android.com/training/monitoring-device-state/doze-standby.html#whitelisting-cases

Can you build that - see if it helps, see if we can remove the wifi-hack!

@dhermanns
Copy link
Author

Interesting - I will try that. Thanks for your help!

@dhermanns
Copy link
Author

Amazing - it seems to be that this was really the root cause: The battery saving of android. I turned of the wifi hack and my new build is running stable for 2 days now:

I created a pull request with my changes:
#3

I think this could be pretty useful for others who are on the old medtronic paradigm veo pump 5xx.
Nightscout should change the arbox0 link to your GitHub repo. I will let them know to change it...

@nightscout-dl
Copy link
Owner

Thanks for the pull request - this is merged and we have a new release!
Can you check it over - including your earlier installation issue on the Nexus 5.

@dhermanns
Copy link
Author

Your latest apk can't be installed on android 6. Did you loose my changed build target from my PR during merge?

@dhermanns
Copy link
Author

Hm - your app/build.gradle sdk version looks fine. I will try later on android 8...

@dhermanns
Copy link
Author

It has to be something else. I can't install your new apk on Android 8 either.

@nightscout-dl
Copy link
Owner

I have rebuilt and re-issued the release. The problems were two-fold:

  1. Only signing the bundle not the jar and bundle (required but only one of the ticks was default filled in in studio).
  2. The "instant run" 'feature' which meant I couldn't install/re-install and all I saw was "not installed" errors. (https://stackoverflow.com/questions/51859959/apk-fails-to-install-the-second-time )

I think we're working now!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@dhermanns @nightscout-dl