These are chat archives for nightscout/beta

3rd
Oct 2014
Ross Naylor
@rnpenguin
Oct 03 2014 00:45
so disconnecting and reconnecting fixes it?
Ben West
@bewest
Oct 03 2014 02:05
oooooo interesting
PierreVandevenne
@PierreVandevenne
Oct 03 2014 02:52
Yes for the Dex. Quit and restarted the app on the phone. With the previous uploader, the uploader would stop doing anything until a press on the center dex button which the Dex would take immediately into account. Here, that's the dex that seems frozen. Had it twice today and twice yesterday (son seems to be going low 6-7 hours after his lantus)
Ross Naylor
@rnpenguin
Oct 03 2014 04:21
Sorry about your son going low :worried:
I hate going low :(
thanks for the info
if that happens again, could you please send feedback and in the comment explain what is going on so I can pinpoint it in the logs to try and recreate
Patrick Drews
@pgdrews
Oct 03 2014 12:59
Has anyone reported a bug with the way the REST API uploader uploads the devicestatus for the battery indicator on Pebble? I found that the devicestatus documents are populated different, and when the Pebble is pointed to an API site, the battery remains at 99%, even though the document shows accurate battery level, ie 31%. Below is a paste of the URI document for devicestatus and and API repectively.
URI*:
{
"_id": {
"$oid": "542e9a0e5f6aacf22bccee67"
},
"uploaderBattery": 30,
"created_at": {
"$date": "2014-10-03T12:43:58.344Z"
}
}
**API**
{
"uploaderBattery": 30,
"created_at": "2014-10-03T12:43:58.337Z",
"_id": {
"$oid": "542e9a0ed0c87c6c323808cd"
}
}
Jason Calabrese
@jasoncalabrese
Oct 03 2014 15:25
@pgdrews the order of the fields won't matter, I'm using the rest api for battery status and not having any issues. What does the result from the /pebble endpoint look like in a browser?
looks like the uploads via mongo are stored as real dates an the uploads from the api are stored as strings, that could effect the sort order, try emptying the devicestatus collection
Kate Farnsworth
@ELUTE
Oct 03 2014 16:02
It looks like this: {"status":[{"now":1412340694128}],"bgs":[{"sgv":"162","bgdelta":-1,"trend":4,"direction":"Flat","datetime":1412340205000,"battery":"99"}]}
Jason Calabrese
@jasoncalabrese
Oct 03 2014 16:03
can we try to empty the devicestatus collection, mixing mongo and the api may be the issue
Kate Farnsworth
@ELUTE
Oct 03 2014 16:10
I think They have different Databases
Patrick Drews
@pgdrews
Oct 03 2014 16:19
Different databases on different Mongo providers.
/pebble -> {"status":[{"now":1412353344940}],"bgs":[{"sgv":"10","bgdelta":0,"trend":8,"direction":"NOT COMPUTABLE","datetime":1412352804000,"battery":"99"}]}
I'll delete the devicestatus collection and see what happens.
Patrick Drews
@pgdrews
Oct 03 2014 16:25
We're in the middle of a sensor change...but the battery info above it what has stayed the same level.
Hehey - good call. Was the collection. Is reporting accurately now. Strange. You would have think over time it would have cleared up.
Patrick Drews
@pgdrews
Oct 03 2014 16:37
Just verified my two uploaders. The URI is pointing to my Mongo's on Rackspace, and the API is going to the site that is pointed to AWS's Mongos. So only thing I can think of was early setup may have uploaded incorrect info, but would have thought that would just clear out after 48 hours or something, Has been like this for at least a month or more? Was when the last big Azure/Mongo outage occurred on a weekend nite a while back.
Jason Calabrese
@jasoncalabrese
Oct 03 2014 16:44
so many moving pieces...
Patrick Drews
@pgdrews
Oct 03 2014 16:49
Yeah - I've got a few more then most with a couple DR/Test sites. I'm also testing the UptimeRobot and there was an alert on one of the MongoDB ports on AWS that I was monitoring the other day and it was down for 10-15 minutes at about 6am and I totally missed the emails. Want to see if that truly will detect a MongoDB issue/outage. Maybe will switch to text, but I just don't care to wake the Mrs. in middle of the night with a non relevant text message. Maybe will do that on the main one that we use for regular home "production" use.
Jason Calabrese
@jasoncalabrese
Oct 03 2014 16:51
some type of automated failover would be nice
Patrick Drews
@pgdrews
Oct 03 2014 16:55
I realistically could do two watch faces couldn't I? Would be good to try that on all three of our watches and would a good check of two different datasets, but also good for an outage scenario. Hmm.. Once the Pebble debacle smooths out will give that a whirl.
Kate Farnsworth
@ELUTE
Oct 03 2014 16:56
You can use the pbw's from the labs page for now.
Jason Calabrese
@jasoncalabrese
Oct 03 2014 16:58
yeah, I do that have 4 versions of the watchface sometimes
Patrick Drews
@pgdrews
Oct 03 2014 17:04
It's interesting seeing the response times to Mongo on the 3 carriers. I'm impressed that the Mongo's on Rackspace DFW is 0-3 miliseconds, and AWS US EAST1 and Azure EASTUS hover around 31, but AWS is more stable around 30-31 then Azure. RS is quick.
But, what I don't know is where UptimeRobot is sending the monitors from.
NVM....they are in Dallas. LOL. That's why. Ha.
PierreVandevenne
@PierreVandevenne
Oct 03 2014 19:37
MongoDB had a bit of downtime for the reboot of their aws servers. I first thought it was because of the bash issue, but it was for the xen issue that wasn't public yet at that time. They did announce the downtime on their status page but not the precise time. I run the node server on one of my local servers in Belgium and can run mongodb there as well, but on the whole mongolab is the most reliable piece of the puzzle imho.