Added loop status support for pebble showing TBR + IOB

[JoernL]

The data is send to the watch with a delay of 20sec because of connection + reaction time to the pump. The delay can be modified in Line 39.

[jamorham]

Can you explain what this delay is for?

[JoernL]

This delay is necessary to display the latest loop status. AAPS needs some connection and action time for setting treatment data. Without delay, outdated (5min) loop data will be shown on the watchface. The delay time depends on connection speed of pump model. Dana R is faster than Combo and i think 20sec should be enough. For Combo users maybe 30-40sec would be necessary. The best solution would be to send a new packet to the pebble right after the StatusLine has been updated.

[jamorham]

Hi there,

I am sympathetic to what you're trying to do with this PR but there are problems with this implementation. So I'm adding facilities to make doing this cleanly much easier.

The PR doesn't have sufficient consideration for the use case where the user isn't using AAPS or discontinues using AAPS. For example if the status line is null I think you're even going to get a null pointer exception and crash the app, but it also changes the overall behavior in a way which will affect users who are not using this new feature.

There is a base class for pebble watch faces and it makes sense to ensure that the communication protocol for the watch faces is shared by all. So I've moved the existing keys in to the base class to make this clearer. Your existing TBR and IOB key numbers would clash with the implementation of trend. So those will need to be renumbered.

See here:
7e68733#diff-21b6faa660d6896fd19381c1d6f262b3

I've adapted the ExternalStatusService so that it now stores the status line using the PersistentStore class and moved your TBR and IOB parsing in to that class as that is where the responsibility should be for those. It also now polls NewDataObserver.pebble() to push an update to pebble whenever new external status is received to avoid your introduced delay in the PR.

The mechanism for retrieving the status line currently will return "" if the data hasn't been updated for 8 hours or has never been received and I've modified the getTBR() and getIOB() so that if there is no input then they will output nothing instead of ???

This means we can make the sending of these records to the watch face conditional on whether there is any data to send, eg whether someone is even using AAPS or if they stop using it then after 8 hours the data will effectively be cleared out.

The watch face similarly can be made to only alter the display if IOB and TBR data is presented so that existing users will not notice any change unless they are using AAPS. We also can control the sending of this through a pebble setting within xDrip+ to give even more control. This also gives us portability to add the same data keys in to the Trend watch face.

7e68733#diff-21b6faa660d6896fd19381c1d6f262b3

Please let me know if you think what I've done so far makes sense

[gregorybel]

we did something similar for wear complication, now it looks to me we store two times the loopstatus in the persistent, could this be the case?
if yes, should we not change this or that doesn't matter so much?

[JoernL]

Yes @jamorham , you're right! My thoughts were that there will be 2 standard watchfaces and if a pebble loop option is enabled the loop-face will be installed on watch. I don't have that android coding skills to implement a pebble broadcast after loop status was updated. That is the reason why i had done this in the easy rookie way via a delay ;)

[jamorham]

@gregorybel Isn't it just forwarded to wear but not actually stored on the phone side but then is stored on the wear side? I don't think that should matter too much.

[jamorham]

@JoernL Well I think that the ideal is that there is a single version of each type of watch face and that if loop data is present then it can show on the watch face via conditional code. I did already unify the code for the color and classic trend watch faces in to a single one and there hasn't been any development on the other watchfaces for some time.

Can you upload a screenshot/photo of how this should look on the watchface you have produced so far so I can see how the data is presented?

[JoernL]

No problem, i will post it tomorrow.

[gregorybel]

you are certainly right, I missed where storage is done, sorry.

[JoernL]

[JoernL]

I have included all your patches and temporary modified it to work with the standard watchface (IOB_KEY,TBR_KEY numbers + copied getIOB() and getTBR() to PebbleDisplayStandard). Works
great! ExternalStatusService calls NewDataObserver.sendToPebble() which calls PebbleWatchSync.class.
directly when a new StatusLine is present - great and without the delay... thanks! Now this should be able for trend watchface, too. But maybe there is not enough space for the loop data. I have to check this out.

[tuzoenduro]

When will this be implemented on the xDrip+ interface? (IOB through the watchface to Pebble).

I'm on a 640g, using Lennarts app to get the info from the pump and then xDrip+ to send it to my watch. I don't go directly through Nighstcout since it's only me and an extra phone contract is expensive here (Spain).

As it is, I don't get the IOB or COB info that the transmitter phone is mining from the pump, and if posible I would love to have them.

Thanks!

[rentedjock]

Hi, I didn't know where to comment, but can I request you guys to modify the app to accept data from miaomiao attached to libre freestyle pro? The app accepts data from libre freestyle and not from the pro one. I get checksum failed. Please help, and let me know where I should comment if this isn't the right place for it. Thanks in advance

[Foxandxss]

Quite the old thread, but can we get IOB on xDrip? It would be nice for the watch.