Change .nsSiteChange trigger to .replaceComponent(...) instead of .prime

[MikePlante1]

This addresses #677 by changing the trigger to upload a .nsSiteChange event to Nightscout from .prime to .replaceComponent(.infusionSet or .pump)

Before this PR, rewinding a Medtronic pump and doing a non-fixed prime to fill the tubing would upload a .nsSiteChange event to Nightscout even if the cannula was not primed with a fixed prime.

After this PR, only a fixed prime will trigger uploading a .nsSiteChange event to Nightscout, as a fixed prime is required for a cannula change with Medtronic but a non-fixed prime is not required.

Omnipod DASH and Eros will also trigger uploading a .nsSiteChange event to Nightscout when a new pod is started and primed in Trio.

This PR is marked as draft because DanaKit does not yet create .replaceComponent(.infusionSet) events, though bastiaanv/DanaKit#11 should address that.

[MikePlante1]

Medtronic 722 was rewinded and a non-fixed prime was issued at 1:34 (no fixed prime). Only IAGE was reset, not CAGE:

A fixed prime was issued to the Medtronic 722 1:48 to fill the cannula. CAGE was then reset:

NS Treatment History:

[dnzxy]

How's the status on this one?

[LiroyvH]

Just noting for record what I mentioned on Discord: I think this may be a problem for users with steel infusion sets and for users who fill their tubing when connected to the cannula (some sets allow this, some trainers explain it that way). A fixed prime will typically not be given in that situation, which will cause CAGE/IAGE to never update for these users - if I understand this PR and the earlier discussion correctly. I'd argue there might be need for a solution to this.

Rewind + normal tube filling should be sufficient and generally speaking would mean the cannula is also changed - but there will be moments where it isn't (eg: motor failure/obstruction) and someone wishes to re-use the cannula. But I think NS syncing "wrong" info in that situation will happen far less frequently and is less of an issue than TruSteel never syncing to NS again. But I'm not sure what a solution to this "can't win" situation is. (Other than maintaining status quo and keep it as it has functioned for... a long time. :P) -edit- actually, making the behaviour user configurable may be the simple solution. Or ask which infusion set and guess.

(I'm quite confused by the wording of the 3rd paragraph btw but that might be a "me problem" :P)

[MikePlante1]

Just noting for record what I mentioned on Discord: I think this may be a problem for users with steel infusion sets and for users who fill their tubing when connected to the cannula (some sets allow this, some trainers explain it that way). A fixed prime will typically not be given in that situation, which will cause CAGE/IAGE to never update for these users - if I understand this PR and the earlier discussion correctly. I'd argue there might be need for a solution to this.

Rewind + normal tube filling should be sufficient and generally speaking would mean the cannula is also changed - but there will be moments where it isn't (eg: motor failure/obstruction) and someone wishes to re-use the cannula. But I think NS syncing "wrong" info in that situation will happen far less frequently and is less of an issue than TruSteel never syncing to NS again. But I'm not sure what a solution to this "can't win" situation is. (Other than maintaining status quo and keep it as it has functioned for... a long time. :P) -edit- actually, making the behaviour user configurable may be the simple solution. Or ask which infusion set and guess.

(I'm quite confused by the wording of the 3rd paragraph btw but that might be a "me problem" :P)

Without this PR, IAGE and CAGE both get reset in NS for every "Rewind + normal tube filling", plus CAGE also gets reset for any fixed prime. That means even when you don't actually change your cannula, any time you refill your reservoir your CAGE also gets reset.

With this PR, "Rewind + normal tube filling" will still reset IAGE, it just won't reset CAGE in NS like it used to. With this PR, CAGE is only reset in NS with a fixed prime. So for steel cannula users who skip the fixed primes, they can still keep track of their cannula's age by just looking at IAGE or they can do a fixed prime before inserting, but it will no longer mess up tracking cannula age for users who can now rely on CAGE unlike before this PR.

[LiroyvH]

Thanks @MikePlante1 for explaining the reasoning. Got to ask tho:

but it will no longer mess up tracking cannula age for users who can now rely on CAGE unlike before this PR.

Ok, but the flipside is that's then at the costs of CAGE no longer working for people whom only do normal tube filling, which is most steel users and all teflon users who do the tube filling with the cannula attached. (Some get trained that way, but there's unfortunately no data on how many do it this way) I suspect that's quite a large amount of users.

Which does beg the question:

That means even when you don't actually change your cannula, any time you refill your reservoir your CAGE also gets reset.

How often does it happen that people change their reservoir but not their cannula compared to how many steel users + teflon users are filling with the cannula attached (much like steel) and don't do a fixed prime? (I mean I did that sometimes, but I used 300U in 1.5 days at the time and there's only so much the reservoir can hold. :P)

So: are you sure that the end-result of this PR isn't making the status quo so that more people now end up having an unreliable CAGE value as compared to before this PR?

[MikePlante1]

Why have an IAGE and a CAGE if you can't reset IAGE without resetting CAGE?? IAGE serves no purpose then.

MinimedKit was originally designed for Loop. This is how it works for Loop. The names *(of .replaceComponent(.infusionSet / .reservoir / .pump) alone make it pretty obvious. It just must not have been ported over properly into FreeAPS X, and by then the majority of users were probably using Pods, so it just never got fixed.

This is a minor setback for those who've gotten used to how FAX implemented it and always skip their fixed primes. But it is a huge improvement for anyone who uses teflon cannulas and doesn't always change their site every single time they rewind their pump.

It would be nice to have MinimedKit updated to add a setting to choose wether a rewind or fixed prime or nothing resets CAGE, and it would be nice to have it updated to actually display CAGE and IAGE in the submodule in Loop/Trio, and it would be nice to have it updated so you could manual reset or undo the last reset of CAGE and IAGE from the submodule in Loop/Trio. But imo, none of those are blockers for this PR.

[MikePlante1]

I've never used OpenAPS, but it looks like it does not reset CAGE or IAGE automatically at all, and users had to manually log it via CarePortal in Nightscout.

I've also never used AndroidAPS, but it looks like users can send the fixed prime from the AAPS app and click to reset CAGE at the same time. Not terrible, but not much better than just being forced to open Nightscout and manually enter it like OpenAPS.

[MikePlante1]

The force push was just rebasing to current dev, as this PR was just one real commit followed by 10 commits merging dev in. No change in code.

I also gave this a test with an rPi DASH simulator. For some reason it's now sending two Pump Site Change events to Nightscout, which is fine because it still resets CAGE – but I'll try to figure out how to stop it from sending it twice.

The "SiteChange" event in History in Trio is newly introduced with this PR, otherwise History looks the same is it does when changing a pod in the latest 0.6.0.7 dev.

I also discovered Trio doesn't reset IAGE with a pod change (looks like it never has). I suppose that doesn't matter, though, because IAGE would always be a duplicate of CAGE when using Pods anyway.

[MikePlante1]

Okay, I found and deleted the code adding the duplicate Pump Site Change event.

I don't have a Dana pump to test with, but assuming that test passes then I think this is ready for merging.

@bastiaanv @marionbarker

[LiroyvH]

Why have an IAGE and a CAGE if you can't reset IAGE without resetting CAGE?? IAGE serves no purpose then.

That's a fair question, and I'm not really sure. But in most circumstances they'll get reset simultaneously. For the sensitive people, cannula might even be replaced more often than the insulin reservoir. (Folks using the same insulin reservoir for 6 days whilst replacing cannula every 3). Which would also mean the question can be reserved: why can't I reset CAGE without resetting IAGE?

This is a minor setback for those who've gotten used to how FAX implemented it and always skip their fixed primes. But it is a huge improvement for anyone who uses teflon cannulas and doesn't always change their site every single time they rewind their pump.

Yes, I'm not debating that. Just pointing out that whilst its a huge improvement for the group you describe, its a huge disadvantage for anyone who uses teflon OR steel cannulas and don't do a fixed prime. And I have my suspicions that the group that's being disadvantaged by this might just be larger than the group who stands to gain something from the change in this logic especially as it addresses an edge case of changing reservoir before site.

Most steel users don't fixed prime and a part of the teflon users won't do a fixed prime either. I wonder if the problem you're solving is actually a problem to most users, or just a very select couple who change reservoirs far more often than their cannula's - and routinely at that, not just once in a while because they got a "Motor Problem"-error for example and decide to just trash the whole reservoir. (I imagine this usecase of changing reservoir more often than cannula will likely typically be limited to people like me whom used in excess of 300U per 36 hours, and from what I've always been told: that's a very small group on whom the project cannot base decisions in a larger picture.)

Were there many complaints about this issue?

It would be nice to have MinimedKit updated to add a setting to choose wether a rewind or fixed prime or nothing resets CAGE, and it would be nice to have it updated to actually display CAGE and IAGE in the submodule in Loop/Trio, and it would be nice to have it updated so you could manual reset or undo the last reset of CAGE and IAGE from the submodule in Loop/Trio. But imo, none of those are blockers for this PR.

That would certainly be very nice. Or a button in the Nightscout settings or something that allows you to manually reset IAGE and/or CAGE. Though being able to set the condition where it does this automatically would be superior for sure. Though Medtronic users are a dying breed, I wonder how this is for Dana. In which case it might be interesting to streamline it and put in the effort anyway for both these *Kits.

I also agree that's not a blocker for this PR. I'm just saying I really wonder if you're not - in the grand scheme of Trio's userbase - highly overestimating the amount of users who will benefit from this and underestimating the amount of users whom will be disadvantaged by this change. In theory, textbook teflon users

Anyway, we can agree to disagree on this matter if you like - just trying to pinpoint how this issue came in to existence and why, after all these years, it must be changed and whether or not you're absolutely sure it needs to change and won't cause more problems than it solves.

Additionally:

I also gave this a test with an rPi DASH simulator. For some reason it's now sending two Pump Site Change events to Nightscout, which is fine because it still resets CAGE – but I'll try to figure out how to stop it from sending it twice

I'm pretty sure its been sending double events for CAGE on Medtronic as well. You can see this when you use something like Nightscout Reporter. Your count of changed cannula's will be exactly double that of the reservoir changes. (At least, it was in my reports.) Pretty sure I've raised that issue a while ago, but apparently not on GitHub lol.

I also discovered Trio doesn't reset IAGE with a pod change (looks like it never has). I suppose that doesn't matter, though, because IAGE would always be a duplicate of CAGE when using Pods anyway.

And for MedtrumKit, it doesn't reset either by the looks of it. ;) I'd argue it should reset both for both Eros/Dash/Medtrum. That these pumps are a reservoir and cannula in one device doesn't alter the fact that you're still changing both of them.

[MikePlante1]

Why have an IAGE and a CAGE if you can't reset IAGE without resetting CAGE?? IAGE serves no purpose then.

That's a fair question, and I'm not really sure. But in most circumstances they'll get reset simultaneously. For the sensitive people, cannula might even be replaced more often than the insulin reservoir. (Folks using the same insulin reservoir for 6 days whilst replacing cannula every 3). Which would also mean the question can be reserved: why can't I reset CAGE without resetting IAGE?

You can reset CAGE without resetting IAGE in current dev and in this PR: Just issue a fixed prime from the pump.

This is a minor setback for those who've gotten used to how FAX implemented it and always skip their fixed primes. But it is a huge improvement for anyone who uses teflon cannulas and doesn't always change their site every single time they rewind their pump.

Yes, I'm not debating that. Just pointing out that whilst its a huge improvement for the group you describe, its a huge disadvantage for anyone who uses teflon OR steel cannulas and don't do a fixed prime. And I have my suspicions that the group that's being disadvantaged by this might just be larger than the group who stands to gain something from the change in this logic especially as it addresses an edge case of changing reservoir before site.

Most steel users don't fixed prime and a part of the teflon users won't do a fixed prime either. I wonder if the problem you're solving is actually a problem to most users, or just a very select couple who change reservoirs far more often than their cannula's - and routinely at that, not just once in a while because they got a "Motor Problem"-error for example and decide to just trash the whole reservoir. (I imagine this usecase of changing reservoir more often than cannula will likely typically be limited to people like me whom used in excess of 300U per 36 hours, and from what I've always been told: that's a very small group on whom the project cannot base decisions in a larger picture.)

Were there many complaints about this issue?

I still don't see the huge disadvantage there. Just enter a fixed prime before you insert your cannula, or ignore CAGE and just look at IAGE, or trigger a CAGE reset via Nightscout Care Portal (could even make a shortcut for that)

Even before switching to the 7-day extended infusion sets, I often changed reservoir and cannula at different times. If a site goes bad, there's no need to change reservoir — just change the cannula. And I don't like wasting insulin and I don't like trying to estimate exactly how much I'm going to use for the lifespan of the cannula.

And I don't have any data to back it up, but I'd guess there are a lot more teflon cannula users than steel cannula users.

a part of the teflon users won't do a fixed prime either

Why would a teflon user skip a fixed prime for a new cannula?

Anyway, we can agree to disagree on this matter if you like - just trying to pinpoint how this issue came in to existence and why, after all these years, it must be changed and whether or not you're absolutely sure it needs to change and won't cause more problems than it solves.

It just wasn't properly ported from Loop in the first place. Most users had probably already switched to Omnipod by the time this was added (seems to be from Pierre's fork between when FAX ended and iAPS started)

Edit to add: And like many things, this is something that has annoyed me about Medtronic in Trio/iAPS for a while — I'm just now getting around to fixing it. Other annoyances I haven't gotten around to addressing include not being able to set a manual temp basal from the app, not being able to see CAGE/IAGE in the app, BAGE not getting reset automatically, and TDD from pump not matching TDD in the app.

I also gave this a test with an rPi DASH simulator. For some reason it's now sending two Pump Site Change events to Nightscout, which is fine because it still resets CAGE – but I'll try to figure out how to stop it from sending it twice

I'm pretty sure its been sending double events for CAGE on Medtronic as well. You can see this when you use something like Nightscout Reporter. Your count of changed cannula's will be exactly double that of the reservoir changes. (At least, it was in my reports.) Pretty sure I've raised that issue a while ago, but apparently not on GitHub lol.

It does in dev, because CAGE is getting reset by both the fixed prime for the cannula and the non-fixed prime for the tubing. This PR fixes that, because it longer resets CAGE from the non-fixed prime for the tubing.

I also discovered Trio doesn't reset IAGE with a pod change (looks like it never has). I suppose that doesn't matter, though, because IAGE would always be a duplicate of CAGE when using Pods anyway.

And for MedtrumKit, it doesn't reset either by the looks of it. ;) I'd argue it should reset both for both Eros/Dash/Medtrum. That these pumps are a reservoir and cannula in one device doesn't alter the fact that you're still changing both of them.

I agree, but I'd rather save that for a new PR. Looks like Loop doesn't seem to reset IAGE for Pods either, so I might look into adding it there too.

[oddst]

I agree, but I'd rather save that for a new PR. Looks like Loop doesn't seem to reset IAGE for Pods either, so I might look into adding it there too.

This is a minor edge question/comment, but I don't know of anyone knowingly using IAGE with Omnipods (if that is what was meant with Pods)? Because it never provides any information when using Omnipods, the info pill is just empty (compared to BAGE that displays "n/a").

The Omnipod users always change cannula and reservoir at the same time. If someone is doing something else, then that would be an extremely small edge case - and supporting that would probably be more confusing then helpful for most.

Users of Omnipods have known over the years that IAGE and BAGE is meaningless in their context, and CAGE do handle everything they need. For knowledgable Omnipod users, both IAGE and BAGE is removed from both ENABLE and SHOW_PLUGINS due to now being relevant or needed.

It is however rather normal that less experienced users have their Nightscout display set up sub-optimally, by including info pills like IAGE and BAGE that never provide any useful information (for them) - but rather just takes up display real estate space and are distracting or confusing.

Having IAGE show the exact same info as CAGE, seems a bit of waste of development time in my opinion with regard to Omnipod users - or maybe I am just completely missing the point...?

[MikePlante1]

Having IAGE show the exact same info as CAGE, seems a bit of waste of development time in my opinion with regard to Omnipod users - or maybe I am just completely missing the point...?

I can't argue with that. The only edge case I can see where it might be useful is for someone who regularly switches between Medtronic and Omnipod, but even then not really that useful.