If the pump has a maximum basal rate that is lower than what is configured in the app, the loop will silently fail. Loop should probably query the pump's max basal rate and use that if it's lower than what the user configured (and maybe warn).

to duplicate in v0.10, go to Health, switch to mmol in BG.
Restart the app. Go into target BG range and delete your values that were previously set in mg/dl.
Leave and go back in. It will now ask to enter as mmol.
Enter values. See target range in screenshot below

@channemann and @eyim are having intermittent issues with glucose updating from Share.

Asking them to debug invocations of private func backfillGlucoseFromShareIfNeeded(). If the issue isn't immediately reproducible, additional remote logging calls can be added.

Discussed with @ps2 , so I thought it would be prudent to log an enhancement request 'formally' as well. :)

Would it be possible to pull CGM data from Nightscout as a source of data for the loop app?

In Canada (and in many other countries) the Dexcom G4 w/share, or Dexcom G5, is not available. I'm currently using an xDrip with an android phone (and the xDrip+ app) to push data to Nightscout. (For use in an openAPS rig at the moment.)

I recognize that this means the user has to carry two phones - but I'm doing this anyway for xDrip, as I'm sure others are too.

(Longer-term it would be ideal to be able to replicate the xDrip function in iOS, but I think that's a different enhancement request.)

https://github.com/amplitude/Amplitude-iOS/blob/master/CHANGELOG.md#384-august-18-2016

Add the Current Glucose Reading Value and Trend Direction to the Loop open/closed Graphic. I know it's on the watch app but it would be great to have it at the top of the main app as well.

Since the majority of users aren't running Carthage to check the repositories out

@ps2 I think I can meet you in the middle here.

Enhancement Request:

Would it be possible to add a Bolus Wizard, where the user is prompted to input carbs and fibre, and a recommendation is made on Bolus amount based on...

• current I:C ratio
• current basal rate
• current IOB

Long-term would be ideal to link to an online food database, or provide the user with opportunity to add 'favourite' meals.

When a user enters carbs and delivers a bolus, a high temp immediately shows up as recommended. I believe this is because the meal is immediately taken into account by the Loop calculations, while the bolus is not, because the Loop relies solely on actual pump data to calculate IOB (as it should). This would not normally be an issue, as the Loop would become aware of the bolus delivered on the next pump readout. However, the high temp recommendation could become problematic if the user accepted the recommended high temp and if the Loop, for whatever reason, failed to communicate with the pump just after that. The user could be left with the bolus and the high temp for 30 min (effectively a double bolus) - a potentially hazardous situation.

It is known that there is give or take 10 units after the reservoir reports 0 units left. But loop looks like it assumes no delivery while insulin is being delivered and increases the dose. I think the safest bet is to either listen for the no delivery alert or to assume delivery and disable looping until the reservoir is changed.

I just noticed while dropping 0.7units/5min(around 7mmol/L at the time), no carb on board, at was dosing 3.4u/hr when I normally take 1.2u/hr at that time.

Almost looks like a feedback loop.

Was able to pull some CGM data from Dexcom Share. As a Canadian user I am displaying data in mmol; however, data is only being displayed in mg/DL in loop.

Could this be a configurable item for the CGM data graph?

Xcode Version 7.3 (7D175)
Recreate: download direct from Loop/Master and build

Error in StatusChartManager.swift
Lines 267,346,414,482

I've seen similar errors pop up in other projects with the newest version of swift.

Document how to troubleshoot provisioning profile issues from the perspective of someone without a paid developer account. The Member Center is not available to those users, and profiles are automatically created by Xcode.

Here's what I've observed so far:

• The initial profile (created by running "Fix Issue") has an expiration date of 7 days
• The "next" profile (unsure how/when this can be forced) has an expiration date of 90 days

One of the harder to track-down issues is with Entitlements not being included when renewing a profile until the user navigates to the target's capabilities tab and flips the feature off-then-on-again. The only Entitlement-backed capability currently used by Loop is HealthKit.

I've been getting this occasionally: UnknownResponse(nil, "Sent <a7574973 5d00>")...I don't believe the numbers after Sent are the same. Any way to troubleshoot this? It seems to be happening when loop is trying to send a new temp basal to my pump (running this with a 522).

This won't work offline, but adds some flexibility of use.

if transmitter == nil {
    // Enable timer ticks
    if !pumpModel.larger {
        // listen and respond to RL timer ticks
    }
}

Color needs some re-thinking. Most urgently, green can't represent both "insulin" and "good/fresh".
In addition, indicators like battery and reservoir don't need to take visual precedence when they're "in the green" anyway. They should move to the background when all is well, using a grey tone that still indicates level.

Where green/yellow/red is used, there should be another distinguishing glyph to assist those with colorblindness. A red circle with an exclamation point would better indicate a stale loop.

If I switch the unit to mg/dl in Apple Health from mmol/L the target glucose values or the insulin sensitivity values. One cannot delete them and read them either.

Tried reseting app and it doesn't convert or allow the entry of new unit types.

Loop is giving me UnknownEventType(20) when doing Fetch Recent History. Before I changed basal patterns it was parsing ok.

2016-06-14 22:45:59.640 Loop[13877:5575435] Writing command to data characteristic: 04000000a96d23c5ac63566555c65000
2016-06-14 22:45:59.767 Loop[13877:5572121] didUpdateValueForCharacteristic: <CBCharacteristic: 0x12d6778f0, UUID = 6E6C7910-B89E-43A5-A0FE-50C5E2B81F4A, properties = 0x12, value = <36>, notifying = YES>
2016-06-14 22:45:59.768 Loop[13877:5572121] Updated response count: 54
2016-06-14 22:45:59.820 Loop[13877:5572121] didUpdateValueForCharacteristic: <CBCharacteristic: 0x12d7256d0, UUID = C842E849-5028-42E2-867C-016ADADA9155, properties = 0xA, value = <00>, notifying = NO>
2016-06-14 22:45:59.820 Loop[13877:5572121] Response to command: 
2016-06-14 22:45:59.821 Loop[13877:5575435] Fetched page 0: <6d2f0505 0c00e800 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000c00 e8000000 07000000 0030056d 3005050c 00e80000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 000c00e8 00000007 00000000 31056d31 05050c00 e8000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 0c00e800 00001402 0fa80012 05010505 0019a840 1205010a 0a0020a9 40520500 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00002cf1>
2016-06-14 22:45:59.834 Loop[13877:5575435] Finished running dispatched RL comms task
2016-06-14 22:45:59.835 Loop[13877:5572121] idleDetectDispatchGroup empty

[
  {
    "programmed": 1.0,
    "_type": "Bolus",
    "type": "normal",
    "_description": "Bolus 2005-02-18T00:41:32 head[4], body[0] op[0x01]",
    "duration": 0,
    "timestamp": "2005-02-18T00:41:32",
    "_body": "",
    "_head": "010a0a00",
    "amount": 1.0,
    "_date": "20a9405205"
  },
  {
    "programmed": 0.5,
    "_type": "Bolus",
    "type": "normal",
    "_description": "Bolus 2005-02-18T00:40:25 head[4], body[0] op[0x01]",
    "duration": 0,
    "timestamp": "2005-02-18T00:40:25",
    "_body": "",
    "_head": "01050500",
    "amount": 0.5,
    "_date": "19a8401205"
  },
  {
    "_type": "SelectBasalProfile",
    "_description": "SelectBasalProfile 2005-02-18T00:40:15 head[2], body[0] op[0x14]",
    "timestamp": "2005-02-18T00:40:15",
    "_body": "",
    "_head": "1402",
    "_date": "0fa8001205"
  },
  {
    "_type": "Model522ResultTotals",
    "_description": "Model522ResultTotals 2005-02-18T00:00:00 head[1], body[41] op[0x6d]",
    "timestamp": "2005-02-18T00:00:00",
    "_body": "050c00e8000000000000000000000000000000000000000000000000000000000000000c00e8000000",
    "_head": "6d",
    "_date": "3105"
  },
  {
    "_type": "ResultDailyTotal",
    "_description": "ResultDailyTotal 2005-02-18T00:00:00 head[5], body[0] op[0x07]",
    "timestamp": "2005-02-18T00:00:00",
    "_body": "",
    "valid_date": "2005-02-17",
    "_head": "0700000000",
    "_date": "3105"
  },
  {
    "_type": "Model522ResultTotals",
    "_description": "Model522ResultTotals 2005-02-17T00:00:00 head[1], body[41] op[0x6d]",
    "timestamp": "2005-02-17T00:00:00",
    "_body": "050c00e8000000000000000000000000000000000000000000000000000000000000000c00e8000000",
    "_head": "6d",
    "_date": "3005"
  },
  {
    "_type": "ResultDailyTotal",
    "_description": "ResultDailyTotal 2005-02-17T00:00:00 head[5], body[0] op[0x07]",
    "timestamp": "2005-02-17T00:00:00",
    "_body": "",
    "valid_date": "2005-02-16",
    "_head": "0700000000",
    "_date": "3005"
  },
  {
    "_type": "Model522ResultTotals",
    "_description": "Model522ResultTotals 2005-02-16T00:00:00 head[1], body[41] op[0x6d]",
    "timestamp": "2005-02-16T00:00:00",
    "_body": "050c00e8000000000000000000000000000000000000000000000000000000000000000c00e8000000",
    "_head": "6d",
    "_date": "2f05"
  },
  {
    "_type": "ResultDailyTotal",
    "_description": "ResultDailyTotal 2005-02-16T00:00:00 head[5], body[0] op[0x07]",
    "timestamp": "2005-02-16T00:00:00",
    "_body": "",
    "valid_date": "2005-02-15",
    "_head": "0700000000",
    "_date": "2f05"
  },
  {
    "_type": "Model522ResultTotals",
    "_description": "Model522ResultTotals 2005-02-15T00:00:00 head[1], body[41] op[0x6d]",
    "timestamp": "2005-02-15T00:00:00",
    "_body": "050c00e8000000000000000000000000000000000000000000000000000000000000000c00e8000000",
    "_head": "6d",
    "_date": "2e05"
  },
  {
    "_type": "ResultDailyTotal",
    "_description": "ResultDailyTotal 2005-02-15T00:00:00 head[5], body[0] op[0x07]",
    "timestamp": "2005-02-15T00:00:00",
    "_body": "",
    "valid_date": "2005-02-14",
    "_head": "0700000000",
    "_date": "2e05"
  }
]

"Last sensor" is confusing - suggesting re-naming to "Last Sensor Reading" or something more descriptive.

It appears that the time displayed for total insulin (normally for the day since approximately midnight) had a bug.

How should the device identifier be constructed for Nightscout?

cc @ps2

Not a bug but more like enhancement I am going to add to code to send push notification and test on our side. On a separate note I noticed that in some cases we get the unsuccessful bolus notification but checking the pump showing bolus went through.

Looking for the ability to use a MM CGM with an x22 pump via loop.

Allow different DIAs throughout the day as a function of time (e.g. 12 m - 8 am DIA = 5; 8 am - 10 pm DIA = 4; 10 pm - 11:59:59 pm DIA = 5).

The share client does make trend values available (encoded as an int, so some transformation is necessary) in the ShareGlucose struct.

DataManager should keep track of the most recent value, to be usable by the GlucoseHUD to display trend.

I think this stopped working with the 0.10.1 update.... two screenshots from two different nights show the same issue. @CrushingT1D is seeing similar, and suspects it's a reset bug (every 5 minutes with each new MySentry vs daily) combined with a decimal place bug.

Would like to test on 723 v2.4a with enlight and connect and enlight/RileyLink pairs

Tried to bolus through the app. It says it failed. Then tried it again and it went through. The bolus insulin on board correctly shows the right amount but it never showed up in the Nightscout upload.

The problem is that the projected bg levels don't show the impact of that bolus even though it shows 10+ units of insulin on board. His bg projection goes right up to 700.

Affects 0.11.0

With the current timing of RL heartbeats and Share polling, the Loop app sits with a new Recommended Basal for 4 minutes before enacting it. It should instead do an enact immediately after generating the recommendation.

I have maximum bolus in Loop set to 1U (and 6U on the pump itself) and was just able to do a 1.5U bolus from Loop.

And properly store sensitive strings in the Keychain.

Taking cues from an early modification by @CrushingT1D, putting the last glucose value into a HUD element (I think I prefer second-from-leading).

Compactly this can describe the last glucose value, the trend arrow, the calibration state and the time, enabling the further removal of the text-based rows at the bottom that cause so much anxiety.

Currently, a single tap on the status screen's glucose chart opens the Dexcom G5 app. If the user is instead using a G4, is would to preferable to open the G4 app (Share 2).

Disabling the closed loop (toggling the button off) still yields "loop not working" notifications. Notifications also still occur even if the Rileylink is toggled off.

The use of 'nightscoutdb' is a little confusing in MLabService.swift (LN:24).
I am not sure what to put in here and it may confused people that it is related to nightscout.

I've attempted to use my mLabAPIPath from the old RemoteSettings (without the leading database/) but I continue to get a ConnectionError

If the user makes an error entering carbs, or doesn't finish their meal, they need to be able to delete their last carb entry so the loop stops high-temping for them.

Any thoughts as to why my battery status might not be filling in? Running on a 722, changed the battery when I started with Loop last night

Due to bluetooth dropping between the phone and the Dexcom receiver, as well as other connectivity issues, the most recent glucose data isn't always uploaded to the Share servers when Loop goes to retrieve it. While this cannot be solved for the present loop cycle, the failed retrieval has impacts on the follow-on cycles as well, specifically regarding prediction calculations. A method for backfilling missing data from the Share servers would fix this.

How many data points to backfill is an open question, but probably at least the last 15 minutes.

Different basal profiles so that one can switch between them without having to re-enter all the data at each switch.

Not sure what the openaps commands are to change the profile selected on the pump, though that would probably be good to be sure that the two match both by changing it on the pump and verifying that the pump profile is the same as Loop's.

As a shorter term fix, however, not having to re-enter everything each time I switch would be great.

Insert glucose data from sentry packets if it exists.

Hi,
I'm trying to build Loop for the first time. After compiling it, the HealthKit appears as it does in the above screen shot. It compiles fine, but I want to make sure that this appears as it should.

Thanks!

As a prerequisite to dumping the mLab API integration, we can instead send some of the existing diagnostic data to Nightscout. There's some open issues to resolve:

• It sounds like the Nightscout web UI isn't built to handle the volume of status data that the OpenAPS users are sending. Waiting for these two stakeholders to sort things out might be best.
• iOS 10's new logging and activity tracing (and the macOS Sierra Console app) will be a much more user-friendly way for individuals to read logs. Where is the balance between what needs to be available remotely vs what can be available when the phone is physically plugged into a Mac?
• Some of the diagnostic data should first be made available offline, directly within the app. CommandResponseViewController can adapt to this use-case easily.

When scrolling vertically in app (and even when specifically selecting a point to touch below the graphs), it acts as a horizontal swipe and selects data/scrolls horizontally on all three graphs. This shows what looks like erroneous data points selected on the graph when scrolling back to the top.

Getting the following:

/Users/riandraeger/Library/Developer/Xcode/DerivedData/Loop-dtxjtygpwjqtvpdpviclkilopvcs/Build/Intermediates/Loop.build/Debug-iphoneos/Loop.build/Script-43EDDBEF1C361BCE007D89B5.sh: line 3: /usr/local/bin/carthage: No such file or directory

When attempting a bolus this evening through the app, the pump gave a A52 error and reset - counted from 1 to 7 and then restarted. Upon restart the time was wiped out, the pump stopped working, and it said I needed to rewind. After rewinding and redoing the reservoir, the pump seems fine. This is actually the second time this has happened. The first time, I didn't log an issue as I thought it was just something random. But this is the second time this has happened while using the Loop.

According to this random internet post http://www.diabetesforums.com/forum/topic/51722-mlnimed-revel-error-a52/ - an A52 error is a software safety check as a result of the bolus error.

We have never gotten this error before using openAPS which seems logical since it doesn't do boluses.