- calendar event visual indicator (#411)
- will change colour depending on BG value as per main chart objective values for (urgent high, high, low and urgent low)
- option added to show/hide visual indicator in Calendar Event settings
- small changes made to interval label texts
Co-Authored-By: Gary Dalley <4158482+gonkowonko@users.noreply.github.com>
- 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
Paul Plant