Battery Level added #7
Conversation
|
I'm wondering if we should add a different have a different entry for the uploader device info. Combining with the dexcom entry will cause us to send the battery info lots more times than we need it. Also it might be nice to send info about the uploader phone even when the dexcom transmitter is out of range. For the uploader the change is really simple, just add an extra entry outside the the for loop, change the type and remove the dexcom info. That would complicate things a little for cgm-remote-monitor but I think it could be transparent for the web client and pebble app. A couple of other little things... Should we keep the battery level and int if thats what we get? We should seen the same info to the rest api also. |
|
I agree it should be its own document. I would go a far as saying that the battery level should not change much in 5 minutes and is not as user critical as sgv values, so I would only send when it changes by 5/10 percent increments in light of saving data usage. |
|
I'm thinking the uploader type entry will useful for other things too. Could include gps info, a ping to let you know the device is still working, if the dexcom is attached, lots of interesting things we can tack on later. |
|
Yeah, I like the idea of sending info even when out of range. GPS would be pretty cool. This could be done in additional uploader class for device info. I am working on getting all the read commands for the Receiver. One of these command is a basic ping that lets you know that you are connected to the Receiver. This will be a lot better when first starting the app instead of waiting till the download has completed to know that it is connected. |
|
I was afraid of sending the battery level too many times so thanks for that verification. I must admit I kind of hack and slashed that one...lol. It got a working prototype going though so that was cool. I am not so familiar yet with the Mongo DB stuff...but perhaps when the app is first launched and a connection is verified create a new collection to which you can send all the status info too. That way the user does not have to create a specific collection themselves prior and thusly helping prevent another troubleshooting issue? |
|
I've been planning to have multiple types of entries in the same collection, we can then easily filter by type or not depending on the need. |
|
Ok started reading more on the MongoDB stuff. I see how you can create a document in a collection and query it. I can perhaps rewrite some of the code for the battery level to be only updated on a single document and update it after so many minutes from the uploader. Cool stuff. |
|
I was able to finally figure out the whole mongodb create one document and only update that. Each time I make a code change do I have to re-pull a request or does it merge with the request I already made? |
|
I don't think we should keep updating the same doc, just only add 1 new entry doc for each time we upload. Instead of the current behavior where the battery is added to every dexcom entry. Also just commit to the same branch will update the PR |
|
Ok so rewrote some things to make it cleaner. Was experementing with a few things. It does seem like updating just one doc is probably the best option because you can also store other data like GPS, or Device name all in the same document and just update that one document. Then on nightscout just query that one document to get your values. If you look through the changes I made I think it will make sense. I'll see about possibly getting GPS cords passed through but I am concerned with battery drain and need to do more research. Obviously make it on/off option in preferences in the app. |
|
With a single document you wouldn't have any history. I think of the entries as immutable, once created they shouldn't change. |
|
I didn't think you need a history of battery levels....just the current one from when you pull it from the android phone. Is there something else you are thinking about the battery levels and history I am not in the loop on. =) |
|
I'm wondering if it would be possible to add MQTT first, and then add battery status as one of the mqtt topics. |
|
Then the business logic can live in the cloud. |
|
I think 1 document is fine that is just constantly updated, but I am fine with either. But I don't think that it should be sent every time that the receiver data is sent, that seems like a waste of data because battery levels should not change much in 5 minutes and I would only see value in precision of 5 or 10 percent change. |
|
If everyone feels better about a single doc that get updated it fine with me, we can always do more later. If we do that we should create a new collection, like we did for I don't like making everything wait on everything else and this is in a functional state, there are lots of people that would like to use it now. |
|
Lets focus on getting the api asap |
|
Was not aware of the API...I guess I should look at what others are doing...lol. Once that is merged I can certainly modify my code to conform to that. In the meantime I needed a place to play with and the single document idea fits the bill temporarily. |
|
New pebble watchface is designed to use the battery upload information. We are commenting out that bit until it is ready from here but it would be a fantastic feature for the community. |
|
Just so everyone knows I have been testing it out the last few days and it has been working great. I have been trying to wrap my head around the new api and wondering how to integrate the battery level changes into it. I just don't have a firm grasp of the new logic yet and don't want to make any changes to it until I have a clearer understanding. I might need some help with some explanation on where you want the value stored...and once that is done we can roll from there. |
|
I would love to test it too if you don't mind. Empty space at the bottom of the new pebble face is bugging my design senses... On Jul 31, 2014, at 11:22 AM, m2oore [email protected] wrote:
|
|
In the mean time...I can tease you with what my watch looks like. =) |
|
Should the label and battery be above the line? CGM on the top, pebble on the bottom? |
|
and I still want to see the 2 clocks show something different, I've never seen it |
|
Jason, if you would like to be in charge of coding and design be my guest. Sent from my iPhone
|
|
@ELUTE, the label/battery location was just an idea, not something we need to/should change now. I am worried that the 2nd clock will create confusion, and it's also some very valuable real estate. |
|
I suggest an icon that only shows up when the times do not match then. users need to know when there is a failure. There are many people (especially pairing the pebble to the uploader) who find that it gets stuck on 3 minutes ago etc. Just because it does not happen on all watches does not mean that it does not happen. On Jul 31, 2014, at 6:31 PM, Jason Calabrese [email protected] wrote:
|
|
@ELUTE, thats exactly what I've been thinking, if we can use the pebble tick timer service, the clock on the bottom will always update no matter what happens with connection to the phone or network. Then we can continue updating X ago so that it's always accurate, even when offline. Add a strike through or something to the BG and use a different icon for the trend arrow, but this doesn't all have to happen in 1 shot. This should be really be getting debated at nightscout/cgm-pebble#16 I'll echo a few things there now |
|
You could do like we do for DIYPS and show the time of the last data point -Scott On Thu, Jul 31, 2014 at 3:07 PM, Jason Calabrese [email protected]
|
|
How far out are we from being able to merge this? Even if it gets sent with the documents for now... I think the community would really like this feature. |
|
@ELUTE I've been trying to get the pebble update accepted by the community and merged. I guess people were busy over the weekend and I didn't get much feedback. See nightscout/cgm-pebble#16 and https://gitter.im/nightscout/beta |
|
I was referring to the battery piece here. Can we get that merged into the uploader so that the battery will function in the pebble watchface? On Aug 4, 2014, at 4:41 PM, Jason Calabrese [email protected] wrote:
|
|
We recognize the value of doing this, but I wonder if we can treat this as experimental for awhile? I've talked this over with a few engineers, and we don't think it's a good idea to combine sgv records with battery levels all the time. We've come up with an alternate plan to report battery status that does not involve sgv records. My proposal is that people who are very interested or really need this get help using the "experimental" branch and that we work on getting the extensible/pluggable code into place so that battery status does not affect sgv records or sgv uploading. Then we can merge the use case into what presumably would be tested/pluggable/extensible code. What do people think of treating this as experimental, and slating it for integrating with a configurable/pluggable architecture so that battery does not depend on sgv, and sgv does not depend on battery? |
|
So if you have looked at the recent submission of my code. I changed the behavior of it adding the battery level to each SGV document. Instead I decided to create just one document and update only that one document only. We can use that single document for other more singular values that we can pass from the android to the database. This document does not interfere with SGV at all and is not part of any of its search returns when you query those values into nightscout or pebble. Infact you'll notice I had to create a separate query to find just the document I created and stored that battery level value in. I agree doing it the first time I had that value stored with each SGV entry....that was my sortof experimental way of seeing if I could get it to work. I think with the way I have it now it works rather well. I have been using it for about a week now. |
|
Can we at least merge this into a branch? I would love to move forward with this @m2oore |
|
I don't have this working with the lastest big update to the CGM-Monitor as I have not figured out the api stuff. But, I pull requested the Android app and your version of pebble has the battery level code in it. The only real thing to do is to merge the android app...or download from my repository. And update the Latest CGM-Monitor with the code needed to consume the battery level information. |
|
Nice, I hadn't seen that, sorry to be out of touch! In that case, I'm nearly swayed; there are some good arguments on the mailing list from Adrien regarding premature modularity/optimization, and you make some compelling points (so does Jason C). I think the remaining concern is just around the frequency of the battery updating:
Some people are questioning the value of showing 86% battery vs 85% battery. (A lot of work was done by Lane and Ross to iterate, add/remove information; battery status might not be relevant unless the battery is nearing low or changing a lot.) Would be interested to hear your ideas on tweaking the frequency. Looking forward to getting this integrated for people. |
|
I thought there was a branch somewhere for this already. |
|
Sure that can be tweaked as we go along. But, I can attest that having run this now and the data is very minimal. I am only using 15% of Azure's daily data limit per day from the free account. Roughly 20mb out of 165mb limit/day. I am sure that is more from the sgv data then the uploading battery level data. I kind of like to see the percentage change from the 1 digit level because I can tell if a battery is draining faster then its supposed to be....also we were going to incorporate a blinking battery icon when it reaches a certain critical level and a minimal amount of vibration to just alert the user. As for the branch I did the pull request with the latest code for Android Uploader off the master branch via my fork m2oore. Hope that all makes sense. |
|
Yup, makes sense, I'll take a closer look at merging into on of our branches later today. For more clarity, I'm not worried about Azure (they only track data-out). The data rates I'm referring to are the cell data: I expect this to add ~20% to the payloads. When we switch to mqtt + protobuf, the data through put should be cut by a factor of 6 or so, so I'm not too worried about it. For people paying per |
|
I am using Ting and pay as you go and I typically only have been using 2 I only have 7 days left of my bill and I have accumulated 22mb of total On Tue, Aug 5, 2014 at 1:00 PM, Ben West [email protected] wrote:
Jonathan Moore |
|
Good stats! Thanks. Are you using wifi at all? How many hours of the day are you using cell data plan? (I'd like to get 24 hours of cell data use well under I'm seeing spikes of up to 5MB/day on occasion, do you see this? |
|
I do use wi-fi I am not using the moto g 24/7 on data network....but when And it totally makes sense on getting an idea of total day usage. I just On Tue, Aug 5, 2014 at 1:15 PM, Ben West [email protected] wrote:
Jonathan Moore |
|
Some changes I'd like to see:
|
6 participants
This is the code used to get the battery level updated through Android Uploader to the MongoDB and then pass it to Nightscout and the Pebble.