Clarification on OpenAPS offline integration

[inventor96]

I'm looking for some clarification on this documentation: https://openaps.readthedocs.io/en/latest/docs/Customize-Iterate/offline-looping-and-monitoring.html

I have a Dexcom G7, so my only options for offline looping requires xDrip+ with a WiFi hotspot or BT tethering. It seems to indicate that xDrip+ needs to have a web server running, but it also needs to be configured to push to xDripAPS on the rig. Could someone explain why both are needed? Regarding the web server approach, I'm not seeing any documentation on getting xDripAPS configured to access that server?

[PhilTU]

My reading of "The second method involves installing an application called xDripAPS onto your rig. " is that xDripAPS is an alternative (second) method to the first (web server), but I don't claim to have any actual knowledge.

[inventor96]

Ha, yep. I was looking for something about "second", but missed that paragraph. Thanks for pointing it out. I would guess your reading of that is correct.

[tynbendad]

fwiw my problem with this method of providing cgm data to the openaps rig is tethering (specifically bluetooth but probably also wifi) will shut itself off on most phones, and with recent android versions there is no good workaround, at least from what i've seen (on older android there is an app you can use to keep turning it back on).

you can read the g5 or g6 directly from the rig with xdrip-js, but there is no work ongoing that i know of to add g7 to that. if anyone has clues on how to add that support i would be interested in taking it on.

[inventor96]

Yeah, 100% agree. Unfortunately I think this is the best we've got. (Future me coming back to the top... Apologies for the novel, but I had a number of helpful (hopefully) ideas as I was writing a response, and figured I'd get them all out for brainstorming purposes)

Previously, I used Tasker to automatically enable BT tethering when my loop rig would connect via Bluetooth. But as you pointed out, that's not a thing on newer OS versions. I don't recall what OS version, but the underlying API for that feature was actually removed, hence why that app, Tasker, and any equivalents no longer work. It was an undocumented API in the first place, so I suppose we could have seen it coming in that sense.

I was using a Google Pixel 2 XL, and recently upgraded to a Pixel 8 Pro, and in both cases, the enabling of the BT tethering seems to last until reboot (though my upgrade to the P8P is recent enough and without thorough testing that I may have missed something and this observation could be inaccurate for this phone). Although definitely an inconvenience, remembering to enable it on reboot isn't super terrible. It's definitely better than ignoring it and dealing with the obnoxious (but useful) Pushover alerts. 🤣

I haven't tested it, but I think Tasker might have the ability to toggle the WiFi hotspot. If this is the case, a condition could be created to automatically enable it whenever the phone is not near one of the networks the user's rig is configured for. The rig could then connect to the WiFi hotspot instead. Still not a great solution due to the increased power consumption on the phone, but still some potential there.

If this is not available in Tasker and one was still wanting to make this work, the AutoInput Tasker plugin could be used with the same condition to mimic the user's actions of accessing and enabling tethering. This could apply to either/both BT and WiFi tethering. Still not great because it requires the user to unlock their phone first, and it also interrupts them using their phone, but still better than nothing.

---- separate, but related issue ----

At any rate, I prefer xDrip+ pushing to my rig over the rig pulling from xDrip+, since my phone is "exposed" to more (and public) networks than my rig is. Should I choose to do so, there's also the potential of configuring iptables on the rig to firewall off itself for extra network security. So my issue becomes that my rig has a potentially-changing IP address while on tethering (BT or WiFi) because I can't make static DHCP assignments on my phone, and xDrip+ has to be updated when the rig's tethering IP changes. However, this was overcome by editing /etc/dhcpcd.conf on the rig (mine is an RPi 0W) to set a static IP for the bnep0 interface. I now get the same IP on tethering every time, and since I don't do BT tethering for any other device with my phone, I don't have to worry about DHCP on my phone creating an IP conflict.

At least for my phone (a Google Pixel 8 Pro), I have noticed a side effect in the rig's connection settings on my phone: the option for enabling internet sharing doesn't show up. This is a separate option from the general toggle for BT tethering on the phone level. I have yet to reboot my phone since making this change on the rig, so I have no idea if this will work in the long-term (e.g. if that setting also needs re-enabled after reboot). Some potential workarounds for this (I haven't even tried starting any of these) are:

1. Configure the rig to listen on the broadcast IP of the tethering network and configure xDrip+ to send to the broadcast IP.
2. Configure dhcpcd on the rig to request a DHCP address from the phone in addition to listing on a static IP on the same interface. The DHCP address would cause the necessary option to display on the phone's settings for the device, and the static IP would be used by xDrip+.
3. Use a rather complex setup with Tasker (now having an HTTP server as a feature) where the rig could issue curl requests to the tethering gateway IP (thankfully, at least for my phone, the gateway uses the networking standard for this) where Tasker could be listening, which would identify the tethering IP of the rig to Tasker. xDrip+ would be configured to push to Tasker, and Tasker would forward the requests to the rig using the last known tethering IP.

Overall, I think getting xdrip-js to support the G7 would be best, but I can only imagine how much effort that would take. If I had more time (lol), I'd be willing to see what was done with xDrip+ to add support and port it to xdrip-js, but such is life.

[tynbendad]

thanks for all the info, i'm keeping track of this in case we have to switch to g7 at some point, although i'd much prefer the xdrip-js option also, and i have some time, but i haven't looked into finding the xdrip+ changes yet, i'll probably open a new discussion when i'm ready to work on that.

[inventor96]

After a month of usage and few reboots between my phone and loop rig, my setup is still working as described. After rebooting my phone, I still have to open the hotspot settings and enable the option to share Internet with Bluetooth devices. The device entry for the loop rig still doesn't display the option for sharing Internet with that specific device, and my rig still has the static IP set for itself. Anytime the rig doesn't have WiFi, BT tethering still works.

[inventor96]

I was updating some documentation, and realized I never described the changes I made to /etc/dhcpcd.conf. So for those interested who come to this thread, here's the high-level process.

1. Connect your rig to your phone.
2. Obtain the IP address, bitmask, and default gateway on the rig.
3. Open /etc/dhcpcd.conf for editing as root, then go to the bottom and add a couple blank lines followed by this block:

   interface bnep0
   static ip_address=<IP>/<BITMASK>
   static routers=<GATEWAY>
   static domain_name_servers=8.8.8.8 8.8.4.4
   

This can also apply to doing it on a WiFi hotspot; just change bnep0 to wlan0. The DNS servers at the bottom can also be changed; it's just a list of DNS server IP addresses, separated by spaces.

[Navid200]

What is the advantage of Open APS over AAPS?
As far as I know, you can run xDrip and AAPS on the same phone and there is no requirement for access to the internet for that loop to run.

[inventor96]

This might be a better to ask in a new topic, but I'll share my two cents.

At the time I was getting started with looping, I opted for a Medtronic pump and OAPS because (previous to the release of the Dexcom G7) it was possible for the rig to be entirely self-contained; it didn't need internet for anything except alerts and better visuals for monitoring. I appreciated the independence for my use case. Obviously the G7 has temporarily messed this up until someone takes the time to get xdripjs/lookout/logger compatible with it, but I haven't felt like purchasing a Riley/Orange Link and switching.

If I could get my phone to communicate with my pump directly, then I would be way more interested in AAPS for the benefit of loosing an extra device from my belt.

[Navid200]

This thread talks about something that is missing in the official xDrip, and your suggested solution for it.
It is very important to know if all options have been considered.
If yes, and if there is still a need for a tedious workaround, we can talk about improving xDrip to help.
So, I think this is the best place to talk about this.

[inventor96]

Gotcha. I didn't get that from your initial message. Thanks for clarifying.

My initial post was just asking for some clarification about the documentation around the use of xDrip+ (not necessarily issues with the app itself). I've since submitted a PR to reflect the clarification: openaps/docs#1595.

The issues and solutions in the thread started by @tynbendad all revolve around how the phone works with a loop rig connected to it, and I don't think that we could fix any of them from xDrip+... The only thing I could think of is if we added a network discovery feature to it in order to find the loop rig, but I don't know if that really fits into the scope of that app.

[tynbendad]

if someone could point me to all the xdrip+ G7 code changes (those critical to talking to the tx, beyond G6) i might have time to make xdrip-js changes some time (probably later this fall.)