Add Device Name/UUID to upload.

[someoneAnyone]

It would be great if the uploader could provide more detailed device information to the database. Currently, the app uploads the uploader's battery status with a date only.

Many NS users leverage multiple uploaders, so it would be helpful to see which device was doing the uploading at a specific time, as well as how it was uploaded (wifi/cell).

Current:

{
    "_id": {
        "$oid": "5448417a45080e31c31e0107"
    },
    "uploaderBattery": 86,
    "created_at": {
        "$date": "2014-10-22T23:44:58.135Z"
    }
}

Proposed (extending the current structure):

{
    "_id": {
        "$oid": "5448417a45080e31c31e0107"
    },
    "uploaderName": "Device_Name",
    "uploaderConnectionType": "WiFi",
    "uploaderBattery": 86,
    "created_at": {
        "$date": "2014-10-22T23:44:58.135Z"
    }
}

or Another Proposal (maybe overkill, i've seen similar structures for other IOT devices like Nest)

{
  "_id": {
    "$oid": "5448417a45080e31c31e0107"
  },
  "uploader": {
    "name": "Device_Name",
    "device_id": "26f53136-b527-11e4-a71e-12e3f512a338",
    "batteryLevel": 86,
    "connectionType": 1,
    "lastConnection": "2014-10-22T23:44:58.135Z",
    "isOnline": true,
    "isUploading": true
  }
}

[trhodeos]

Good idea. I'm pretty sure @ktind is adding this to the upcoming mqtt stuff. We should be able to port it back to the mongo uploader and the rest api pretty easily.

[jasoncalabrese]

If we add id's we should include both the receiver and sensor id's

[francescaneri]

In this way you could incorporate NightClock @arbox0 @trhodeos @jasoncalabrese

[someoneAnyone]

@jasoncalabrese, I like that. Something like... maybe?

{
  "_id": {
    "$oid": "5448417a45080e31c31e0107"
  },
  "uploader": {
    "name": "Device_Name",
    "device_id": "26f53136-b527-11e4-a71e-12e3f512a338",
    "batteryLevel": 86,
    "connectionType": 1,
    "lastConnection": "2014-10-22T23:44:58.135Z",
    "isOnline": true,
    "isUploading": true
  },
  "transmitter": {
    "name": "Device_Name",
    "device_id": "26f53136-b527-11e4-a71e-12e3f512a338",
    "batteryLevel": 86,
    "connectionType": 1
  }
}

[someoneAnyone]

I was thinking the connectionType could be an enum, that matches up to one of the following... 1. Wifi, Cell, USB On-the-go, Bluetooth, etc..

[ktind]

I've toyed with similar ideas off and on - my early prototypes even included similar concepts. I like it and I have a proposal on the table to include receiver SN and a unique identifier for the uploader but it only covers MQTT.

Devices like the Nest usually maintain an open connection to a server. This is something we do with MQTT, but we also intend to rely on HTTP as a fallback mechanism. Maintaining an active connection makes it almost trivial to detect when a device goes offline (last-will and testament feature of MQTT for example). HTTP on the other hand will require server side calculations and some inference. We need to clarify exactly how presence reporting, detection, and logging will work in our system as a whole.

I'm thinking that some of the data listed above (lastConnection, isOnline, isUploading) needs to be determined server side. I don't believe that the uploader is the right place because it should be calculated relative to the server. I have a few questions on your proposals:

• If I'm uploading a record, that implies that I'm online, no? Unless you intended for the isOnline attribute to indicate whether or not the receiver was connected to the uploader.
• If I create a record that I'm online, would that not indicate that I am also uploading?

We should be cognizant of the amount of data that is added to each upload. There needs to be a cost/benefit analysis performed when adding new elements. Protobuf was responsible for a dramatic reduction in data with MQTT. Maybe we should also consider a protobuf payload for the RESTful calls as well. With around ~8600 device readings in a phone billing cycle, adding a few 100 bytes per upload may seem harmless, but it could get expensive for the user. I'm sure that we can eliminate some of the redundancy with the less volatile data (e.g. device id, receiver serial number, connection type, or sensor id) by only sending it once per session or something.

IMO, this is something that is worth looking into that needs more discussion with the larger team due to the impact on the system.

[jasoncalabrese]

There's also the issue of correlating the device info and the SVG, MBG, CAL, etc data with the device data, what happens when there are 2 uploaders?

[someoneAnyone]

@ktind, I was thinking the isOnline BOOL would be more of the device attempted to upload (sort of like a heartbeat) but had no data from the device. When all is good in the world both would be true. I figured it could help in troubleshooting via a remote interface (the website). Reason I thought this would be useful is because sometimes the uploader will be connected but lost the data stream from the CGM and either requires an app restart or re-plugging of the cable.

[someoneAnyone]

@jasoncalabrese, I haven't completely modeled what the data could look like, but can we setup a relationships? For every Entry record, have a id field for the upload record?

[someoneAnyone]

As a novice, how does MQTT play into this project? Is it similar something like, RabbitMQ (pub/sub message bus)?

[gangfc]

I see two issues here..Losing the data stream from the uploader to the dexcom receiver seems to be a new bug. In older versions I could let the uploader run for days and weeks without having to connect/disconnect the dexcom receiver.

[francescaneri]

@gangfc is from a few months to use the program but I can confirm that. in more I would say that is not seen on the screen when the trend of the graph before the upgrade to version 0.1.12 it showed.
@someoneAnyone if it bothers you that comments say it without problems;)
@ktind @jasoncalabrese thinking of transferring the data we are interested in when you connect the phone could be a solution to be able to risparmare data space and still get the information we need. (Wifi, Cell, USB On-the-go, Bluetooth, etc ..) while SVG, MBG, CAL can be transferred in the usual way. thanks Matteo