new dev branch starting post 14.2.4 release #7146
Conversation
The /api-docs/ endpoint will now send the correct api-secret header when API_SECRET is used for authentication.
Using share2nightscout-bridge, the device property is defined as 'share2' displayBg should honour the Dexcom HIGH and LOW values when the device is share2 This ensures that NightScout returns "LOW" for 39mg/dl and "HIGH" for 401mg/dl as is reported in the Dexcom app/receiver.
@bewest I tested current dev. Unfortunately, this does not work currently. Nightscout dev deployed to Heroku, but my NS was then broken. But then I reverted 513d155 minimed-connect-to-nightscout, and now the Dexcom arrows are working again. Curiously, when scrolling backwards in time, the undetermined arrow is still present, but new readings are good. Details: Trend arrows seem to be ok now, have observed flat, 45 up and one arrow up. |
|
I tested Details: |
|
I can also confirm that the minimed-connect-to-nightscout commit breaks NS during start-up. As mentioned by @bjornoleh and @devonestes, reverting this single commit allows it to start correctly and then corrects the Dexcom Bridge trend arrow problem (from deployment onwards). EU Dex server
|
This reverts commit 513d155.
This patches uses a newer versin of minimed-connect-to-nightscout that is designed to work under the same version of node as Nightscout. It should result in Nightscout gaining a capability to use Medtronic Careportal accounts for cloud to cloud synchronization.
…pitchford/cgm-remote-monitor into dev
For Medtronic Carelink folks, we need the following scenarios tested:
|
|
Can’t comment on Carelink functionality, but dev is working with Dexcom share now, and I had no issues deploying or opening my NS site. Thanks for the fix, and also looking forward to having less differences in mmol/L BG values between apps with "MMOL_TO_MGDL": 18.018018018 |
|
@bewest , did you find any evidence that the Share changes were not fully rolled out for OUS accounts? Someone mentioned an inconsistency for European users, where some allegedly were not affected. I am unsure if this was a misunderstanding, or if some may have been using US accounts. I’m just concerned a fix would break unaffected accounts, unless there is already a check that considers if the changes has taken place or not. Perhaps that is the case for the NS fix? Thanks! |
|
@bjornoleh unfortunately I only know what is reported on these threads. Much more information is required. The patches in question appear to apply to all glucose values, US and OUS. It looks to me like there are guards and detection so ensure that so long as the shape of the data stays the same, we can handle trends described by an integer or by a string. We don't have any kind of logging for observability that gives us oversight of all Nightscout users. Likewise Dexcom does not implement equitable data governance policies or have any relationship with us to communicate details about our constituents. |
|
Thanks, as long as both ways are supported, I guess it will be fine. I will tag you in the LF FB post with the report I was thinking about from Switzerland. |
|
I will say that Dexcom knows that there are different legal and regulatory requirements in different countries. In addition it is not unusual for them or other medical device vendors to roll out changes in different geographical regions on different timelines. Both reasons will cause slight differences among the global population. Nightscout is a big tent. |
Hey @bewest,
|
The `npm audit fix` in the `Dockerfile` is currently deleting vulnerable packages. Although we do want to have package security, this should be done in a development process, not as part of the Docker build. This commit also reduces the Docker image size and improves security.
…an/cgm-remote-monitor into dev
This should force the coverage job to return with a success error code. Codacy changed support for legacy projects. This change should not cause builds to fail and should not influence ability to merge pull requests. Until further work with coverage with codacy, this change emits a warning of "NO COVERAGE" while allowing the build to pass, rather than failing the build.
When collecting date from Dexcom via share2bridge-dexcom before we would poll at regular intervals. Dexcom transmitters / apps refresh every 5 minutes give/take the inaccuracy in the transmitters clock. If we poll every 5 minutes, we will randomly introduce up to 5 minutes of lag before we refresh. For example, if we poll 4:59s after dexcom refreshed we will face a 4:59s lag seeing the latest data arrive This patch introduces a refresh adjustment. We look at the timestamp of the most recent data item and aim to refresh 5 minutes plus a buffer after that timestamp. for example, 5:20s after the most recent data time. the additional buffer gives dexcom a chance to push the data through their application/infrastructure (after the app sends the data, it appears in testing to be around 20s before it is available in the API) This reduces the lag time to a reliable 20 seconds regardless of when nightscout was started and keeps it in track as it drifts forwards and back.
The default interval is increasd from 2.5 minutes to 2.6 minutes This change incorporates the lag between the app uploading and the data being available in share2nightscout-bridge This change also accomodates the optimisation of the refresh interval based on the last collected data timestamp
…excom_fetch_times Optimize time between polling share2nightscout-bridge to reduce ingest lag
Please target new developments for inclusion in the next release of Nightscout to the
devbranch.