Add predicted iob data to broadcastservice

[bigdigital]

Some people would like to see predicted(simulated) iob data on the watch. So this PR extends the broadcast data with a predicted IOB and BWP info.
Also it enables not simple mode in defaultLines function in order to receive simulated data including predicted lgraph lines.
The 28.01.2023 updates.
added cancel_alarm not notify remote devices in case alert were stopped
added external status line in extra key as string + timeStamp

[tolot27]

IMHO this always sets the variables to an empty string which does not change till line 569. Maybe you should initialize the strings to "" in line 84/85?

[bigdigital]

This is a place where the variable resets in case if the iob data would not be updated in BgGraphBuilder.

[bigdigital]

But in case if settings.isDisplayGraph() is false, the predictedIOB and predictedBWP always would be empty. Maybe it would be better to transfer iob only if graph is enabled.

[tolot27]

The only location where predictedIOB and predictedBWP are set to likely non-empty value is in the statusReceiver onReceive event. The next use is bundle.putString("predict.IOB", predictedIOB); but right before the if condition these two variables will be emptied. Hence, an empty string is always passed to bundle.putString. That's my main concern. Did I oversee anything?

[bigdigital]

Yes. the variables are filled via statusReceiver by receiving the broadcast messages. And those broadcast messages can be triggered by bgGraphBuilder.defaultLines(false) function which calls addBgReadingValues(simple) and the last one function calls Home.updateStatusLine("iob", df.format(iob.iob)) . So when the code reaches to the bundle.putString , the iob and wpb values would be filled with the valid data.

[bigdigital]

@tolot27 as i understand this pr was stuck because the "bwp" and "iob" broadcast data which is generated in BgGraphBuilder transfers with help of sendBroadcast finction which is runs asynchronously. Maybe to resolve this problem we can change sendBroadcast in updateStatusLine to sendBroadcastSync which should block the execution of the thread .

[jamorham]

What about using the keystore data like is done with bwp_last_insulin in PebbleDisplayTrend ? I could easily add more keystore fields if this doesn't include everything needed. Then you don't need to worry about asynchronous broadcasts.

[bigdigital]

Yep. I guess this should help to transfer data across different parts of the application. It is enough to add bwp_update data (but maybe better to divide the current string inot two separate variables with the carb and insulin info). And a separate keystore for "iob" which is declared by this line Home.updateStatusLine("iob", df.format(iob.iob));

[jamorham]

I have added both, let me know if this helps: 094b09c

[bigdigital]

Yes. Now works fine, added appropriate code changes

[4RK4N]

so what exactly is blocking the merge of this PR ?

[Navid200]

@bigdigital Your last post in this PR is a question. Do you believe this PR is ready as is?

If this PR is merged, what else could WatchDrip need in the future that would require another change to xDrip?
Is it not possible to create a mechanism that would allow editing what Nightscout sends if needed in the future?
For example, is it not possible for WatchDrip to request a parameter and xDrip sends it on the next broadcast? Then, if 2 months from now, WatchDrip needs another parameter, you will not need to open another PR. You will just modify WatchDrip to request something that it did not previously.

Or, is that not practical?

If that is not practical, can you think of any other parameters that may become required in the future and include them right now in this same PR?

Please note none of my comments are needed to be answered and addressed. I am just hoping to help the conversation flowing.

[oakeley]

Please could this be added to xDrip? This would enable so much. Many thanks @bigdigital for proposing it and @4RK4N for seconding it

[bigdigital]

Do you believe this PR is ready as is?

The last time i tested it, it works fine.

If this PR is merged, what else could WatchDrip need in the future that would require another change to xDrip?

Maybe a small fix to transfer the dismissed snooze alarms action to the watch bigdigital/watchdrip#4

For example, is it not possible for WatchDrip to request a parameter and xDrip sends it on the next broadcast? Then, if 2 months from now, WatchDrip needs another parameter, you will not need to open another PR. You will just modify WatchDrip to request something that it did not previously.

This would be of course great, but as i know there is no such global variable store, where you can get all those values. For example, predicated IOB and BWP are not stored anywhere. And updates only by graph update.

[4RK4N]

Do you believe this PR is ready as is?

The last time i tested it, it works fine.

If this PR is merged, what else could WatchDrip need in the future that would require another change to xDrip?

Maybe a small fix to transfer the dismissed snooze alarms action to the watch bigdigital/watchdrip#4

For example, is it not possible for WatchDrip to request a parameter and xDrip sends it on the next broadcast? Then, if 2 months from now, WatchDrip needs another parameter, you will not need to open another PR. You will just modify WatchDrip to request something that it did not previously.

This would be of course great, but as i know there is no such global variable store, where you can get all those values. For example, predicated IOB and BWP are not stored anywhere. And updates only by graph update.

adding parsed iob cob and maybe tbr data from the external status line aaps sends into xdrip would be good. i have a hacky modification doing that right now. for a proper PR the ExternalStatusService.java would need a getCOB() added and maybe some testing on getTBR(), getIOB() and getAbsoluteBR() if they output the desired result.

many xdrip users also use aaps and in turn the xdrip predictions are not as good as aaps predictions. which is totally ok since that's not the primary purpose of xdrip. but to have the aaps external status data sent by the broadcastservice would help aaps users a lot.

EDIT UPDATE:
i cleaned up my xdrip fork and sent a PR with the changes to @bigdigital to integrate it into this PR.
ExternalStatusLine now gets transmitted as a string as-is with a timeStamp added in a seperate bundle field. Further parsing can be done in the recieving app (watchdrip) if needed.
here is my small addition: bigdigital@90369a2
I hope we can get this merged soon.

EDIT UPDATE 2:
i compiled a new xdrip with tis pr merged in. no problems so far. im also using the sendBroadcastSync() change mentioned earlier in this PR #2294 (comment)

[bigdigital]

Thank you. @jamorham