Skip to content

Conversation

@danamlewis
Copy link
Contributor

This will keep Nightscout in sync with autotune after the nightly run.

This will keep Nightscout in sync with autotune after the nightly run.
@danamlewis
Copy link
Contributor Author

Inspired by @jpcunningh 's additions to the doc with the manual instructions (https://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/nightscout-setup.html#how-to-automatically-sync-your-profile-from-autotune).

I can't think of any reason why uploading nightly would not be desired behavior, but please chime in if you can think of a use case where that's non-optimal.

if [[ $ENABLE =~ autotune ]]; then
# autotune nightly at 4:05am using data from NS
(oref0-autotune -d=$directory -n=$NIGHTSCOUT_HOST && cat $directory/autotune/profile.json | jq . | grep -q start && cp $directory/autotune/profile.json $directory/settings/autotune.json) 2>&1 | tee -a /var/log/openaps/autotune.log &
(oref0-autotune -d=$directory -n=$NIGHTSCOUT_HOST && cat $directory/autotune/profile.json | jq . | grep -q start && cp $directory/autotune/profile.json $directory/settings/autotune.json && oref0-upload-profile settings/profile.json $NIGHTSCOUT_HOST $API_SECRET) 2>&1 | tee -a /var/log/openaps/autotune.log &
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you would want to upload either the $directory/autotune/profile.json or the $directory/settings/autotune.json rather than the $directory/settings/profile.json because it won't be updated yet to the new basal profile in the $directory/settings/autotune.json by the time it runs.

The downside is that you won't pick up changes made in the preferences.json file over time. There is a separate issue opened up on autotune not picking up those changes. Once that is resolved, I don't think $directory/settings/autotune.json will have a downside.

@tim2000s
Copy link
Contributor

tim2000s commented Oct 10, 2018

I think this should be possible to merge in now as the Autotune update issue #1101 has been closed and rolled into dev?

@efidoman
Copy link
Contributor

I plan to test these changes on my system as soon as I get my install issues resolved.

Conflicts:
	bin/oref0-cron-nightly.sh
@scottleibrand
Copy link
Contributor

Have been running this for awhile, and it's working properly. Ready to merge if no objections.

@tim2000s
Copy link
Contributor

I’ve been seeing an oddity with this. The uploaded script hasn’t been uploading the autotuned CR, only the pump CR. It also seems to split the last half hour of carb ratio out. Anyone else seen this? (Note that upload currently disabled, hence date in image)
3f05273f-283e-451c-a1d7-73f6ef1331e7

@scottleibrand
Copy link
Contributor

Our uploaded CR record isn’t showing a pump value or multiple CR schedules, but it’s also not updating and is now out of date.

@viq
Copy link
Contributor

viq commented Mar 7, 2019

Woudln't it also make sense for the oref0-upload-profile to issue a Profile Switch even to nightscout?

@tim2000s
Copy link
Contributor

tim2000s commented Mar 9, 2019

@viq No. If you automatically make a profile switch then you don’t give people the option of not profile switching, which some may wish to have. Profile switch events should either be an option in set-up of profile upload or a separate trigger event.

@viq
Copy link
Contributor

viq commented Mar 9, 2019 via email

@tim2000s
Copy link
Contributor

Given the way that people are using AndroidAPS is noticeably different from OpenAPS, I’d disagree.

As people have now started to use the automated profile switching capabilities off triggers, automating a profile switch in NightScout when this is going on starts to run into conflict with what people are doing to override a profile. This isn’t something that exists in a OpenAPS world so has never been an issue.

That’s why I’d prefer it to be something that is a deliberate choice for someone wanting to use Autotune. Enough people don’t understand the OpenAPS aspects of AndroidAPS so it would be good to force them to explicitly understand the implications of this.

@viq
Copy link
Contributor

viq commented Mar 10, 2019 via email

@tim2000s
Copy link
Contributor

I don’t think that’s unreasonable. Would be worth updating the docs at the same time with a warning that this would override any automated profile switching using glucose triggers.

@scottleibrand
Copy link
Contributor

Updated rounding, and confirmed that a manual run is uploading updated data. Also updated the nightly cron to wait 60s between finishing autotune and uploading profile, to allow cron-every-minute to run ns-loop and update the profile.json. Will let it run on one rig and check it after tonight's autotune run to confirm it gets the new values.

@scottleibrand
Copy link
Contributor

This successfully uploaded our newly autotuned profile this morning at 04:08:50, so I think it's good to merge.

@scottleibrand scottleibrand merged commit 75d08e1 into dev Oct 8, 2019
@scottleibrand scottleibrand deleted the nightly-autosync-NS branch October 8, 2019 01:50
scottleibrand pushed a commit that referenced this pull request Oct 27, 2019
* Have autotune sync to NS nightly after autotune runs

This will keep Nightscout in sync with autotune after the nightly run.

* always round insulin to carb ratios to 0.1g

* round basal rates to 0.01 U/h, not 0.001

* sleep 60s to generate a new profile.json
scottleibrand added a commit that referenced this pull request Oct 29, 2019
* Offline xDrip looping

* Add the script to package.json

* Add the glucose value

* Changed the setup json to use the offline script

* Also add the script to ns-loop shell script

* Fix web script trying to access BG data when there's none

* Better error logging

* Output full filename on on parse error

* Ensure JSON parse gets a string, not a stream

* Don't read the file we're outputting to

* Don't read file we're outputting to

* Fix path typo

* Try loading from router, not hardcoded address

* Fix bug resulting from code restructuring

* The apparently rare case where glucose is loaded from Nightscout before a new reading was available out misformatted data

* Better error logging for wrong secret

* Code cleanup

* remove unused ns-glucose report instead of updating it

* remove commented-out Spike stuff

* tabs to sapces

* Remove binary download options (#1252)

* Remove binary download options

* Add radiotags to runagain, and fix bug for radiofruit hardware type

* Use Edison's FAT32 Partition (#1253)

Mount the Edison's FAT32 partition to give us enough room to install golang.

* Radiotags in oref0-runagain.sh (#1254)

Pass radiotags to oref0-setup.sh from oref0-runagain.sh.

* Add network module dependency (#1261)

Fixes issue of `Cannot find module 'network'` in the ns-looplog.

* Debian Buster compatibility  (#1275)

* Save hardwaretype in preferences.json

Store hardwaretype so that it can be used elsewhere.

* Install node v8

Make sure nodesource repo is used to install nodejs and npm.

* Install node v8

Make sure nodesource repo is used to install nodejs and npm, except on armv6...

* Switch Radiofruit openaps-menu back to main repo

* fix systemctl syntax

* skip bgproxy if we already have a new glucose value and it's time for another loop

* checkip.amazonaws.com now puts spaces after commas

* Allow oref0-upload-profile to also switch to new profile (#1285)

* Unused local variables (#1284)

* raspbian password checking adjustment (#1282)

old line 12: the existing logic didn't make sense to me check for edison  but expire root so adjusting to check for root, expire root
old line 16-21: If you changed the password for 'pi' before running the script you'd never get to the part about changing root's password as it's disabled and locked by default and therefore /run/sshwarn will not exist.
new line 16-32: Check if we are running Raspbian, check the build date against the current password date for both pi and root. If they are the same, we are using default passwords and prompt for change. Checking them independently and only information message once.

* fix wrong interface choose (#1286)

By default, choose the first interface found with a control socket in the socket path.

* fix bootstrap to put tune-dia-and-peak argument on openaps-install, not the curl

* Allow G4 Share serial to be blank (#1268)

* Categorize improvements for libre 1 minute data (#1238)

* Work in progress on categorize

  * Determine date & dateString properties in prepGlucose map function
  * Filter invalid records in filterRecords filter function
  * Clean up for loop to remove previously performed checks
  * Average any values that fall within the 2 minute deadband

* Increase limit to allow for 1 minute data

  * Ensure 1440 (60*24) records can be downloaded

* refactoring: round_basal (#1294)

- parametrized mocha test

* Improved rounding of mmol/L units in oref0-upload-profile (#1295)

* Round ISF properly in oref0-upload-profile with mmol/L units

* Round BG targets properly in oref0-upload-profile with mmol/L units

* Add explanations for unit conversion code

* Reestablish bluetooth connection after failure to set bluetooth hci name (#1291)

* Reset bluetooth adapter if fail to set bluetooth hci name

* Check to make sure oref0-bluetoothup not already running

* Stop bluetoothd and allow next cycle to handle restart

* per #1288, only use minZTUAMPredBG if enableUAM, and use minGuardBG otherwise (#1292)

* run oref0-set-system-clock after oref0-set-device-clocks in case rig is offline (#1290)

* run oref0-set-system-clock if oref0-set-device-clocks fails

* remove output redirection for debugging

* run oref0-set-system-clock regardless of return code from oref0-set-device-clocks

* fix tabs that should be spaces

* Fix case mismatch that causes values in mg/dl to be multiplied by 18 (#1296)

* Add checks to make sure variables are defined. (#1297)

* Update bin/all-autosens-history.sh

Add 2019

Co-Authored-By: viq <[email protected]>

* lodash 4.17.15 per npm audit fix

* Have autotune sync to NS nightly after autotune runs (#1098)

* Have autotune sync to NS nightly after autotune runs

This will keep Nightscout in sync with autotune after the nightly run.

* always round insulin to carb ratios to 0.1g

* round basal rates to 0.01 U/h, not 0.001

* sleep 60s to generate a new profile.json

* Standalone MRAA installer for OpenAPS v0.7.0 (#1302)

* Standalone MRAA installer for OpenAPS v0.7.0

Addresses #1270

* Add oref0-mraa-install to package.json

* Unused local variables (#1301)

* Unused local variables

* Unused local variables

* Upload preferences.json and oref0 version to devicestatus (#1300)

* per #1288, only use minZTUAMPredBG if enableUAM, and use minGuardBG otherwise

* upload preferences.json to devicestatus

* use --preferences instead of positional arguments

* yargs entry for --preferences

* upload oref0 package.json version string

* redact sensitive fields in preferences.json

* reduce size of large logfiles like new -date ones

* remove old commented-out code

* remove old commented and deprecated code

* Refactor enable smb in determine-basal.js (#1299)

* Move the enable SMB into its own dedicated function

This will allow easier SMB conditional implementations

* Forgot to remove the existing logic...

* fix function naming

* function fix round 2

* don't let  kill the script if oref0 already exists

* Travis CI: Upgrade to Python 3.8 and add more flake8 tests (#1304)

* Non-breaking space (#1305)

* Non-breaking space detected by eslint

* Detect socket timeout and don't log stack trace

* whitespace

* Add  ECONNREFUSED to safe error list, better error message

* Reduced logging (#1309)

* Detect socket timeout and don't log stack trace

* Add  ECONNREFUSED to safe error list, better error message

* Consolidate IP logging to same line as xDrip load notification, remove unused variables

* Disabled xDrip logging after first error

* expand one-line json to properly count glucose entries
@st8ass
Copy link

st8ass commented Nov 6, 2019

This successfully uploaded our newly autotuned profile this morning at 04:08:50, so I think it's good to merge.

@scottleibrand does not work, if configured authorization with token
authorization-with-token

@scottleibrand
Copy link
Contributor

If you or anyone would like to volunteer to add tokenauth support, I'd be happy to review a PR. We don't use it, though, so I can't really develop or test that easily.

I also wouldn't want to hold up the 0.7.0 release for missing tokenauth support, unless it causes failures of something other than the new profile upload feature. Have you seen any such side effects?

@st8ass
Copy link

st8ass commented Nov 7, 2019

I understand. No problem with that, this is not essential

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 this pull request may close these issues.

8 participants