- implemented to ensure a minimum time has passed since sensor activation
- especially necessary for Libre sensors (either Libre 2 BLE or Libre through transmitters) that can transmit glucose values immediately after activation. The first 50 minutes can often produce very unreliable values so it's better to just not process anything during this time.
- note that there is no set time after which the sensor values are reliable. Sometimes after 10 minutes, values are good. Sometimes it needs 30 or even 40 minutes.
- warm-up time is therefore initially set to 45 minutes warm-up time but minimumSensorWarmUpRequiredInMinutes can be edited in ConstantsMaster.swift
- don't ask the user for confirmation when automatically disconnecting the transmitter after a failed NFC scan
- the erroneous true value was left in by error whilst testing
- change "Follow Dexcom-app" to "Read from Dexcom app" to avoid confusion with Dexcom Follow
- changes to transmitter/sensor display formats to use Nightscout format and improve clarity
- label changes
- typo correction: disclosureAaccessoryView -> disclosureAccessoryView
- simplified sensor status UIAlert and now includes sensor duration (elapsed time since start) and remaining (time until end date)
- rewrite of NFC scan workflow
- initial scan of NFC-enabled sensors will now *not* initial BLE scanning
- NFC scan logic redone to perform several loops until a successful NFC scan with valid data is hopefully performed
- UI updated to inform user of scan attempts and give much clearer alert messages.
- haptic feedback (vibrations/noise) added to guide user during scan cycles
- a failed NFC scan will now inform the user and offer to immediately scan again. If the user declines the transmitter will be disconnected (if existing) or removed (if adding new)
- BLE Peripheral view should show correct status in connection row if pending NFC scan to continue
- once a valid NFC scan has been performed, the user will be informed and the superclass will be told to start BLE scanning to find the sensor/transmitter. This will avoid trying to connect before a valid NFC is performed
- the scanned sensor serial number is passed back through the delegate to update the expected device name at the same time as BLE scanning is started. This prevents the app from connecting to a different transmitter (i.e. Libre 2).
- when a Libre 2 sensor is disconnected, the active sensor is set to nil. This prevents the countdown from staying on screen with no valid sensor connected.
- as above but the libre1DerivedParameters are also set to nil to prevent an issue that can show very high readings when initially connecting to a new sensor
- related alert messages changed to improve clarity
- translations added for EN/NL/ES/FR/DE/PT/SV
For an unexplainable reason, after a calibration, and if loopdelay is used, there's one single wrong value created and sent to Loop.
I couldn't it fix it
but this change suppresses creation of readings for a period of loopdelay + 5.5 minutes
This was only for Libre with smoothing enabled.
sometimes the older values reappear but with a slightly different timestamp
this caused readings being uploaded to NS with just a few seconds difference
Fixed by adding 10 seconds to timeStampLatestNightScoutUploadedBgReading
This only works for treatments that are deleted within 24 hours after creation
Each time a list of treatments download from NS, there's a check to see if a treatment that was already uploaded previously, is in the list downloaded.
If not then we can assume it's been deleted, and will be marked as deleted also in xDrip4iOS
Minor bug in string replacement during translation. Change order of string replacement as "hour" is included in "hours". This affects all language translations
now the loopdelay feature gives smoothed values per minute readings to loopshare, with the exact delay
before this change, the delay was much bigger than the actual configured delay, and readings came in every 5 minutes, in stead of every minute
it's possible to create multiple cgm transmitters (eg a Libre 2 and a dexcom) but only one can be active, ie connected.
But one could go to the settings for the non-active CGM, and change the setting 'Use Transmitter algorithm'.
In that case, the setting was changed also for the active CGM, causing incorrect status.
this is fixed now
haha
seems some blePeripherals remain in coredata without a type being assigned. Probably happens while scanning for a new device.
those are now cleaned up at app start
loopDelay means that readings shared with Loop will be shifted forward with a predefined amount of minutes. Example : a reading that is for instance created at 15:00, to which a delay is applied of 5 minutes, then Loop will receive that reading at 15:05, while at 15:00, Loop will receive the reading that was created at 14:55.
This is only useful when used in combination with smoothing. Advantage is that readings that Loop will receive are more efficiently smoothed
- new setting is available in the Developer settings
- used SwiftUI to define a new View that allows to create loopDelays
- colors used in SwiftUI code are defined in Constants/ConstantsUI.swift
- deployment target increased from 12.0 to 13.0
- String extension getSchedule renamed to splitToInt
- if the user tries to add a new (or modify an existing) BG check and set it's date in the future, warn them that it is not allowed and set the date to now.
- this is a safety feature for APS system that can use BG checks as part of their prediction as well as CGM values
- the different treatment types (insulin, carbs, BG checks) can be filtered if required to show/hide them in the treatment table
- if boluses are shown, an option to filter micro-boluses is also enabled.
- button icon images are set individually as filled/unfilled to more clearly show if they are selected
- .getTreatments call reduced from 100 days to 21 days to save overhead
- previous settings options to show micro-boluses in the treatments table (and associated translations) removed as no longer needed
fix#362
- suppress sending unlockPayload : only for Libre 2. This allows to run/connect several apps to Libre 2
- suppress share readings with Loop : useful if more than one app (eg more than one instance of xDrip4iOS) run in parallel, to ensure only one instance stores readings in shared user defaults
- additonally, minor change in comments
- minor change in comments for LoopDelay
- added extra ranges to allow 24hr/48hr/3d and 7d options
- time period selected is now always shown but faded out
- when double tapped, the range changes to the next one and the label is turned white and then faded back out
This uses a new glucoseMiniGlucoseChart object to display a static 24hr or 48hr mini-chart beneath the main chart.
- simplified to display only glucose chart points with all axiis, guidelines and labels hidden.
- it will update every time new glucose readings are processed
- a double tap will toggle between 24hr and 48hr modes (default 24hrs)
- by default the mini-chart will be hidden (upon first ever launch) for users with "Zoomed Display" enabled. Otherwise, the mini-chart will be shown by default.
- as above but same logic also applied to the statistics view for first launch
- home screen settings menu edited to add option
- observer added to hide/show the chart after settings change and also to redraw the chart after hours are toggled by double tap
The bug was that after restore of failed Internet connection, new readings are not uploaded to NS.
- as mentioned in the comments of func uploadData(dataToUpload: Any, httpMethod: String?, path: String, completionHandler: (() -> ())?)
completionhandler should be called only when upload was successful.
But the result of the upload was never checked. So probably, in some error cases, completionhandler was called with success. As a result, the upload was considered as successful and not redone when internet comes back
- also some updates in func uploadDataAndGetResponse. Set nightScoutResult to .failed when there was an error.
Optimized getTreatmentEntryChartPoints to run faster.
- Previously, getTreatmentEntryChartPoints was generating lag and spikes of CPU usage.
- The code was optimized by reducing the amount of calls to getBgReadings.
- Now getBgReadings is only called once inside getTreatmentEntryChartPoints.
- Now calculateClosestYAxisValues interpolates the SGV value from the two closest bgReadings, if there are.
- Profiling registered a speed up of 500%.
- chart hour axis label and scroll back timestamp will be shown in user locale
- treatment list time will be shown in user locale
- snooze screen times and dates will be shown in user locale
- BLE peripherals dates and times will be shown in user locale
- alarm dates and times will be shown in user locale
- landscape view date will be shown in user locale
- small improvements to layout of alarms screen
- schema updated to include location and allow region changes in simulator/debug
- Date.fromISOString and Date.ISOStringFromDate now have an overload that accepts an optional reusableDateFormatter.
- ISODateFormatter unified between Date.fromISOString and Date.ISOStringFromDate and extracted to another func, Date.ISODateFormatter.
- BgReading dictionaryRepresentationForNightScoutUpload was a variable while the thing with same name at TreatmentEntry was a func. Now both are functions and accept an optional reuseDateFormatter as argument.
- Deleted dictionaryRepresentationForNightScoutUpload.swift.
- Implemented a progress bar named ProgressBarViewController and a struct used for updating it: ProgressBarStatus.
- SettingsSelectedRowAction callFunctionAndShareFile now updates the progress bar with each callback.
- DataExporter now reuses the same DateFormatter, speeding up the calls to dictionaryRepresentationForNightScoutUpload.
- DataExporter now receives the callback as argument at instantiation.
- DataExporter calls the callback to report progress during readingsAsDicts().
reduce timeStampLatestLoopSharedBgReading with 30 minutes. Because maybe Loop wasn't running for a while and so missed one or more readings. By adding 30 minutes of readings, we fill up a gap of maximum 30 minutes in Loop
- also small improvement in case loopdelay = 0, add 5 seconds to timeStampLatestLoopSharedBgReading to avoid storing values that were already stored previously
- BG Checks (finger prick) can be entered as a treatment
- will be converted and stored in coredata as mg/dl (to avoid having to add units to the treatment coredata model)
- will be converted and shown locally in the correct unit
- will be synced with Nightscout in the original unit
- Nightscout uploads will add the "GlucoseType"="Finger" and "units" attributes to align with BG checks entered via Care Portal.
- BG checks displayed on the main chart as a red circle with gray border as per Nightscout style
- observer added to refresh treatment table (values/units) if the bg unit is changed by the user
- add 5 seconds to last Readings timestamp, because due to the way timestamp for libre readings is calculated, it may happen that the same reading shifts 1 or 2 seconds in next reading cycle
- add tracing, can be deleted later on
Libre transmitteris tend to show erratic values. Smoothing improves those values a lot but only for historic values, not for the most recent values.
To avoid that Loop takes actions based on those wrong values, this new option allows to introduce a delay. Most recent values will not be shown. Older values will shift in timestamp. To Loop it will look as if this is the most recent value. Advantage is that values used by Loop will be more reliable, but running a number of minutes behind the real values.
New setting in development section. Only to be used for developers.
- in function syncTreatmentsWithNightScout, first check that nightscout is enabled and nightscout url != nil
- before splitting id by '-', check first that id is not an empty string
deletion is done at app start up.
If user would go to treatments screen very fastly, after starting the app, then it may crash (only once). But that's probably not going to happen frequently
by setting UserDefaults.standard.nightScoutSyncTreatmentsRequired = true, a treatments sync is triggered
This is now done when initiating readings upload
In case of Libre 2, this is every minute, even though there's an upload only once every minute
Upload of new readings and sync of treatments is done simultaneously
by setting UserDefaults.standard.nightScoutSyncTreatmentsRequired = true a treatments sync is triggered
This is now done when initiating download of readings.
Download of new readings and sync of treatments is done simultaneously
- use .decimalPad keyboard for insulin entries
- change "New Entry" to "New Treatment" as the idea of a Treatment "Entry" is not intuitive to most users
- minor IB layout changes to enable future new treatment types to fit easily
Bug that was there since long time, but (for unknown reason) created an issue only with the treatments enabled. Probably because of a small time difference (1 second) between timestamp of latest reading and actual timestamp
- missing variable/constant declaration comments added
- corrections to some comments
- improvements to array handling to prevent needing to unwrap
- ChartPointsScatterDownTrianglesLayer.swift moved
- stored/synced treatments will be displayed on the main chart
- carbs will be shown as a floating circle aligned with closest glucose point values
- bolus will be shown as a triangle. Micro-bolus threshold can be configured in settings (default: 1.0U). Micro-bolus will then be shown as small triangle with no labels
- option in settings to show/hide treatments on the chart (default is to show)
- changes to TreatmentType structure
- functions added to treatmentEntryAccessor
- new userdefault keys added to store new user settings
- a new chartpoint class extension has been added. This is modified from Loopkit
- correction to the NSResponse to correctly filter exercise treatments
- initial translations implemented
This release stores cgm transmitter address and characteristics in Shared userdefaults
xdrip-client-swift (also branch loopheartbeat) is also adapted. It reads the new shared user defaults and if necessary setsup a bluetoothTransmitter, scans and connects and subscribes to the receive characteristic
- TreatmentNSResponse : changed type of createdAt from String to Date
- TreatmentEntryAccessor : functions that use howOld as parameter, changed type from Int to TimeInterval
- created constant for maximum days to upload for treatments, default 7 days
- increased maximum amount of treatments to show in TreatmentsViewController to 100 days
- removed TODO : check that hTTPURLResponse.statusCode is 200
- removed checkIfDisReConnectAfterTimeStampFunction in comments of initializer NightScoutUploadManager (seems not used anymore)
- in DexcomShareUploadManager and NightScoutUploadManager : renamed upload to uploadLatestBgReadings to make clear distinction with other upload functions
- deleted xdrip/Texts/TextsNFCLibre.swift because it's not used (not related to treatments)
- renamed xdrip/Texts/TextsNightScoutTestResult.swift to xdrip/Texts/TextsNightScout.swift
- fix in getLatestTreatments, howOld
- removed getRequireUploadTreatments from TreatmentEntryAccessor, filter on treatments to upload is done in NightScoutUploader
- using a new value in UserDefaults to trigger a NightScout sync. Setting the value to true from anywhere will launch a new sync.
- quite some changes in NightScoutUploadManager
- TreatmentsViewController does not control the sync, it will just trigger it whenever necessary by setting UserDefaults.standard.nightScoutSyncTreatmentsRequired to true
- NightScoutSync is triggered from several places : create a new Treatment, update a Treatment, delete a Treatment, click the sync button
- Removed UIAlertController with result from NightScoutSync. It should always succeed. It's like uploading BgReading's.
- removed file TextsNightScoutTestResult.swift, seems not used
- in TreatmentNSResponse: matchesTreatmentEntry changed : check on date didn't work, not it compares date in milliseconds, that works.
- removed/changed some var's , coreDataManager for example which is now Implicitly Unwrapped Optionals, in stead of optional. This is something which could be improved throughout the project
- after download form NS : check if existing treatments are updated, and if so update locally
- delete treatments at NS : treatments deleted on the app are not permenanetly deleted from coredata, but there's a new attribute "treatmentDeleted" which is set to true. Which means will not be shown in table. It's needed to keep track of deletions at NS
- when conforming to methods, then it's not needed to comment the methods. They are already commented in the protocol declaration
- same applies to overriden functions
- use /// in stead of // when commenting declarations. By using alt-tap one a function or variable, one can see the comments
Paul Plant