Your APS, like any other piece of technology, will break sometimes. One of the things you’ve probably become well aware of as a person with diabetes is how things might fail. We people with diabetes (PWDs) are well known for having “emergency backups” for most things. Depending on your APS, you may or may not be able to have an “emergency backup”, full APS system ready to go. However, some of the broken components can often be fixed, or troubleshooted, and resolved.
If your system breaks, or you stop looping, you should think through the reasons of why you are not looping. There are three major categories of things that will prevent you from looping:
No CGM sensor data
Wonky or missing data
Communication errors between pieces of a system.
Some of these issues have more obvious fixes. If you don’t have a CGM sensor running, you won’t be able to automate your insulin delivery. It may be a matter of inserting a new sensor and waiting for the warmup period. However, there may also be issues with the quality of data that prevent you from looping. For example, if your CGM shows an error message (such as ???), your system cannot loop off of that information. In that scenario, you’ll have to decide to wait until data comes back, or decide to switch to a new CGM sensor. Additionally, if your controller cannot read your CGM data for any reason, you won’t be able to loop, even if the data and the sensor are “good”. This could be because your body is blocking transmission from your sensor and transmitter to the controller, or because the controller is out of range. It could also be caused by the Bluetooth being turned off on your controller. It may also be that the environment around you is very “noisy” and interfering with your Bluetooth connections between your devices.
It’s helpful to understand these basic scenarios so you can walk through them for troubleshooting if you are alerted, or discover, that you are no longer successfully in automated insulin delivery mode.
If you’ve chosen an APS that has the controller inside the pump, that removes one area of troubleshooting. For non-integrated systems, device troubleshooting includes assessing the connection and data transfer between your CGM and the pump/controller.
If your APS has a separate handhold controller or it’s on your phone, you’ll need to include investigating the connection between the controller/phone and the pump, as well as the controller/phone and the CGM. You may also need to charge your phone more often than you did before.
Your APS may also be working locally, but your loved ones monitoring it remotely may not be able to see that it’s working, or you may not be able to see what it’s doing on your secondary displays. In that case, you would be troubleshooting the data flow from your controller (pump, separate device, or on your phone) with your uploader device (often, your phone) for transmitting the information to the cloud. Next, you might look to ensure that your phone/uploader has internet connectivity via cellular service or a Wi-Fi connection. Depending on how you’re sharing your data remotely, there are likely other troubleshooting steps specific to your setup, but checking the flow of data from your device to the cloud often resolves many of the most common issues. Fixing these can involve killing and restarting a CGM data app, toggling the Bluetooth on your device(s) on and off or even rebooting the devices if possible.
The hardware (or physical) components are often the easiest to troubleshoot. However, real-world diabetes can sometimes cause issues, too. For example, what happens when your insulin pump site gets pulled out by a doorknob? What happens when you have been running resistant, realize your pump site is “a little bit old” and decide to change it - how does your APS know that your likely cause of resistance is gone? Additionally, how does the APS know about - and deal with - you taking additional insulin, either as an injection or via another mechanism such as inhalable insulin? What happens if you’ve bolused, and throw up due to food poisoning? And what happens when you travel, with regards to time zones and jet lag and the changing insulin demands that it causes?
You may not have all the answers, or experience all of these scenarios, when you first get started with an APS. But they certainly happen! So it’s worth discussing and exploring how your system can potentially deal with these scenarios.
How long does it take the APS to resume looping after I’ve had a compression low, an error code (such as ???) or having missing CGM data?
How common is it for the CGM reading to be blocked by the body?
How often are people in fully closed looping mode with your system?
If my pump site falls out or isn’t working well, how do I tell your system that I haven’t actually received the insulin it thinks that I have gotten?
Can I tell the system about other insulin sources, and if so, how?
What happens if I throw up after a meal bolus, and/or don’t get to eat the meal I accounted for?
When, and how, should I change the time zone on my device when I’m traveling to a different time zone? How will this affect my APS?
What should I do with my APS when I shower or swim? How does it account for, and handle, missing insulin during that time frame?
Even armed with all of this knowledge, and years of experience, you may still find yourself in need of help from time to time. You need help troubleshooting your new device, you can’t find documentation or answers to your question and the support line for your system is closed, etc. Thankfully, the diabetes community is incredibly helpful, friendly, and supportive! There are dozens (if not hundreds) of channels where you can find help and support: forums such as TuDiabetes or Beyond Type 1, Twitter, Facebook Groups, Reddit, etc.
It’s not always clear how to ask for help, though. It can be hard to do so. Having spent the last five years interacting and supporting others in the DIY diabetes community online, we’ve developed some helpful tips to help people who need to ask for help. When some of this is used to post a question online, it becomes easier - and quicker - for someone else to step up and help you work through your issue or scenario.
Start by explaining your setup. DIY example: “I’m building an Edison/Explorer Board rig for OpenAPS, and am using a Mac computer to flash my Edison.” Commercial example: “I’m using APS XYZ and am attempting to remotely monitor with Nightscout.”
Explain the problem as specifically as you can. DIY example: “I am unable to get my Edison flashed with jubilinux.” Commercial example: “I’m unable to see BG and looping data from APS XYZ in Nightscout.”
Explain what step you’re stuck on, and in which page/version of the docs. DIY example: “I am following the Mac Edison flashing instructions, and I’m stuck on step 1-4.” (And if you can, paste a URL to the exact page in the documentation or guide you’re looking at. Clarify whether your problem is “it doesn’t work” or “I don’t know what to do next.”) Commercial example: “I tried doing Step Z but it did not resolve the problem and BGs are not appearing.”
Explain what it’s telling you and what you see. Pro tip: Copy/paste the output that the computer is telling you rather than trying to summarize the error message, or share a screenshot. DIY example: “I can’t get the login prompt, it says “can’t find a PTY”. Commercial example: “I’m looping just fine on APS XYZ, but the error message in Nightscout is ABC. Here is a screenshot: (image)”
Be patient waiting for a response! There are many people who can chime in and help, but even with thousands of people with diabetes out there, they may not be on your channel of choice at that moment. Don’t worry if you don’t get a response in minutes. If after a while (say, a few hours) you haven’t seen any response, you can comment and try to “bump” your post, or check another channel to try to find help. Caution: be careful about posting the same question to multiple channels at the exact same time. It can make it hard to troubleshoot across multiple channels, and it also may convince people that your question is being answered elsewhere.
Be aware of what channel you’re in and pros/cons for what type of troubleshooting happens where.
Facebook – best for questions that don’t need an immediate fix, or are more experience related questions. Remember you’re also at the mercy of Facebook’s algorithm for showing a post to a particular group of people, even if someone’s a member of the same group. And, it’s really hard to do back-and-forth troubleshooting because of the way Facebook threads posts. However, it IS a lot easier to post a picture in Facebook.
Gitter or similar for DIY setups – best for detailed, and hard, troubleshooting scenarios and live back-and-forth conversations. It’s hard to do photos on the go from your mobile device, but it’s usually better to paste logs and error output messages as text anyway (and there are some formatting tricks you can learn to help make your pasted text more readable, too). Those who are willing to help troubleshoot will generally skim and catch up on the channel when they get back, so you might have a few hours delay and get an answer later, if you still haven’t resolved or gotten an answer to your question from the people in channel when you first post.
Email groups – best for if no one in the other channels knows the questions, or you have a general discussion starter that isn’t time-constrained
Start with the basic setup, and come back and customize later.
Make sure you walk before you run. The documentation for DIY and guides for commercial setups are designed to support the general use cases. The best practice for either DIY or commercial setups would be starting with the basic features and getting familiar before trying to further tweak and customize things. If you skip steps, it makes it a lot harder to help troubleshoot what you’re doing if you’re not exactly following the documentation that’s worked for dozens of other people.
Pay it forward.
Don’t be afraid to jump in and help answer questions of things you do know, or steps you successfully got through, even if you’re not “done” with your perfecting your APS yet. Paying it forward as you go is an awesome strategy and helps a lot!
Avoid vague descriptions of what’s going on, and using pronouns such as “it”. Troubleshooter helpers have no idea which “it” or what “thing” you’re referring to, unless you tell them. Nouns are good. Saying “I am doing a thing, and it stopped working/doesn’t work” requires someone to play the game of 20 questions to draw out the above level of detail, before they can even start to answer your question of what to do next.
Don’t get upset at people. Remember, anyone responding to your question is trying to help and donating their time and expertise. That’s time away from their families and lives. So even if you get frustrated, try to be polite. If you get upset, you’re likely to alienate potential helpers and revert into vagueness (“but it doesn’t work!”) which further hinders troubleshooting. And, remember, although these tools are awesome and make a big difference in your life – a few minutes, or a few hours, or a few days without them will be ok. We’d all prefer not to go without, which is why we try to help each other, but it’s ok if there’s a gap in use time. You have good baseline diabetes skills to fall back on during this time. If you’re feeling overwhelmed, turn off your APS, go back to doing things the way you’re comfortable, and come back and troubleshoot further when you’re no longer feeling overwhelmed.
Don’t go radio silent. Report back what you tried and if it worked. One of the benefits of these channels is many people are watching and learning alongside you, and the troubleshooters are also learning, too. Everything from “describing the steps ABC way causes confusion, but saying XYZ seems to be more clear” and even “oh wow, we found a bug, 123 no longer is ideal and we should really do 456.” Reporting back what you tried and if it resolved your issue or not is a very simple way to pay it forward and keep the community’s knowledge base growing! Also, once you’ve solved an issue, consider hitting the “edit” button and putting [SOLVED] or [RESOLVED] at the front of your post, so people know that you no longer actively are needing help on that particular issue.
Don’t wait until you’re “done” to pay it forward. You definitely have things to contribute as you go, too! If someone’s description was really helpful, consider writing that up in more detail and sharing it again with someone in the future, or add it to some of the community documentation for that particular APS system.
And, don’t hesitate to ask for help if you need it. In the Resources section, I’ll list some of the online groups such as the “CGM In The Cloud Off Topic” group on Facebook where just about any question goes! Just remember or refer back to some of the above tips and chances are you’ll be able to resolve any issues more quickly.