nightscout / android-uploader Goto Github PK

http://developer.android.com/training/sync-adapters/index.html

Using a sync adapter to buffer data upload should allow for uploading all data even with spotty coverage/connectivity

"I/Choreographer( 3745): Skipped 336 frames! The application may be doing too much work on its main thread."

Handlers are created on the Main/UI thread causing the application to become unresponsive during USB communication

A malformed REST uri that throws an exception like:
E/Uploader(32632): java.lang.Exception: Unexpected baseURI: yourpassphrase@https://blah/dexapi/, uriParts.length: 2, apiVersion: 0
E/Uploader(32632): at com.nightscout.android.upload.Uploader.doRESTUploadTo(Uploader.java:127)
E/Uploader(32632): at com.nightscout.android.upload.Uploader.doRESTUpload(Uploader.java:101)
E/Uploader(32632): at com.nightscout.android.upload.Uploader.upload(Uploader.java:70)
E/Uploader(32632): at com.nightscout.android.upload.Uploader.upload(Uploader.java:59)
E/Uploader(32632): at com.nightscout.android.dexcom.SyncingService.handleActionSync(SyncingService.java:161)
E/Uploader(32632): at com.nightscout.android.dexcom.SyncingService.onHandleIntent(SyncingService.java:103)
E/Uploader(32632): at android.app.IntentService$ServiceHandler.handleMessage(IntentService.java:65)
E/Uploader(32632): at android.os.Handler.dispatchMessage(Handler.java:102)
E/Uploader(32632): at android.os.Looper.loop(Looper.java:136)
E/Uploader(32632): at android.os.HandlerThread.run(HandlerThread.java:61)

Should prevent the upload status indicator from being green

App starts with Y-axis in mg/dL even when set to mmol/L. Current value correctly displayed in mmol/L. Opening Preferences menu seems to set correct Y-axis scale.

Should be database record type 7 from the dexcom

Noticed with the latest apk the "Uploaderbattery" field in mongolab (devicestatus collection) is sometimes reporting 0 see below:
{
"uploaderBattery": 0,
"created_at": "2014-09-13T19:43:12.887Z",
"_id": {
"$oid": "
}
}
Other times it reports the correct value ( 5 mins later)
{
"uploaderBattery": 30,
"created_at": "2014-09-13T19:48:11.878Z",
"_id": {
"$oid": "
}
}
I disconnected/ wiggled the otg cable, the battery started reporting non zero values again, could just be a coincidence but thought I would mention it. Grant

Hi,
When the Android application installs it should prompt the user to accept terms and conditions that
release us from liability. In that dialog it should contain a use at your own risk statement. My two cents.

I have used 5", 7", and 10" inch tablts and the font sizes were the same on all of them.

I think we should use bigger screens for bigger phonts, espiecely when it comes to lines like "updated x minutes ago". This one remains too small.

My main motivation is this: I would like to put a tablet on the living room to always see the values and so this value stays too small.

Reading through docs it seems that google is pointing towords creating multiple xml files:

res/layout/main_activity.xml # For handsets (smaller than 600dp available width)
res/layout-sw600dp/main_activity.xml # For 7” tablets (600dp wide and bigger)
res/layout-sw720dp/main_activity.xml # For 10” tablets (720dp wide and bigger)

see http://developer.android.com/guide/practices/screens_support.html

I guess that this works and is simple, but will require more work when updating the different activities.

Should I prepare a fix?

Red-Green is a VERY common color blind problem, and we need a better indicator of status than just color changes.

Was working on integrating my "dexcom-uploader" instructions with James' Wiki and did the "android-studio" download zip, import, etc. documenting stuff. After I added API 18 to SDK Manager, I got an error that the SDK Build Tools 19.0.3 did not meet the minimum requirement of 19.1.0. When I downloaded 19.1.0 build tooks via SDK manager, still didn't work. The solution was to modify "build.gradle" from 19.0.3 to 19.1.0.

My version of Android Studio is 0.8.2 on Windows 8.1.

I'm not sure whether people are deploying "dexcom-uploader" or "android-uploader" at this point... as James' wiki points to Android-Uploader (http://www.nightscout.info/wiki/welcome/the-android-app)

• Greg

XLarge xhdpi use preference fragments that try to bind values before they are defined. Temporary fix is to remove the bindings to verify.

This seemed to resolve part of the problem, but now there is a scenario where we try to bind the value with a dependency that doesn't have a default value. This was triggered by storage options because they are in a preferencescreen so the binding doesn't occur until the user goes into that screen.

This should remove the need for

When doing two finger stick calibrations during a sensor start / restart, the uploader does not upload both recent MBGs. It only uploads the most recent of the two MBGs. This occurs whether using REST or MongoDb upload. The missing MBG is picked up doing a gap sync. I seem to recall reading some code the other day that forced the uploader to only send the most recent MBG, but now I can't find it. :/

The graph doesn't move as time moves on.

0.1.6cwd

With the increased use of REST API for multiple sites, and the increased use of changing from "this configuration" to "that configuration", this enhancement request is to create and store a profile for a site with the REST API configuration, and then the REST API "base URL" could simply be "checkbox'ing" which one or more to do... This would simplify / mask the "make sure there's a space between configuration elements, allow for one or more sites, allow for quick testing and configuration changes, etc.

As discussed with Ben and Kevin I would like to localize the three parts of Nightscout. I'm Italian and I'm supporting the Italian community in order to setup and manage Nightscout and I think it would beneficial for many to have a localized software.
I'm translating android-uploader in Italian and German via a German friend of mine.

I hope I'm using the right tool to start a discussion and keep track of changes, if not please let me know.

Ivan

There seems to exist some perverse condition in which bad records from the future are inserted into mongo. Let's find it and squash the bug.

example

3914/9/4 19:27 61368028020000 98 Flat dexcom

pretty far in the future
at least your bg is good in 1900 years
bewest an hour ago
lol
boggles

3914/9/4 19:27    61368028020000    98    Flat    dexcom
3914/9/4 19:27    61368028020000    98    Flat    dexcom
Sun Sep 21 14:50:42 PDT 2014    1411336242000    96    Flat    dexcom
Sun Sep 21 09:20:43 PDT 2014    1411316443000    198    Flat    dexcom

ayiyiyi
where did that date format even come from?
eesh
this is the document:

{
    "_id": {
        "$oid": "541f3c53e4b086a044819ee6"
    },
    "device": "dexcom",
    "date": 61368028020000,
    "dateString": "3914/9/4 19:27",
    "sgv": "98",
    "direction": "Flat"
}

Would it be possible to get the battery information into the uploader? I know that Jonathan Moore has this working on his. Our new pebble app has it all worked in... Just need it to be sent from the uploader and the exception handled if they are not using the newest version of the uploader...

The receiver response to an egv query after the warmup period does not appear to follow the standard response pattern. The only way to recover from this condition seems to be to perform the initial calibration.

There have been A LOT of complaints about the uploader not working and receiving date/time mismatch errors. The users are doing nothing different and suddenly the error shows... One instance, user has both Rajat Heroku site and azure site. Received date/time mismatch error at midnight, documents stopped flowing to mongolab and azure site stale data. Heroku site continued to match dex the whole time.

This is serious. We can't have sites randomly going down in the middle of the night.

If the user selects the preference to upload Sensor Data, we should also include the noise value (clean/light/medium/heavy) from the EGV record. That value is used by the Dexcom to determine whether to display unfiltered (if noise=clean), filtered (if noise=light/medium) or ??? (if noise=heavy).

Beta Uploader REST API format has been refactored into "https://secret@url" instead of previous "secret@https://url". While the dev branch of "cgm-remote-monitor" supports both formats of the REST API, the current 0.5.1 and prior do not. As such, the release of the new uploader will break all nightscout websites running 0.5.1 or prior which use REST API.

In order to deploy new formatting of REST API, new "cgm-remote-monitor" must be deployed and the actual software release/deployment of the uploader CAN NOT be automatic push from Google Play because of the dependency on the new cgm-remote-monitor version.

The main purpose of the app is to get data to the cloud. The main screen should be focused on giving feedback about that purpose and less on displaying the graphical display. The status icons should be glance-able, perhaps as a grid of four tiles with the icon and then Check or X symbology in addition to colors.

We should have less than 80 as red and more than 180 as yellow.

I'm having issues getting the Dexcom update on a regular basis with my Nexus 9 (non-rooted). My previous Nexus 7 running Lollipop worked perfectly fine, but for some reason the Nexus 9 is not working as well. Are there any special settings I have to enable to get it to stay connected to the Dexcom?

hey all I posted in the google communities and was asked to post here as well to see if an alarm on the viewer or uploader was possible to sound when for what ever reason the rig fails to upload to the cloud .

example... one night we had the rig running all 4 icons on the bottom were green. the cell data dropped out and was no longer uploading. Hannah sleeps through DEX alarm for a low.

if there was a way to have either the uploader alarm or the view alarm when no data has been pulled from the cloud say after 20 min or have a few time ranges to pull from it might save a child that's hypo unaware like ours if they have a data failure during the night. hope that explains what I mean.. Regards Tom

Traveling this week, I found multiple instances where the CGM was still collecting data but due to various reasons, I was not uploading. I tried various methods to get the 2-day upload to occur but could not get it to happen in a repeatable manner.

The app needs a "Refresh" button with perhaps time-period options (1 hour, 2 hour, 4, 8, etc.) to avoid TOO many repeated points.

To reproduce what we saw flying to Hawaii and back, start with the Dexcom receiver and Android uploader phone both set to the correct time in your home timezone. Then, switch the uploader phone's timezone (making sure the time remains correct for the new timezone) and update the Dexcom's time accordingly. Then, do a gap sync.

When you do that, you'll see that the data displayed in Nightscout is all duplicated, with an offset of however many hours are between the two timezones.

The desired behavior would be that the android-uploader matches up the Dexcom receiver's time with the local time on the phone, and if they match, inserts new data using the local timezone. It also needs to make sure that data uploaded by gap sync after a Dexcom receiver time(zone) change is not an offset duplicate of already-uploaded data. (I'm not sure whether/how the internal timestamps change when you change the receiver's display time, but I believe at least one of the timestamps is unaffected, so we should be able to use that to verify no offset duplication is occurring.)

If this isn't enough detail to reproduce the problem or identify the solution, LMK and I'll dig into what exactly is happening in the uploaded data, and figure out exactly what it should be doing instead.

Only seem to be getting 4 hours out of the uploader?
biggest puller of data is android services from the looks of it with nightscout running at 6% prior android uploader seen far less android os battery use currently running at 54%
not 100% sure if fully related to beta test but only noticed the problems when we switched

There have been nifty prototypes floating around to implement opt in questionaires.
A few design requirements for dialogues like these:

• should offer way to revisit/revoke/edit answer
• should offer way to find more details

Set up for tracking. :-)

Sorry for the strange issue.
I saw that the wip/cookie branch was deleted and I would like to prepare a pull request, so I wander where the new repsitory graph is?

Definitely an odd use case, but submitting anyway.

1. Dexcom Receiver #3 connected to Beta Uploader, not set to expire for 3 days.
2. Changed Dexcom sensor and reset receivers #1 and #2 on schedule.
3. Received ??? on beta uploader (as expected).
4. Received a wierd Chinese character after the ???, but then returned to ???

Mongo db for "beta uploader" has SGV values of... 9, 6, 10, 9, 10, 10... I think the offending value was "6"... but that's guess.

The uploader does not appear to support multiple REST API sites using a "space" as the delimiter. (please route to Kevin Lee).

Attached is screenshot of configuration using one space between the two test sites.

My T1D neighbor parents have discovered a problem where the app gives up connecting to the network too quickly. They have a Moto X and the uploader starts as soon as the phone boots up... in fact it starts so quickly the app gives up with a Net Connection Error within seconds of starting up.

The workaround I found is to disconnect the cable from the phone during bootup, and give the phone a minute to connect to the Internet before plugging the Dexcom back in.

Note: this is for the previous version of the app (sorry I don't have a version number as the phone is not in my possession). But we decided not to update them to Cookie Monster, so we haven't updated the app either. Does the current app handle network connection errors better? Ideally it should wait like 30 seconds and try to connect again (and keep repeating that).

Hey -- been thinking about techniques to troubleshoot various "uploader" phone issues. Using "adb" seems to be the answer, and specifically "adb logcat"...

I've successfully connected by uploader (DROID MAXX) to my computer and connected using ADB and watched the main log and the event log.

It looks like we can filter for specific TAGs and priorities... and it looks like the code uses the "TAG" in the activity as the class.getSimpleName(). But to be sure, a couple of questions:

1. Is it scoped to just the 3 classes? Activity, G4Service and Reader?
2. Does the code log today in a way that, if captured, would help troubleshoot things?

Thanks.

• Greg

This kind of behavior can happen if while doing one of the operations between the two an exception will fire.
This was found in code review.

Should I submit a fix?
[email protected]

Tieing into Kevin Lee's wip/mqtt uploader, with event log access, the support team has been thinking about how helpful it would be to somehow see what is actually happening on an uploader rather than relying on what a user says or thinks is happening --

Had a nice conversation with Kevin..... here is what we talked about... concept:
If the uploader had a button to upload the last N lines (e.g., 250 lines) to the users own Mongo database to a new collection for "EventLogs" (or some other name), and there was a new mapping in the website API for the support technician to query /api/v1?action=viewUploadLogs

and the output simply dumped everything in the collection to the screen.

There is a chicken/egg for "first time users"... if they are having troubles getting setup, then will Azure be created? And to do this, the Support Team may need to alter instructions to have the user create Mongo, Azure, and then the Uploader to ensure Azure is connected as a prerequisite.

I notice the following, after switching to rest api, uploading of device status battery remains stuck at the last value before doing the switch. Comparing documents on the treatments collection I found a
{
"$date":
missing in all new values uploaded using the rest api, below an example of 2 datapoints:

Last good value
"uploaderBattery": 70,
"created_at": {
"$date": "2014-11-25T02:11:16.728Z"
}

New values after switch to Rest API

"uploaderBattery": 97,
"created_at": "2014-11-25T04:29:00.087Z"
}

Notice the missing
{
"$date":
after the semicolon in created at. Pebble thus does not show 97, but 70 from that point on if you are using API upload instead of MongoDB

Currently the Dex BG data in Mongo has a date string format of "dateString": "06/28/2014 09:58:52 AM", using the PWD's local TZ. The new devicestatus and treatments collections used by the dev branch have a date field format of "$date": "2014-09-07T20:25:07.796Z" and the time appears to be UTC.

In order to maintain data consistency, it might be a good idea to choose one format for all collections. It would make it easier to correlate data when troubleshooting problems with Mongo uploads.

I'm currently using an uploader built from WIP/devicestatus.

Hi All,
I am new to nightscout and am still trying to get my head aroud the code. I am T1D, and am wanting to reduce the complexity somewhat. I believe it would be best if the Uploader drove the following:

1. Units (mg/dl or mmol/l) driven from the uploader. Either read directly from the Dex, or as a preference setting. Setting is probably best, and would send the units and preference setting to either Mongodb or REST.
2. Alarm levels driven from either Dex (preferred) or uploader. Meaning that the levels would become "device info" like the battery level from the phone. If anyone has some documentation on commands and data that can be sent/retreived from the Dex, please point me to it, or send it to me.

These two things would make it easier for al in set up and operation of the system, especially for the T1D perspective.
Cheers

When using a tablet in horizontal mode, the rotation is ignored. The main screen should respect orientation. The preferences screens DO respect orientation.

Some users have reported that when they scroll down to turn 2 day upload off, they cannot turn it off or that the "I understand" toggle flips off. Do we have a work around for this?