olorinmaia
commented
2 months ago I agree to some extent that some of these functions would be handy to have in AAPSClient, but there may be technical limitations for how this is handled through NSClient API that limit what can be done, can be better answered by @MilosKozak . There is also a concern about security and potential overdosing when more than one device can administer boluses directly.
"SMB calculations and status" is available in Nightscout and AAPSClient by clicking on OAPS / OpenAPS button in overview screen. It's a summary though, and doesn't contain all the info available in debug-screen in SMB-tab in AAPS, but for my part, it got all I need, which is mainly calculated "insulinReq" and SMB size.
"Temporary Basal modification" is handled through oref, and can be affected by setting temporary target and shouldn't be needed for interference from AAPSClient.
"Preferences" "Loop Status/settings" "Pump settings, history and configuration" None of these are needed to be configured or viewed so often that syncronization between AAPS and AAPSClient is needed imo. An option in those cases where child is far away and you want to change things is Teamviewer.
Did you know that Wear OS got support for communication with phone through internet/esim/wifi? :) This is a function that is automatically enabled on Samsung watches and when bluetooth connection is not available the watch can sync over Google Cloud with phone. I actually disable bluetooth on the watch connected to AAPS phone and only communicate through Google Cloud. That way I can use AAPSClient on my phone and AAPS wear to handle my son's AAPS. That way I can give bolus if needed, allthough he isn't in bluetooth-range. It works very well for us. With this setup, it isn't really needed with SMS commands.
More info about Google Cloud Sync Service and remote control via wear OS: https://developer.android.com/training/wearables/data/data-layer#connectivity https://androidaps.readthedocs.io/en/latest/remote-control.html#remote-control-of-aaps
MilosKozak
I am sure that I am bringing up a topic that has been discussed at great length - with many differing opinions and points of view. I apologize that I was not a party to previous discussions, and if these are limitations of developer time and effort or legal matters, then I apologize up front. My goal is to determine if I am missing anything in terms of the trade-offs between excellent DM management and safety when it comes to the AAPS client. BLUF - why are certain features are included in the client app and others excluded? I do not believe there are any technical hurdles that would prevent the AAPS client from both (A) displaying the same information as the master or (B) having the same functions and control as the master.
The use cases for AAPS client that I can think of are:
None of these situations would preclude the AAPS client mirroring exactly the function and display of the master in terms of safety - in fact very much the opposite. While the SMS features do allow remote commands, including bolus, I am not willing to use it in most scenarios because I do not have access to the information about why previous decisions have been made or any details of the calculations involved.
It appears that at least the following functions are not available in AAPS client:
The one area that I believe there is reason for concern over is possible confusion between AAPS client and master on the same phone (controlling two different people), however there a lot of options for mitigating that risk - additional authentication (2FA as used in SMS), notifications and/or confirmation. Authentication/verification to enable full control should be implemented over feature removal in the client.
I am diabetic and I have a 5 year old daughter with T1DM, and I cannot possibly state how grateful I am for the existence of this project and the example it sets. I have spent a great deal of time and money on phones, remoting software, rooting, bypassing security features, etc. so that I have full control and visibility - and yet it all fails with poor signal as not enough bandwidth to successfully remote. Stating the obvious, my daughter is not in a position to be aware of or make any decisions regarding her insulin pump, and I am struggling to think of a scenario where someone is capable of making insulin pump decisions and at the same time has someone else viewing/controlling their insulin pump via the AAPS client. I appreciate any insight.
I truly want to thank all the devs of this this excellent capability. I'm not strong at java, capable with python/C/x86 assembly, but certainly willing to contribute.