Closed Pogman closed 6 years ago
Cool - hopefully that's working
cool animation... gradle build done. grab phone... and USB cable ;-)
Hey Whooze, you use this for yourself right? There is really useful offline support for the Urchin watchface that rounds this out nicely and would love to have some testing/feedback on. Here's how I use mine but this is highly customisable and can be as simple or complex as you want.
IOB, Basal - temp running 39 mins remain / 8 hours to next cal, bolus dual at 9:26 / 20% uploader battery 133 units in the pump 6 days life in the sensor and the date
@volkerrichert thank the xmas elfs!!! cool
Using it on my daughter. Got a pebble classic connected to my iPhone as follower. Gotta connect the pebble to the uploaded for this to work, right? Awesome watchface!
This will only work with all the extra pump info for a Pebble connected to the uploader phone but. It's still a good watchface for followers to use but without all the extra pump/treatment info.
Yeah, I figured that. Would be cool to have a watch face that could get all the extra info when not connected to the uploader.
When I see what you guys do I realize how little I know. My php-skills don’t really help, guess it’s time to change track of my programming
No problems to compile it here, I put the APK on my phone and fired it up.
1st thing that happend is that it halted and warned for low battery on pump. Got the pump and yeah - it was an alarm on it for low batter. Changed the battery and told the app to get back in business.
I got some errors: 00:48:59 Communication Error: retry failed, 0x81 connection busy (ReadHistoryRequestMessage) 00:49:03 Next poll due at: 00:50:46
It synced data again until
00:51:50 Communication Error: Pump sent a NAK(304:0F) response (ReadHistoryRequestMessage)
Again, it started to load data again on next poll.
This is amazing guys!
Those errors are fine you will get them depending on radio noise or if the pump is busy it just refuses to accept the request - the thing to note is that it defers the request and retrys and everything is handled automatically
If you dig into the setting you can get all your historical data too - you may need to refresh or clear your browser cache to see the data updated in your ns reports - I'm hoping the NS guys can sort that out
Yeah, I tweaked thoose settings before I even plugged it in :)
I bugged ya on gitter too, lol
What will happen when I direct this app to the "real" database. There are loads of gaps and a few manual entries there, boluses I've entered and temp basals I've put in too...
Is it better to put this in a clean database?
It will clean out the old data and fill all the gaps in for you up to the last 90 days - goodbye carelink forever! Note it may take some time as it does it all async so as not to get in the way of keeping the polled sgv current.
It only needs to go through that process once and then it's always fast and up to date
Fabulous!
Any known issues?
It's stable enough to use on a day to day basis? Paying extra attention since it's beta and all, but hey, perfect week to try this out, holidays and all
When it does the clean out it will keep any note you made - for issues I don't know but there may be something in the profiles to fix - it's all running perfect for me and the way I use this stuff but everyone has there own use case so the real testing has begun!
History Sync Enable upload of past historical data to Nightscout. Backfil days as set in advanced settings for CGM and PUMP history (note: this will clear and refresh data where needed)
It halted on 2017-12-18 This setting is in the pump?
Ok - when you first started this version it recorded the the time and will only push new data after this time., this is in case you want to preserve any old data in NS. when you enable that setting it will start pushing historical data up to 90 days worth (the default is 7 days and changed in system settings).
aaah, there it was, found it, wow, I'm stupid. :(
Have put my phone on charge for a while and will plug it in and make sure it keeps pushing the new stuff before I go to bed.
If you stop it it will resume the task next time you use it even if it's days later - it's very tolerant of the messy real world (I hope)
gonna see what happens now.. I fired it up to my beta-site. Have now switched to the original site and it started to backfill where it finished last time. Maybe it will go back and backfill the stuff that's on my lab-site later on.
Got Error uploading: java.lang.NumberFormatException: Expected an int but was 9.4 at line 1 column 717 $[3].carbs
Yeah this is what I want to hear about - I don't use the wizard much so things like carbs need testing - are you mg/dl or mmol?
mmol
Hmm, it ain't pushing new stuff either, I see it on the uploader but it's not being pushed to the site
you may need to clear your browser cache also it has to limit uploads so as not to overwealm NS with data - it will get there over multiple passes, this really only happens when it's doing this big big data pull
k, we'll see what happens :)
I see that al CGM-data 90 days back has been deleted oops
Hopes it manages to put the real thing there instead
at least the deleting works lol ;)
2017-12-18 and newer is still there (that's the stuff that got pushed to the beta-site)
it won't upload anything more if it's hitting that "int" error
I figured... should I just try to find the bad stuff and remove it?
I could just rename the old treatments and entries and let the app fill it all back up without the old clutter
Need to understand why you got that error as it shouldn't be possible really, can you run this with logcat or bugfender for more detailed logs?
Sure if not just clear your stuff in mlab and you should get your 90 days back.
Actually did yo have any manual entries with carbs = 9.4? or were you using the older "treatments" branch (that may have pushed non "int" items)
Naaah, never runned anything else but the original uploader.
I'll try to just rename the treatments and entries for now and see if I can push that to my beta-site tomorrow for further testing.
When it comes to logcat or bugfender I don't really know how to do that, but maybe you can point me in the right direction there?
Sure don't worry about it - do what you said there and if it works it gives me a clue to where to look or add a error check of some sort
It pushed the new values that I missed for the last hour or something + updating new values.
It have backfilled CGM data 2017-12-17 and back to 2017-12-11, seems to be chew it way through the data
Gonna let it work without my interruption now :)
Time to get some sleep!
It backfilled nicely from 2017-09-27 to 2017-12-17. The data that it backfilled to the lab-site haven't been backfilled to the "live-site".
Any way to trigger a new backfill to get the stuff from 2017-12-18 to last night?
Guess it will sort itself out when I put the new version on the real uploader-phone, that will trigger a new backfill
when you run the uploader on a different device it will pull all the data again from the pump and upload only what's missing in NS
also if your using profiles Ns has bugs related to multiple profile groups (this will be explained later)
for now set in the uploader "single profile group" and "offset start date" to enable
I tried to get bugfender to work, the apk was built and everything looked good, I installed it on the phone but the app crashed on launch.
Had to fall back to an apk without crashalytics and bugdefender. Plugged in the meter and it backfilled the missing data, except for this day
The report looks a bit sketchy
Correct times are 1Unit @ 2017-12-25 23:08 0.4 Units @ 2017-12-26 00:30
Guess that is a nightsout-issue though and it will probably be correct by tomorrow
If you got an apk you want me to try out I'm more then willing too, sucks to not be able to provide any logs
Are you using other apps that are sending data to NS? It says "Android APS started" in that screenshot? Also are you using the latest version of NS? And always to be sure - clear the browser cache.
Don't worry about getting program logs for now and if we really need to look at them we can sort out an apk.
Also make sure the clocks on all your devices are getting their time from the network with correct timezones.
If you think the wrong data is being sent by the uploader to NS have a look at the treatments tab in the reports and see whats up there.
Yeah, I turned on AndroidAPS for a while last night to see what it recommended. Gonna check out the treatments and make sure all clocks are synchronized later today
There shouldn't be any problem with running AndroidAPS too though it might muddy the waters when looking for bugs. Your data looks good to me and even those times that look wrong are just being represented a bit off in NS - that's probably a NS issue though and I think it was something they fixed in a later version.
Gonna check this out asap! Thanks a bunch!