Skip to content

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Tandem t:Slim X2 integration? #904

Closed
whoiswes opened this issue Jun 6, 2019 · 42 comments
Closed

Tandem t:Slim X2 integration? #904

whoiswes opened this issue Jun 6, 2019 · 42 comments

Comments

@whoiswes
Copy link

whoiswes commented Jun 6, 2019

Prompted by StephenBlackWasAlreadyTaken/xDrip#260

I realize that this is probably not something that xDrip itself would implement, but figured it would be worth starting the discussion here. Feel free to redirect this if there's a better venue.

Like the reporter in the issue above, I too have a son on an X2, and have been leveraging xDrip (and Nighscout) for remote monitoring since his diagnosis. It would be fantastic to be able to connect to his pump and pull bolus/basal/Basal-IQ/Control-IQ information and sync to both xDrip followers and Nightscout/Tidepool.

I would assume that Tandem would need to provide access to the pump's API, OR develop their own Android app that would allow xDrip or NSClient to connect and retrieve data. Since neither of these things have happened yet (to my knowledge) I am assuming any progress would be hacking into the bluetooth interface.

Again, I know this is probably not the right place to discuss but this community is pretty active (and talented) so I wanted to get the discussion going.

@SindreSB
Copy link

SindreSB commented Oct 9, 2019

Currently, I am unable to find anyone working on this. The androidaps site states they have talked to a tandem exec that said there were no plans of opening up the pump to DIY community. Also, the mobile app is yet to be released. This means we can't even analyze traffic between the pump and the app. T
he best option for now would be to try to get hold of a copy of the pumps firmware and try to reverse engineer the bluetooth interface from that. Neither of these are simple options, but I think reverse engineering the firmware is the only option now. Option two is to wait for the app to be released and try to the reverse engineer the protocol from that.

@senortighto
Copy link

since the mobile app is out now, any way we can piggy back reading data from the upload, MITM to read the data being uploaded to phone with xdrip and the t:connect app, or at least pull data from the tandem t:connect site?

@smilodonis
Copy link

This interests me aswell. Tidepool and diasend have an uploader app (for PC and mac) that can get the data from x2 and upload it to their web, so I belive it is possible to do at least a Android apploader similar to 600 uploader for Medtronic pumps. Also I belive the tidepool uploader is open source.

@dan5912
Copy link

dan5912 commented Oct 30, 2020

I just got done doing a bluetooth capture of the pump -> app comms using a high end BLE sniffer and... wow this app dumps a lot of data. The app has spent 5 minutes (so far) dumping 87 byte packets every 30ms. My guess is that it is grabbing all of the stored pump data from forever and trying to upload to tslim servers. Just doing a simple refresh of the main screen transfers ~50 packets of data and, despite the data on screen being the same, the packets were not the same. Payload sizes were identical, but data was not even close beyond the first 6 bytes of a header. I'm just guessing, but they may have app layer encryption on top of the BLE encryption. Let me know if someone wants some log captures. I just don't have the bandwidth at the moment to do this sort of analysis. (edit: The data payloads I'm referring to changing are after the sniffer has done the BLE decryption to get the actual ATT notifications / Write Commands. There seems to be another layer of encryption / obfuscation on top of the normal BLE protocol layer)

@palaslet
Copy link

palaslet commented Nov 3, 2020

@dan5912 , Can you attach the logfiles here, so it's accessible to anyone who want to look into it? I might be interested to at least have a look. Pretty sure I won't be able to make any sense of it, but still...
We have to start somewhere, and even if we only can get some kind of handshaking going, that would be huge!

@dan5912
Copy link

dan5912 commented Nov 16, 2020

@palaslet I'm still working to get logs to you guys. Tandem app decided to break needing a reinstall, which requires BLE pairing again, which requires me to extract the LTK via BT error dumps to decrypt the logs... Hopefully I'll have the time to sort through this soon.

@MachFour
Copy link

MachFour commented Dec 9, 2020

Is there some private chat area where we can talk about this? I've been spending quite a bit of time recently looking both the firmware and the app, and I might have some useful info. Or even email....

@dan5912
Copy link

dan5912 commented Dec 9, 2020

Does discord work? Seems to be the current popular means (outside slack or something).
https://discord.gg/JuRWpgDYW9

@tolot27
Copy link
Collaborator

tolot27 commented Dec 9, 2020

@MachFour and @dan5912 Please create a private room at gitter and add me.

@MachFour
Copy link

MachFour commented Dec 9, 2020

@tolot27 I've created room and added both of you. @dan5912 you should have received an invitation to join Gitter

@smilodonis
Copy link

Please add me as well. Thank you

@whoiswes
Copy link
Author

whoiswes commented Dec 9, 2020

Feel free to add me as well. Not an app developer, but I've got several years of backend development experience (primarily Python) and also have a spare pump that's not being actively used.

@MachFour
Copy link

I might just keep the chat for people who are actively investigating this (and it's easier to coordinate with fewer people). We can update you here with progress.

@bwrampton
Copy link

Just wanted to check in on this and see if any progress had been made. I am definitely interested in this initiative (as a consumer, not a developer). Thanks!

@tolot27
Copy link
Collaborator

tolot27 commented Jan 16, 2021

@bwrampton There is ongoing work but not any stable code, yet. As soon as something is available for testing, it will be reported. Until then you have to be patient.

@jyaw
Copy link

jyaw commented Jan 26, 2021

Hey there! I'm interested in helping out or testing if needed. Was looking at getting my X2 data into NS and found this thread...

@MachFour
Copy link

Hey, thanks for your interest! Right now things are in really early stages and there is nothing to actually test, but I appreciate your offer to help out. As @tolot27 said, as soon as something is available for testing, you'll know :)

@bewest
Copy link
Member

bewest commented Feb 9, 2021

How is this going? I've been auditing similar cloud-native Nightscout plugins (Dexcom Share, Minimed Connect) and would like to add this to the suite.

@MachFour
Copy link

@bewest see comments above, there is nothing ready to even test out yet

@sneps85
Copy link

sneps85 commented Feb 13, 2021

@MachFour As my son has diabetes and is using a Tandem X2 with G6 and I am an iOS/Android developer, I would like to ask if I may help you somehow?

@AuroraThiel
Copy link

I don't know a thing about developing apps, but as a consumer, I really want to thank the Devs that are working on this! I found this from a Google search, wondering if there was an integration option.

@palaslet
Copy link

@AuroraThiel and @sneps85, I'm taking the chance answering on behalf of @MachFour.
As stated above they're currently working on it. From what I can understand this task is not a simple one. Medical companies need to adhere to strict regulations regarding operational security for their devices, so there's going to be at least one (probably several) layers of encryption on that bluetooth connection. This is usually the most difficult beast to tame.
We just have to wait and see what they're able to achieve. I'm quite sure they'll post an update here when there's anything exciting to report.

@sneps85
Copy link

sneps85 commented Feb 18, 2021

@palaslet Thanks for the update, but maybe you misunderstood my comment. I asked if I could help to decrypt the security layers, as I am a iOS/Android developer and do have experience with reading bluetooth devices (for example for snow producers).

@MachFour
Copy link

@sneps85 I sent you a message on Gitter to hopefully clear things up.

@jwoglom
Copy link
Contributor

jwoglom commented Mar 8, 2021

Apologies for responding to an old thread, but I wanted to share more widely a project I created which serves as a synchronization tool between the t:connect Android app and Nightscout.

It's not especially well-documented (yet), but for setup you just need to enter your tconnect credentials, pump serial number, and Nightscout details into a file named secret.py. You can then run main.py with either a start and end date, or the --auto-update flag to have it automatically upload tconnect data in to Nightscout.

If there is any interest I can write up some formal documentation. I've been using this on my own for several months now and it works great -- though if you wanted the data to appear in xDrip you need to configure it to backfill data from Nightscout, I believe.

@ChaseCarHG
Copy link

ChaseCarHG commented Mar 15, 2021

I wanted to share more widely a project I created which serves as a synchronization tool between the t:connect Android app and Nightscout.

Wow! This rocks!
It made me curious if any of NightScout's CGM-Remote-Monitor was already in Python, but it seems not per here:
https://github.com/nightscout/cgm-remote-monitor

Q1: With that, what are the chances of having this ported into NightScout?

I got my NightScout instance running from Docker on my Synology only a few days ago, and meanwhile, would love to have this as its own container, or fold it into my existing docker-compose.yml stack (run through Portainer). Then I noticed you are years ahead of me, into Kubernetes.

Q2: Do you already have this project containerized, or do you plan to containerize it soon?

Q3: If not, would you be willing to mentor me through containerizing it when I run into a roadblock?
(I am not a software engineer, but rather a nuclear engineer with a ton of programming experience.)
Edit: Good starting point? https://github.com/autoferrit/docker-supervisor/tree/master/python/3.5

@jwoglom
Copy link
Contributor

jwoglom commented Mar 16, 2021

Hi @ChaseCarHG --

  1. Personally, I think that the tconnect synchronization feature is best served as a separate tool that works together with Nightscout, rather than integrating it into the existing Nightscout source code. It doesn't depend on any of Nightscout's internals and just utilizes the public API. Also, like you mentioned, Nightscout is written in Javascript while the tconnectsync project is in Python and it doesn't seem like a good use of anyone's time to rewrite either of them in a different language.

  2. When you posted this question, I hadn't containerized it, but it's a pretty simple Python application and containerizing it is easy. I've since added a Dockerfile and instructions in the README to my repo.

@ChaseCarHG
Copy link

  1. When you posted this question, I hadn't containerized it, but it's a pretty simple Python application and containerizing it is easy. I've since added a Dockerfile and instructions in the README to my repo.

First off, you rock!

First build took overnight on a Synology, but it persevered.
My .env file is set up adjacent to the dockerfile in /volume1/docker/tconnectsync/
I am Eastern Daylight Time too.

Now, I'm so close yet so far...

MyUserName@SERVERNAME:/volume1/docker/tconnectsync$ docker run tconnectsync --auto-update
Traceback (most recent call last):
  File "/home/appuser/main.py", line 355, in <module>
    main()
  File "/home/appuser/main.py", line 314, in main
    last_event = tconnect.android.last_event_uploaded(PUMP_SERIAL_NUMBER)
  File "/home/appuser/api/__init__.py", line 40, in android
    self._android = AndroidApi(self.email, self.password)
  File "/home/appuser/api/android.py", line 31, in __init__
    self.login(email, password)
  File "/home/appuser/api/android.py", line 56, in login
    self.patientObjectId = j["user"]["patientObjectId"]
KeyError: 'patientObjectId'

@jwoglom
Copy link
Contributor

jwoglom commented Mar 16, 2021

@ChaseCarHG let's move this to a github issue thread on the tconnectsync repo to not clog up the thread. Can you re-post this at https://github.com/jwoglom/tconnectsync/issues/new?

@davidrint
Copy link

We connected my daughter up to t slim today. Interested in all options. Posting here to be kept up to date when you guys are ready. Exciting stuff.

@nickrout
Copy link

Thank you all for your efforts.

@fatbob313
Copy link

Really interested in this as well. Our 8 year old had a Medtronic 670g before where the uploader could send all treatment details to Nightscout in real-time and I really miss that, although I think the T-slim is better in almost all other aspects.

@annbob
Copy link

annbob commented Sep 11, 2021

As discussed above, @jwoglom has done a brilliant job of creating a synchronizer between the tconnect mobile app and nightscout. Found here...
https://github.com/jwoglom/tconnectsync
The instructions are pretty simple to follow, especially if you've already set up nightscout using instructions for setting up heroku.
The only downside is that you have to host the tconnectsync project on an always on computer somewhere.
I've been using the docker containerized version with "auto-update" feature turned on.
NOTE: at least in my case you have to be logged into the tconnect app in order for the app to upload data to the cloud, which is where tconnectsync receives its data from. When you are not logged in to the tconnect app data is not updated to nightscout until you are logged in to tconnect app again. Then any past data is uploaded to the cloud where tconnectsync then recognizes the new info and transfers to nightscout.

@fatbob313
Copy link

Unfortunately the T:connect app is only available in the US (as far as I know...), or is there a way around that restriction?

@davidrint
Copy link

Unfortunately the T:connect app is only available in the US (as far as I know...), or is there a way around that restriction?

I would love to know that too. I found an apk download but would rather avoid setting up in that way and i do not know if the software would check when running anyway.?

@fsvaren
Copy link

fsvaren commented Oct 11, 2021

The APK doesn't help, it is geofenced. I think it is on its way here though, but I wouldn't be surprised if they restrict use to a small subset of phones, just like the Dexcom G6 App.

@Navid200
Copy link
Collaborator

Sounds like a great idea. It will be great if it becomes possible.
I don't think we can make a change to xDrip, at least now, to enable this. So, I close this issue.

You can continue any conversations about this or any other xDrip-related ideas and concerns in the discussions:
https://github.com/Navid200/xDrip/discussions

I hope you help me reduce the number of open issues. There are xDrip bugs that don't get enough attention because there are so many open issues and feature requests.

Please don't open an issue here, on this platform, in order to get a conversation going.
If you like, you can continue to post in this thread even though it is closed. But, please don't reopen it.
Thanks for your help.

@fsvaren
Copy link

fsvaren commented Oct 29, 2021

Another way to handle "lots of open issues" is to use the project view and only move bugs and other issues that need attention to the project and set a status where the show up on the board. Just a suggestion.

@Navid200
Copy link
Collaborator

Thanks for that. I had never paid attention to projects. Unless I have misunderstood what it is, it lets us create a list of selected issues (and PRs) and organize and label them.

The underlying problem is that when a user has a problem and comes to the issues platform, the more open issues there are, the less likely it is they will see an existing issue related to their problem. Having a reasonable (small) number of open issues helps users as well as me who has been trying to coordinate the issues. Someone has to keep going through the open issues and add them to the project. So, at the end, we need to have a reasonable number of open issues.

I think the user community needs an alternative, to the issues platform, for asking questions, making suggestions, and ranting.
I am hoping that they will use my discussions platform for that. I also have been engaging users on facebook and let them rant there.

Thanks for the suggestion.

@tolot27
Copy link
Collaborator

tolot27 commented Aug 12, 2022

Work is in progress but don't ask when it will be ready!

@tolot27 tolot27 reopened this Aug 12, 2022
@Miquest
Copy link

Miquest commented Aug 12, 2022

I am very excited about the result! I am so thankful that you are putting so much effort into implementing a new feature for the community/xDrip users. I am looking forward to!

@Navid200
Copy link
Collaborator

I'm converting this to a discussion.

@Navid200 Navid200 converted this issue into discussion #3016 Aug 14, 2023

This issue was moved to a discussion.

You can continue the conversation there. Go to discussion →

Projects
None yet
Development

No branches or pull requests