Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Upload of "eventType: Sensor Start" to the Nightscout treatments works only to 1st NS site #266

Open
bordeb opened this issue Jan 12, 2018 · 8 comments · May be fixed by #3362
Open

Upload of "eventType: Sensor Start" to the Nightscout treatments works only to 1st NS site #266

bordeb opened this issue Jan 12, 2018 · 8 comments · May be fixed by #3362

Comments

@bordeb
Copy link
Contributor

bordeb commented Jan 12, 2018

When starting new dex sensor it seems that, if there is more than one Nightscout sites (REST-API) in the Base URL settings (space delimited), the upload of the "eventType: Sensor Start" works only for the 1st (first) NS site in a row. All other NS sites are missing this data. I tried to confirm this with fresh setup of multiple NS sites and clean install of the xDrip+ app and can confirm this issue. I also tried to reorder the NS sites under Base URL settings and it is always only the first one in a row that receives the while all others are missing the "eventType:" "Sensor Start" data.
xDrip + app ver latest stable: 2017-11-13
NS ver latest: 0.10.2-release-20171201

@bordeb bordeb changed the title Upload of "eventType: Sensor Start" to the Nightscout treatments only to 1st NS site Upload of "eventType: Sensor Start" to the Nightscout treatments works only to 1st NS site Jan 12, 2018
@jamorham
Copy link
Collaborator

jamorham commented Mar 6, 2018

Can you try this again in the latest nightly? March 6th.. let me know if I have resolved it. Thanks

@bordeb
Copy link
Contributor Author

bordeb commented Mar 7, 2018

Thank you @jamorham ! Now I figured out - or better to say remembered (silly me) how I can easily test this without the real change of the sensor so I will test it and report here. I will make some test NS sites and fresh xdrip installation on spare phone (parakeet system) and test this and report here

@bordeb
Copy link
Contributor Author

bordeb commented Mar 7, 2018

Hi @jamorham , I have just tried with nightly 6th March and it seems that the issue is still not resolved. The behavior that I can see is still the same.

@bordeb
Copy link
Contributor Author

bordeb commented Dec 2, 2018

HI! I just want to shed some attention to this old issue. I am still experiencing this issue. With dexcom as well as with libre sensors.

@Navid200
Copy link
Collaborator

@bordeb Is the problem still there with more recent releases of xDrip and Nightscout?

@Navid200
Copy link
Collaborator

Closing due to inactivity

@Navid200 Navid200 reopened this Oct 25, 2022
@jonprogers
Copy link

This issue is still happening as reported here: #2299 (reply in thread) and here #2358 (reply in thread)

@Navid200 asked me to transfer the information to this thread.

Where there are two space separated URLs specified as the Base URL in xDrip settings;

  • glucose values (type sgv) are uploaded to both nightscout instances
  • CGM calibration events are uploaded to both nightscout instances
  • other treatments and events (for instance I've experienced it with:- carbs, insulin, CGM sensor start/stop) only go to the first URL specified

Swapping around the order that the URLs are listed causes to carbs, insulin etc. to go to which ever nightscout instance islisted first.

My current configuration is two nightscout 14.2.5 instances, xDrip nightly from 2022.10.15 and dexcom g6 being read directly by xDrip with the G5/G6 Transmitter hardware data source and the Native Algorithm enabled.

@TiagoPRSilva
Copy link

When starting new dex sensor it seems that, if there is more than one Nightscout sites (REST-API) in the Base URL settings (space delimited), the upload of the "eventType: Sensor Start" works only for the 1st (first) NS site in a row. All other NS sites are missing this data. I tried to confirm this with fresh setup of multiple NS sites and clean install of the xDrip+ app and can confirm this issue. I also tried to reorder the NS sites under Base URL settings and it is always only the first one in a row that receives the while all others are missing the "eventType:" "Sensor Start" data. xDrip + app ver latest stable: 2017-11-13 NS ver latest: 0.10.2-release-20171201

After all i found some relevant logs in nginx

tail -f access.log my-redacted-public-ip - - [11/Apr/2023:22:49:22 +0100] "GET /api/v1/treatments HTTP/2.0" 200 2 "-" "okhttp/3.12.13" my-redacted-public-ip - - [11/Apr/2023:22:49:22 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:49:23 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:49:25 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:49:27 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:49:32 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:49:37 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:49:43 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:49:48 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:49:53 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:49:58 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:03 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:08 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:13 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:18 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:23 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:27 +0100] "POST /api/v1/entries HTTP/2.0" 200 68 "-" "okhttp/3.12.13" my-redacted-public-ip - - [11/Apr/2023:22:50:27 +0100] "POST /api/v1/devicestatus HTTP/2.0" 200 161 "-" "okhttp/3.12.13" my-redacted-public-ip - - [11/Apr/2023:22:50:27 +0100] "GET /api/v1/treatments HTTP/2.0" 200 2 "-" "okhttp/3.12.13" my-redacted-public-ip - - [11/Apr/2023:22:50:28 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:33 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:38 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:43 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0" my-redacted-public-ip - - [11/Apr/2023:22:50:48 +0100] "GET /socket.io/?EIO=3&transport=polling HTTP/2.0" 400 51 "-" "okhttp/4.9.0"

@Navid200 Navid200 linked a pull request Feb 25, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants