Ns readonly treatment download - #4646
Conversation
Treatment download was gated on the upload master switch
(cloud_storage_api_enable), so a device could not act as a read-only
Nightscout client - for example a family where AAPS is the sole
uploader and xDrip devices should only receive the BG checks and notes
entered there. Downloading with upload off cannot duplicate anything:
it never writes to Nightscout.
The download switch and the Base URL field lose their dependency on
the upload switch accordingly. Download is also skipped quietly while
the base URL is unset, still the {template} placeholder or unparseable,
instead of throwing URISyntaxException on every attempt.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The treatment download previously only ran when the Home screen was opened, so treatments entered elsewhere (e.g. a BG check in AAPS) reached a follower with the phone in a drawer only much later. Trigger the same rate limited download from the follower's periodic background cycle. No-op unless treatment download is enabled. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A blood test downloaded from Nightscout stayed on the device that downloaded it. Push newly downloaded blood tests over xDrip sync so the rest of the family (master and other followers) receives the calibration-eligible marker without each device needing its own Nightscout download configured. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The same Nightscout entries reappear in every download pass, so a single Sensor-type BG check flooded the log with "Cannot use bloodtest which is not type Finger" every minute. Track which entries have already been complained about and log each only once, while still rechecking so a later edit to Finger gets imported. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Thanks for your PRs. If a particular issue is being addressed, please explain how we can recreate that issue. It is not a good idea to provide your API_SECRET to someone you want to follow you. You can provide a read token to them. Then, they can only read and will never be able to upload anything: |
|
On the read token — you're right, and it's compatible with this PR. |
|
Can you explain exactly how you are setting up xDrip as a Nightscout follower please? |
|
You shouldn't use Nightscout under Cloud Upload for setting up xDrip as a Nightscout follower. |
Oh but why not? As it does include downloading data from nightscout? I am happy with my current setup - my nightscout on free northflank tier is not stable enough to keep it as a single source of data for followers. I have my AAPSClient bound to nightscout, and using xdrips as xdrip sync followers, which has helped me a lot already - when nightscout is down, I still get readings on xdrip, and when xdrip sync is down (it happened a few times in a couple of years), I still get readings over nightscout. I've seen reports that the commercial nightscout is not too stable and gets offline from time to time too, so keeping it either xdrip sync or nightscout wouldn't be a good idea. Also, this PR is about downloading treatments from nightscout, not BG data. |
Because that is not a data source. xDrip can be a Nightsccout follower. xDrip can also upload to Nightscout. You have to set up xDrip differently depending on if it is meant to be a follower or an uploader. |
xDrip can also be xDrip Sync follower and receive missing treatments from Nightscout with this little change. I don't want to set it up as nightscout follower because of the reasons I stated above. What is the reason to have this limitation? |
|
OK, I finally understand what you wan to do. But, why not just switch the hardware data source to the one that works at any time. If xDrip Sync works, leave it like that. When it stops working, change the hardware data source to Nightscout follower. |
Not really, as what I initially want is to get the finger BG treatment data entered in AAPS and broadcasted to xdrip master and followers. It doesn't work now - do you know why? The finger bg check data entered in AAPS doesn't sync over local broadcast to xdrip. If it did, I would be happy too, but I'm afraid AAPS local broadcast change would be required for that, so I took this direction - getting that data from nightscout. I could possibly achieve what I want if I had one of the followers to follow nightscout - others would probably get that data synced from that one, but it would still be a workaround where a solution is possible. The proposed solution would actually benefit a setup with no followers at all - one could enter a bg check in aaps and get it in xdrip while using local broadcast, which probably doesnt send this data now (not sure, needs testing). |
|
xDrip is a CGM. AAPS is not. We shouldn't add redundancies to xDrip. There is enough in it already. |
|
AAPS does nothing with it, its for information only. And its not necessarily for calibrations, its more to let the parents know whats an actual BG. Its more convenient to use a single app to enter everything - aaps is used to enter carbs, insulin and other stuff anyway, and has a nice way to enter finger bg too - but we cannot use it because it simply doesnt sync to xdrip. I had a hard time making my child to enter finger bg data into xdrip, maybe because he is not used to it or what, but now when he can do it in AAPS (with this fix), it gets entered more often. |
|
If we set up xDrip as a Nightscout follower and it does not download blood glucose readings from Nightscout, it makes sense to add that ability. I didn't know it did not do that already. Setting up xDrip to upload to Nightscout and add a checkbox to disable its upload is not a good idea in my opinion. If someone doesn't want xDrip to upload, they should not go to the Cloud upload menu in xDrip. |
|
No, it's not that. Take a setup with no followers at all - xdrip is with dexcom (or any other direct cgm) source, broadcasting BG data to AAPS over local broadcast, and receiving AAPS related data (insulin, carbs etc.) directly from AAPS. No nightscout involved. This setup does not sync finger BG check values (and many other treatment values) from AAPS to xDrip. We can either fix this local sync to include whats missing - that would probably involve a change to AAPS as well, or use nightscout as a mediator - as it has all data uploaded from AAPS, we can just download it in xDrip from nightscout, with just the proposed fix. |
|
So, if you set up xDrip as a Nightscout follower, does it download blood glucose entries? |
|
If AAPS broadcast to xDrip does not include blood glucose, we can ask AAPS to add that. If xDrip blocks it from AAPS, we need to fix that. |
|
It probably does, I don't really know that, as its not the follower sync problem that is being adressed.
|
|
A setup that has no followers at all must have AAPS installed then. That user can see all the blood glucose readings in AAPS already. I was talking about your case where you are following your child. You can set up your xDrip to use xDrip Sync or Nightscout follower. If either one of those is skipping in downloading something, we can talk about fixing those. |
We are not adding a switch to stop uploading. In the existing nightscout sync (rest api) infrastructure, we only enable the nightscout url entry and the switches to enable treatment data download while the upload switch is still off. That does look strange, as it looks like master switch, but it now would become not a master, but just a switch for the Upload functionality, letting the download functionallity to be toggled independently. |
But he cannot see the AAPS finger BG checks in xDrip, which would be a lot more convenient as it provides a 10 minutes delay and a nice visual match of sensor vs finger readings inside the graph. AAPS doesnt have that. |
So, the problem is that your son's xDrip does not show blood glucose readings from AAPS. |
|
Yes, we can narrow down the problem to that. xDrip does have a line for reading finger BG check value from AAPS, which is commented out. I haven't checked the AAPS side - will do it now to see if it gets sent from AAPS. Yet the provided fix involves more than just a finger BG readings - xDrip now also receives additional events like "AAPS started", "Missed BG readings", any notes entered manually in AAPS and much more. Should all of this be included in the data transferred from AAPS to xDrip locally? Or should it have some boundaries and send only the critical data, as the remaining not that critical treatments could be received from nightscout (using the provided fix)? Anyway, will come back soon with the information about what's being sent from AAPS. |
|
You can wait for the lead developer review. Hopefully, he will not have as much trouble as I did understanding what the problem is. xDrip receives data only from one data source. There have been requests to allow one to get data from two at the same time. It has never been approved. Isn't what you are looking for the AAPS client? It lets you see what your son sees in AAPS. |
|
I do have AAPS client and I can see what my son sees in AAPS, that is not a problem - I particularly want to see BG check data in xDrip, as AAPS doesn't provide a convenient way to match it with sensor data. Also, it would be neat to have all the data around, and not have to look for some things in one app, and other things - in another one. It's not a "several data sources" problem. The datasource is still single, we just enable the treatment download from nightscout (which doesn't include the sensor BG data). That is already available with the nightscout upload enabled - it allows downloading from nightscout (while already having configured another physical data source), it just requires uploads to be enabled too, which I try to become an option, not a requirement. |
|
OK I also tested what AAPS actually does when I enter things. 1 g of carbs — showed up in xDrip within seconds, on its own. It's AAPS's XdripPlugin (app.aaps.plugins.sync.xdrip, DataSyncSelectorXdripImpl). It selects which data types to broadcast to xDrip — processChangedCarbs fired for the carbs and sent NEW_FOOD. There is no equivalent for therapy events, so BG checks never leave AAPS toward xDrip locally; they go only to Nightscout. That's the whole asymmetry, and it's a deliberate limitation on the AAPS side, not something xDrip can fix by listening harder. |
Fair enough. I also updated the initial PR description to reflect our conversation here, hope it is more understandable now. |
2 participants
Let xDrip read AAPS-entered BG checks (and notes) from Nightscout, without turning on upload
The problem
A finger BG check entered in AAPS never appears in xDrip. This is by design on the AAPS side, not a bug you can see: AAPS broadcasts carbs and insulin to xDrip locally (its XdripPlugin sends them straight over), but it does not broadcast therapy events like BG checks — those it sends only to Nightscout. So the only way xDrip can obtain an AAPS BG check is to read it back from Nightscout. Today xDrip refuses to download treatments from Nightscout unless the upload master switch is also on — which would make xDrip a second uploader to a site AAPS already uploads to, duplicating everything.
How to reproduce (xDrip + AAPS on one phone, AAPS uploading to Nightscout):
(Verified by watching the broadcasts: carbs go out as
info.nightscout.client.NEW_FOODto xDrip; the BG check produces no broadcast toward xDrip at all, only an NSClientV3 upload. xDrip's own AAPS receiver even has a commented-outmgdlread atNSClientReceiver.java:303, but it's moot — AAPS sends nothing to read.)What this changes
What this is not
For the reviewer — the open question
The confusion seen in comments is probably about the names of the settings and their placement: a read-only download option living under Cloud Upload menu reads oddly. The suggested alternative — make the Nightscout-follower data source download treatments — wouldn't serve this case, because the reading source here is Dex or xDrip Sync+ Follower or anything else, so switching to Nightscout follower is not an option - nightscout is not a source, but a supplement for the data which is not received over the other existing channels, like local broadcast from AAPS. If we could rename "Cloud Upload" to "Cloud Sync", that would probably remove the discrepancy. Also, the Enabled switch in the root of Nightscout Sync would probably have to be renamed to "Enable Uploads". That is your call and I'm happy to make any required changes to the settings, which I tried to keep minimal with this PR.
Why it's worth the complexity
Any AAPS user can now see AAPS-entered BG checks in xDrip's graph — with xDrip's 10-minute delayed marker and a visual match against sensor values, which AAPS doesn't offer — and keep BG checks, carbs and insulin all in one place, entered once in AAPS.