AndroidAPS
AndroidAPS copied to clipboard
nightscout
Discussion: Why open loop when DST ?
I'm on DASH and @jbt7rr has Medtrum. I had a 3h open loop with the summer/winter time change but he did not...
As AAPS knows IOB and COB at the moment of the change, the only thing that can change between 2AM and 3AM is the profile.
It would be good if, after the time change, AAPS sends new time to pump, then sends active profile to pump automatically. This way, we can keep closed loop for DASH too
This is a thing that would needs to be done in the pump driver. For dash I can see if I can do something however, in the coming weeks I'm tight on time.
however, in the coming weeks I'm tight on time.
No hurry, you have 6 months to finish it 🤣
As AAPS knows IOB and COB at the moment of the change,
When timeshift is backwards, think the problem is that the database values get "duplicates" in time: BG values, but also and oRef calculations on IOB and COB (database entries, decay times) become invalid.... So IMHO better stop loop for some time!
Btw: DASH pumptime is updated but needs users OK to do that. Think I would like to keep that this way?
needs users OK to do that. Think I would like to
Why validating the time by the user is important?
BG values, but also and oRef calculations on IOB and COB (database entries, decay times) become invalid....
So IMHO better stop loop for some time!
Yes, going back in time might be complicated. Need to think about how it can be solved.
At least, on time move forward, it will be easier to solve.
The Medtrum pump did not open the loop yesterday night. So, it can be done 👍
Why validating the time by the user is important?
User should know about DST change, check pump, confirm all is ok?
For DASH, this is a Pod alert status as we know (beep, refresh, ack) for other events like Pod expiration or Pod status issues Purpose of the alert is to inform user and let him/her confirm. This is why Pod alerts are not handled automatically..
Btw: Even though I got the DASH Pod alert (time on Pod) to be confirmed, DASH continued to operate even when my confirmation was 5 hours later.
User should know about DST change, check pump, confirm all is ok?
I don't know about other pumps but with DASH, what is there to check and confirm? What options do you have other than accepting the DST change ?
Ok, for informing the user about the DST change in x hours (this is already done actually) but when it is time to change, user doesn't really have any choice.
Purpose of the alert is to inform user and let him/her confirm. This is why Pod alerts are not handled automatically..
We are not talking about pod alerts. In pod alerts, user must do something (as in Ok, I heard that pod will end in 2 hours or Ok, low insulin reservoir ...)
In each alert, user must prepare an action to come (change pod).
With DST, the user has nothing to do. If user has no options to choose or to do, why bugger him/her with a useless question?
Btw: Even though I got the DASH Pod alert (time on Pod) to be confirmed, DASH continued to operate even when my confirmation was 5 hours later.
The problem is not the alert. It is the open loop for 3 hours.
AAPS can send a message telling that pump has been set to the DST change if you want. It is useless but why not.
You phone, computer, car etc don't show an alert telling you that it has set the new DST time.
The problem is not the alert. It is the open loop for 3 hours.
IMHO As all Loop calculations are time based the only sensible and safe(!) way to handle DST changes is to STOP the loop. Because of safety concerns I strongly feel we should not change this!
Only know EROS/DASH but in general I do not see DST as a problem. However I can imagine users being confused and concerned about this. They should not be?
- User should know about DST
- User may need to take appropriate actions (mostly pump specific, YMMV).
Makes no sense trying to "automate" this at this mostly depends on the type of change (DST or TZ travel) as wel as pump & user/profile specifics as described in documentation?
The problem is not the alert. It is the open loop for 3 hours.
How much of a problem is this actually? It is not for me.
AAPS switches to standard basals which should be ok in most cases. Sensor alert should protect. When in doubt: set an alarm clock for a wake-up to check?
why bugger him/her with a useless question?
I get your point and you may be are right here. Personally I do not think it is useless? Confirming means the user tells the Pod to update the time on the Pod "now".
Yes, this could be automated. But as this is not a trivial change in the Pod's operational logic it could have unknown side effects? It affects the Pod's internal default basal rates, could triggering a secondary alert (expiry) or even a Pod fault? So implementing such should not be seen lightly.
Anyway, I would prefer to be around when Pod's time is reprogrammed. I know - I'm a tech ;-) For the general user, yes this is maybe not a bad idea.