are people running jubilinux-v0.2.0 ? I'm having issues with the network, just wanting to know if anyone is using that or not?
we had to update oref0-setup because people are. haven't seen any other reports of other problems since we fixed that.
had to add a kernel module for edisonvoltage
i started suspecting the my jubilinux version since I've been running the version from last summer. with the Wifi hotspot. but now I'm having a hell of a time with wpa_supplicant.conf
strange since i've never had issues with it before
but if others have gotten it to work, I'll figure it out. just wanted to make sure I was not attempting something no one else has got to work.
stuff like this is how you get better with linux!
strange /etc/network/interfaces keeps changing to default after a reboot
When I do
cd ~/src/oref0 && git checkout tiny-basal-eSMB && git pull I get error: pathspec 'tiny-basal-eSMB' did not match any file(s) known to git. What am I doing wrong here?
Apparently, I had to do
git pull before running the first command. I'm not sure why, but that's what google told me and it worked, so I'll go with that.
Yeah.
git pull runs a git fetch which pulls new branches down from the server.
haha, watching this pi rig (which I just set up) duel with my edison rig one minute apart is really funny -- the edison has a good autotune/autosens profiles, so it's setting ever-so-slightly different temp basals :D
Yeah, I assumed
git pull did something like that. Just don't remember having to do that before. I guess because this is an entirely new branch?
@cluckj you can copy them over if you get tired of the duel at any point ;)
Yeah, normally you git pull for some other reason at some point after I initially create a branch before you get around to wanting to check it out.
@danamlewis yep :D
@scottleibrand have any ideas on how to fix the issue with NS not displaying manual boluses....do you happen to know if someone is working on this already?
Running the latest Dev, can I change my curve back to the old curve so I can see if it solves my problems? If so what was it called? Currently I have it set to rapid-acting
You can, it's called bilinear. If that solves a problem, then that probably means some of your other settings are compensating for the inaccuracy of the old curve, and will need to be updated as you transition to the more accurate curve.
Keep in mind that autotune takes the curve as a given, and tunes everything around it. So running autotune over 2+ weeks of data with each curve might give you some insights as to what those differences are.
I'll try doing that tomorrow and see what the difference is on each curve setting.
@scottleibrand i agree with @andrew-warrington that it would be good to be able to disable or limit the SMB's when BG's are going down. @andrew-warrington suggests that in https://github.com/openaps/oref0/pull/732#issuecomment-337827623 . I think disabling SMB when BG is going down or one of the projected predicted BG's is a hypo would make SMB safer.
@dmdfreak @scottleibrand : i also had other settings that were compensating for the inaccuracy of the old curve. I think it would be good to advice to use
maxSMBBasalMinutes=20 for the first days when switch from bilinear to rapid-acting curve
@scottleibrand are there min temp low targets....ie if you entered a temp target of zero---maybe temp target re-established as 60 or 55...and reciprocally, max temp targets onthe high side ..if one entered 1000...maybe 190 or 200 is actually factored??
@garykidd Minimum target is 80 openaps/oref0#608
I do not know about a max. target
@PieterGit @andrew-warrington SMB while BG is trending down play an important role in correcting post meal-highs for us, so I would not like them to be disabled as a default behavior.
I was continuously getting the error:
"Could not get subg_rfspy state or version. Have you got the right port/device and radio_type?"
After doing all of the troubleshooting steps with no relief, I ended up flashing the edison again and starting from scratch.
Still didn't work.
I replaced the explorer board with a new one, and voila. It works.
So that error can indicate bad hardware, so if you are pulling your hair out with that error, you might try a new explorer board.
The only odd thing - when I replaced the explorer board, I expected my MAC address to change, but it didn't. Not sure if the MAC is generated and not an actual hardware address, but had me scratching my head...
@drnoname82 : the most SMB's I see are on a rising BG. I've seen some SMB's on falling BG's that were causing a hypo/low (or at least giving extra insulin when it was not wanted). I think the defaults should always be chosen based on safety first and not on correcting post meal-highs. I agree with Scott that we now have some issues, because of older settings (which were fine with the 0.5.x version) that give problems with newer algorithms. That doesn't mean the new algorithms are wrong (because the older settings might be wrong). We must make sure we properly document on how to use the new algorithms and adjusting the right parameters.
@primags : the MAC is stored on the emmc filesystem of the edison module
@PieterGit Thank you, I'll look up what that is :)
@primags Did you reprogram the radio chip using CCprog?
@drnoname82 Yes, I completed that successfully but it did not fix the issue.
@primags OK, that sucks. Our Explorer Boards both had the same problem, but reflasing with CCprog fixed it
@drnoname82 I think there may have been trauma to the board since we were trying to fit it in a 3D printed case and it never worked right after we "fit" it in there lol. But all other wireless communication / BT was working, which made me think it was software related at first
@PieterGit I totally agree that everything should be focused on safety. But I think the answer to your problem should be more refined than "Do not SMB when BG is trending down". For example when BG is trending down and deviations are rising because food absorption is picking up, I would want OpenAPS to SMB if necessary.
@primags : wifi and bt are in the edison module, so if you break the explorer board by putting it in a too tight case wifi and bt might still work if the intel edison still gets power
Thanks @PieterGit I changed back to bilinear last night. I'm going to let that run this morning and see if it changes how it was reacting, then I'll change back and change the MaxSMBBasalMinutes like you suggested and see what happens at lunch. Alo going to run autosense on both curves like @scottleibrand said and see what the dirrefence looks like.
@drnoname82 what do you mean with deviations are rising?
@dmdfreak i had problems with newer version, mainly because i used multiple CR and ISF schedules. now still working out the best single CR and single ISF. At least in that case a with a 0.6.0 upgrade (with SMB already used), I would be setting MaxSMBBasalMinutes to 20 or so to be sure the newer algorithm and curve does not cause (severe) lows
causing severe lows is exactly what was happening to me.
Running oref0-autotune --dir=/root/myopenaps --ns-host=https://mynightscout.azurewebsites.net --start-date=2017-10-01 --end-date=2017-10-20
Grabbing NIGHTSCOUT treatments.json and entries/sgv.json for date range...
Query: https://mynightscout.azurewebsites.net find%5Bdate%5D%5B%24gte%5D=1506834000000&find%5Bdate%5D%5B%24lte%5D=1506920400000&count=1000
-rw-r--r-- 1 root root 994 Oct 21 08:45 ns-entries.2017-10-01.json
Query: https://mynightscout.azurewebsites.net/find%5Bcreated_at%5D%5B%24gte%5D=2017-09-30T06:00-0500&find%5Bcreated_at%5D%5B%24lte%5D=2017-10-02T12:00-0500
-rw-r--r-- 1 root root 39761 Oct 21 08:45 ns-treatments.2017-10-01.json
oref0-autotune-prep ns-treatments.2017-10-01.json profile.json ns-entries.2017-10-01.json profile.pump.json > autotune.2017-10-01.json
/root/src/oref0/lib/autotune-prep/categorize.js:22
var glucoseData = opts.glucose.map(function prepGlucose (obj) {
^
TypeError: Object #<Object> has no method 'map'
at categorizeBGDatums (/root/src/oref0/lib/autotune-prep/categorize.js:22:40)
at generate (/root/src/oref0/lib/autotune-prep/index.js:22:30)
at Object.<anonymous> (/root/src/oref0/bin/oref0-autotune-prep.js:105:27)
at Module._compile (module.js:456:26)
at Object.Module._extensions..js (module.js:474:10)
at Module.load (module.js:356:32)
at Function.Module._load (module.js:312:12)
at Function.Module.runMain (module.js:497:10)
at startup (node.js:119:16)
at node.js:906:3
Could not run oref0-autotune-prep ns-treatments.2017-10-01.json profile.json ns-entries.2017-10-01.json
Trying to run autotune and I got this
check if
ns-entries.2017-10-01.json has been downloaded ok
how can I do that?
less ~/myopenaps/autotune/ns-entries.2017-10-01.json
perhaps something is wrong with the API_SECRET so that the downloading of cgm (and treatments) from NS does not work. the autotune script should fail on that.
What should I be looking for?
if it's not empty and it has bg data in it
I ran autotune without problems when I updated to 0.60
is this run on the rig, or on another system?
Only one I have currently
{
"error": {
"message": "ObjectID is not defined",
"stack": "ReferenceError: ObjectID is not defined\n at D:\\home\\site\\wwwroot\\lib\\entries.js:149:42\n at use_collection (D:\\home\\site\\wwwroot\\lib\\storage.js:45:7)\n at Function.getEntry (D:\\home\\site\\wwwroot\\lib\\entries.js:145:7)\n at D:\\home\\site\\wwwroot\\lib\\api\\entries\\index.js:148:17\n at Layer.handle [as handle_request] (D:\\home\\site\\wwwroot\\node_modules\\express\\lib\\router\\layer.js:82:5)\n at next (D:\\home\\site\\wwwroot\\node_modules\\express\\lib\\router\\route.js:110:13)\n at Route.dispatch (D:\\home\\site\\wwwroot\\node_modules\\express\\lib\\router\\route.js:91:3)\n at Layer.handle [as handle_request] (D:\\home\\site\\wwwroot\\node_modules\\express\\lib\\router\\layer.js:82:5)\n at D:\\home\\site\\wwwroot\\node_modules\\express\\lib\\router\\index.js:267:22\n at param (D:\\home\\site\\wwwroot\\node_modules\\express\\lib\\router\\index.js:340:14)"
}
}
where did you find this error?
when I did this:
less ~/myopenaps/autotune/ns-entries.2017-10-01.json
ok, so i'm right that downloading the glucose data (entries) from nightscout fails. something looks wrong at the nightscout side
@PieterGit If BG is falling, carb absorption might be picking up rapidly at the same time indicating that BG will soon start rising. It would not be helpful if OpenAPS did not bolus simply because BG is falling. This is only an example to illustrate that a simple logic of "Do not bolus if BG is falling" would do a lot of harm in other places.
@dmdfreak : what happens if you open the URL mentioned in the autotune output Query in a Brower: https://mynightscout.azurewebsites.net find%5Bdate%5D%5B%24gte%5D=1506834000000&find%5Bdate%5D%5B%24lte%5D=1506920400000&count=1000
https://mynightscout.azurewebsites.net isn't my nightscout. So maybe thats the problem?
that explains, i thought you changed it for gitter use
nope. But I don't understand how it would have changed. Also don't know where to fix it lol
I suppose
echo $NIGHTSCOUT_HOST has the same ns url
best is to change the URL in
~/myopens/oref0-runagain.sh and rerun that script to reinstall
that has the correct url
echo $NIGHTSCOUT_HOST had the correct URL
the wrong url is also in
oref0-autotune --dir=/root/myopenaps --ns-host=https://mynightscout.azurewebsites.net
perhaps you missed the line that you need to supply your own NS url :smile:
ummmm...... LOL
no comment LOL
This is what happens when you wake up and immediately do things you shouldn't be doing LOL
Amazingly, it works when you give it the right URL LOL Thanks @PieterGit
can you PR a change to make the URL indication in the docs more clear. I also noted that https://mynightscout.azurewebsites.net really exists, so perhaps changing it to the non existent https://FILL_IN_YOUR_OWN_NIGHTSCOUT.herokuapp.com makes it more clear :smile:
_> "message": "The _id field cannot be changed from {_id: ObjectId('59ea0951ac9277f77de06c72')} to {_id: \"59ea0951ac9277f77de06c72\"}.",
friggin' mongodb
I can give it a try. :smile:
@PieterGit We had some lows when using the new curves with a DIA of 5, but since using a DIA of 7 we do not see more lows than before
Sorry, DIA=6 is what we use
I am just setting up my rig, looking for some help troubleshooting... I bought the Explorer board (v1.3 2017) and Edison pre-flashed with jubilinux from Enhanced Radio Devices. I have the Edison mounted on the board and an Adafruit 3.7v battery supplying power. With the battery connected, the Edison starts to get warm and makes a faint clicking sound (seems like it is getting power). When I connect USB from my laptop (Win 10 x64) to the OTG port, nothing happens, it does not show up as a drive letter on my laptop. When I connect to the UART port, my laptop recognizes the serial connection (COM3) and PuTTy connects but nothing shows up in the terminal despite waiting and pressing Enter a number of times. Also of note, both the power and charging LEDs fail to illuminate on the board (with the battery and both USB ports connected). I have pressed/held the power button on the board multiple times for ~20s to no effect.
@c-robertson Are you very sure about COM3 or are there any other COM ports that show up in your Windows device manager? The drive letter never showed up for me, but that is not needed anyway. What happens if you remove the battery and connect the USB to UART?
Yeah, no other COM ports show up. In fact, when I unplug the 'Ports (COM & LPT)' section in the Device Manager disappears altogether. I have checked that Windows has the latest FTDi driver.
@scottleibrand : i noticed a PR or branch where you set the ns-glucose to the last cgm record. can you point me back to where I saw that? I can't find it anymore
@c-robertson Do you use a hub or connect directly to the computer? Is it a USB-C port? If you have a cable that comes with the Dexcom receiver, that should do.
@c-robertson are you sure you're using a proper USB cable. most short cables are power only
@drnoname82 Sorry, forgot answer you direct. With the battery disconnected, same diff.
@drnoname82 @PieterGit Tried multiple cables, some of which I know carry data. Also, tried the 1 USB 2 port on my laptop for connecting to the UART
@c-robertson So you have no lights on your rig at any time?
@drnoname82 Correct, no lights. Same with battery and USB charging block connected (no laptop connections whatsoever). Would expect to at least see charging light up...
@c-robertson Yup, does not sound like a USB cable problem. You should see some LEDs. Is the Explorer Board connected firmly to the Edison?
@drnoname82 So, I used the Sparkfun Edison HW kit, as recommended by the docs... Have it firmly mounted in the standoffs.
@c-robertson Puh, that sounds like a hardware problem with either Edison or Explorer Board. Do you have more than one Edison or EB?
@drnoname82 Just the one setup, trying things out for the first time. I have a 'ticket' in with the vendor by replying to their sales email from the order email I received. Not sure if anyone looks at those, it has been in for a week with no action. For all I know it is an automated email system and no actual humans are paying attention.
@c-robertson : did you check the COM device in the Windows device manager? I also once had an explorer board that failed in windows with communication, but when I connected it to a raspberry pi it worked, so if you have a unix system or mac around you might also test on that system.
@drnoname82 I'm new enough here that I don't know if others have had issues with Enhanced Radio...
i had good experience with enhanced radio with a defective explorer board before
@PieterGit PuTTy can see the COM port. If I try any random port, it gives an error.
check in Control Panel -> Search for Device Manager and look under Ports to see if you see a USB Serial Port
@c-robertson the battery and the edison get hot (that's okay), but in my experience I've never had an edison "click" -- not sure what's going on at enhanced radio, I've always had good interactions, had a board replaced before, no trouble
@PieterGit @thacherT1D How did you contact Enhanced Radio? I replied to my order confirmation, and ended up with a ticket in their Freshdesk online system.
i emailed with
morgan at enhancedradio.com (i also see mails to support at enhancedradio.com )
@PieterGit RE: the COM port, I have checked that. Start out with no COM ports, connect the rig, get one COM port (COM3) in Dev Mgr
you sure you use 115200 as baud rate?
If you never see any LEDs that definitely does not sound normal
@PieterGit Thanks for the email addrs, I will try support then bug morgan...
btw my edisons also never "click" (except for when i place them in an explorer board)
@PieterGit Yes on baud rate. In Dev Mgr, right click on COM port and check port settings. I used those to match up setting in PuTTy
@c-robertson @PieterGit same ones I used -- I would for sure try support over sales
ok, think it's an hardware issue. with windows rebooting the system to restart the usb subsystem also sometimes fixed my problem, but I don't think it will fix yours
@PieterGit Note the click is very faint (need to hold it up to my ear to hear it). I was just looking for any indicate that power was flowing...
@PieterGit @thacherT1D @drnoname82 Thanks everyone. Feel like my suspicions are confirmed. Will try the support contacts at ERD.
Am I right that if I want to test new prediction features, I should move to rendering branch of NS?
@PieterGit @drnoname82 regarding my suggestion to disable SMBs on a downward trend, I agree should not be a mandatory thing. I would still like to see it as a preference setting. In my microbolus-based home-made APS algorithm which I used prior to switching to OpenAPS, it was a key safety setting. I had implemented it a few months in after some hard lessons wherein I had allowed the algorithm to microbolus on a downward trend, either due to COB or due to wildly insufficient IOB to reach the target. Despite the microboluses on a downward trend being very conservative, I ran into hypos on occasion. I think the reason is the algorithm could never know about everything, for example if I accidentally forgot to report some unplanned physical activity (i.e. running like mad from a tram station to a train platform).
@Diadon81 : the NS branch is for viewing it in Nightscout, you can also use the new prediction features without upgrading NS, but you won't be able to see the new lines
One way SMBs on a downward trend are less risky with OpenAPS than they were with my algorithm is that my algorithm didn't do any automatic sensitivity detection. So there is definitely a case that they are safer with OpenAPS. I just don't know about the unreported exercise case.
@andrew-warrington : i think that openaps algorithms should not require to always require setting excercise mode. An occasional short sprint from tram to train should not require exercise mode / setting a high temporary target
@PieterGit currently I am on master branch of Nightscout, should I switch to rendering branch to get this new lines?
There are two pull requests for NS currently nightscout/cgm-remote-monitor#2926 and nightscout/cgm-remote-monitor#2919 . As far as I know they are currently work in progress. At least the changes cause the NS tests to fail. Perhaps @scottleibrand can give an update if the PR's are ready to test.
@PieterGit I agree. I guess the question is, how big is the risk? I am not tuned in to the discussion well enough to know whether unreported exercise has ever been discussed or has been seen to be a problem by the community (with or without the SMB topic).
Unreported exercise certainly is a challenge, but the influence OpenAPS has on a sprint from tram to train is virtually zero. BG during this sprint would mostly be determined by the IOB when starting the sprint. Of course I would not mind an option to disable SMB on donward trends, but I think this is most likely not the fix to the causal problem that OpenAPS thinks you need insulin while in reality you don't
@drnoname82 @andrew-warrington : i think what we need is a good/minimum set of SMB settings and a good description on how to use them and how to change them. I like the
maxSMBBasalMinutes because it's clear what it does and is powerful. Perhaps we should implement enableSMB_with_falling_bg as a non exposed preference in preference.json and let it be only set it default to true if the all other enableSMB's are set to true. Docs now suggest "You may want to experiment with turning only one of them on at a time so you can closely observe the behavior (via both Nightscout and pump-loop.log) in the enabled situation." .
@PieterGit @andrew-warrington Disabling SMB simply becauseBG is falling right now pretty much disables the entire prediction logic of OpenAPS. So I think this should by no means be a default. Also I do not see why we should be required to set e.g.
enableSMB_after_carbs in order to allow SMBs during falling BG. I think we should focus on identifying why OpenAPS wrongly gave insulin, be it as SMB or as high temp. An option is fine, but it should not be default or conditional.
Hi. Is it possible to reset the IOB? My son is honeymooning yet (he secretes enough basal insulin sometimes). For this reason, sometimes openaps computes negative IOB and predicts to rise high
I need to reset to zero in that situations, because he really doesn't need that negative insulin
@PieterGit "disabling SMB when BG is going down or one of the projected predicted BG's is a hypo" is what the new minGuardBG does. Can you take a look at that and see if that does what you'd want?
@PieterGit "i noticed a PR or branch where you set the ns-glucose to the last cgm record." - how recently was that?
@PieterGit @Diadon81 those PRs are good to test. Not sure what's up with the unit tests: if anyone can debug that it'd be appreciated. They don't seem to affect normal operation though at least the way we use NS.
@jcwarrior I would manage that with a temp target to start with. Are you saying that he is getting natural insulin OpenAPS doesn't know about, so it's then giving too much extra and he's ending up low? If so, an activity mode would counteract that, especially if you have exercise mode enabled.
@scottleibrand : i thought i saw a jq statement and a
touch on ns-glucose.json, but can't find it in the branches / PR's anymore
max temp target is 200 and is not high enough to OpenAPS stop basal infusion. He secretes insulin.... ones days much another days almost nothing. That make more dificult to get a perfect config for OpenAPS. Yesterday I had to put actual basal multiplicator config to 1
the only solution that has occurred to me is to reset the insulin on board, but I'm afraid that's not possible because I suppose it is calculated from the insulin infused by the pump
Right. Other option would be to unattach pump, do small bolus into pump to match iob to 0, reattach. However, that may ultimately cause more low temping that is unneeded later.
Thank you @danamlewis and @scottleibrand . I'll try that next time. My child is having diarrhea these days and needs very little insulin :worried:
:/ hope he feels better soon
@jcwarrior if you enable exercise mode in 0.6.0-dev, that will make high temp targets adjust the sensitivityRatio, making them much more effective for that situation (to the point that a 140 might be sufficient).
There is also an option to allow autosens to adjust IOB calculations the same way exercise mode does, which will allow the system to do this automatically if it's detecting sensitivity with autosens.
Also check whether your autosens is hitting the minimum from preferences, and consider lowering that if so.
thank you @danamlewis We are on 0.5.2 yet. Is 0.6.0-dev stable enough? We have autosens off. He is very very high sensitive (800 sometimes....) and I prefer to manually do the ISF changes
How often do others find that they have to use
ccprog to reflash the radio chip on the Explorer Boards? We have 2 Explorer Boards, both less than 3 months old, and both had to be reflashed twice. Is that normal?
Ooh. I would at minimum update to 0.5.5. Since you're watching closely, I think 0.6.0 dev would be worthwhile given some of the new features there
OK Dana. Yes, we watch closely anything :smile: I'll try to update 0.6.0-dev. I'm interested on exponential curves too
Pump loop fail after enabling SMB/UAM. I have checked the 3 troubleshooting steps in the docs & all seem ok. Have current bg data in nightscout. What am I missing?
What is recommended between using Loop or openAPS?
@nicked22 it depends, see e.g. http://seemycgm.com/2017/09/02/loop-vs-openaps-update/
@nicked22 a lot of it is usability preference. Beyond that - there should also be algorithm and feature set preference. Pros and cons to each.
Tim also has some good comparisons: http://www.diabettech.com/looping-a-guide/ and some other posts
Which one allows me to adjust the code of the algorithms more easily?
Code? Depends on what languages you know. If you're talking about tweaking feature values and preferences how you want them from the defaults - they're about the same.
95% of people on both don't end up adjusting the code itself.
For example, for OpenAPS, here are the preferences and settings you can adjust/ http://openaps.readthedocs.io/en/latest/docs/While%20You%20Wait%20For%20Gear/preferences-and-safety-settings.html#
@scottleibrand : found it, the optimize branch, openaps/oref0@7dd8def
@WeedsDIY are you running Autotune?
Also, can I see more of your pump log?
Yes on running autotune as part of the loop.
@danamlewis Been running pump log a long time. How much do you want to see? Or is there something specific your want? Provided a single loop attempt.
Ran autotune on the last three weeks while using bilinear curve. Then switched to rapid-acting curve and ran it again. Very little difference between the 2. @scottleibrand but switching back to bilinear made a big difference in how my numbers are doing. Took me to mid 80's and is holding steady. No lows. Also showing very little negative IOB. I will switch back to rapid-acting and lower SMBBasalMinutes to 20 and see if it still goes low.
Tomorrow
@danamlewis Just restarted Putty and pump-loop.log. This is the first listing of info... root@sshrootrigmaroll:~# tail -F /var/log/openaps/pump-loop.log
{"carbs":0,"boluses":2.5,"mealCOB":0,"currentDeviation":null,"maxDeviation":0,"minDeviationSlope":0}
BG data is too old (it's probably this), or clock set incorrectly. The last BG data was read at Sat Oct 21 2017 13:36:20 GMT-0500 (CDT) but your system time currently is Sat Oct 21 2017 16:05:29 GMT-0500 (CDT)
"reason": "BG data is too old (it's probably this), or clock set incorrectly. The last BG data was read at Sat Oct 21 2017 13:36:20 GMT-0500 (CDT) but your system time currently is Sat Oct 21 2017 16:05:29 GMT-0500 (CDT)"
Checking system clock against pump clock:
Checking deliverAt: null is within 1m of current time: Sat Oct 21 16:05:30 CDT 2017
date: invalid date ‘null’
SMB pump-loop failed. pump_loop_completed more than 15m old; waiting for 30s silence before mmtuning
Radio ok. Listening: .No pump comms detected from other rigs
Listening for 30s silence before mmtuning: .No pump comms detected from other rigs
mmtune: "916.516", 5, -81 waiting for 42 second silence before continuing
{"carbs":0,"boluses":2.5,"mealCOB":0,"currentDeviation":null,"maxDeviation":0,"minDeviationSlope":0}
BG data is too old (it's probably this), or clock set incorrectly. The last BG data was read at Sat Oct 21 2017 13:36:20 GMT-0500 (CDT) but your system time currently is Sat Oct 21 2017 16:05:29 GMT-0500 (CDT)
"reason": "BG data is too old (it's probably this), or clock set incorrectly. The last BG data was read at Sat Oct 21 2017 13:36:20 GMT-0500 (CDT) but your system time currently is Sat Oct 21 2017 16:05:29 GMT-0500 (CDT)"
Checking system clock against pump clock:
Checking deliverAt: null is within 1m of current time: Sat Oct 21 16:05:30 CDT 2017
date: invalid date ‘null’
SMB pump-loop failed. pump_loop_completed more than 15m old; waiting for 30s silence before mmtuning
Radio ok. Listening: .No pump comms detected from other rigs
Listening for 30s silence before mmtuning: .No pump comms detected from other rigs
mmtune: "916.516", 5, -81 waiting for 42 second silence before continuing
@WeedsDIY how do you get CGM data to the rig?
@dmdfreak that means likely you've been compensating with basals for the old curve, so switching to the new curve likely means dia and basals need adjusting. What dia are you using for each?
@scottleibrand : can i branch the optimize branch for improving and finishing openaps/oref0#528 , or should i wait until scott-dana-dev has been merged to dev
Start with optimize :+1:, scott-dana-dev will never be merged to dev. It's where we test a collection of PRs and some not-yet-branched changes
DIA is set to 4 in the pump. I tried switching to 6 per Scott's suggestion yesterday, but it still continued to take me low. I also ran autotune with the rapid-acting curve enabled expecting basals to adjust but there was almost no difference in suggestions. @danamlewis
@danamlewis The way I am understanding it to work, G5 transmitter (attached to body) sends data to receiver (in this case a Samsung S7, running Dexcom G5 Mobile app), the data gets uploaded to Clarity and Nightscout links to Clarity for info. Rig pulls data from nightscout via internet connection. I can see the rig listed as an active device on my internet router, so reasonably confident rig has internet connectivity. Can see uptodate BG data in nightscout from the dexcom side. Just seems to be a connection in rig talking to NS.
@dmdfreak : do you use multiple ISF or CR? I also ran into lows. I changed to single ISF and CR and currently using DIA 5.
thanks @danamlewis . I'll branch of the optimize branch
@WeedsDIY correct flow. Yes, seems like a rig-NS issue
@danamlewis Ideas on how to get comms re-established? Last time this happened we had to make a new NS setup.
Single ISF & CAR @PieterGit
CR ... auto fixed it for me LoL
@WeedsDIY azure or heroku?
Shouldn't require a new site. May need a dynos restart or something
heroku
Try restarting dynos
@dmdfreak : ok thankx. if you use SMB I had was able to prevent some hypo's by limiting
maxSMBBasalMinutes to 20 before my ISF/CSF/DIA was tuned.
@PieterGit Per your suggestion earlier, I was going to try that tomorrow and see if it helps.
@thacherT1D per tweet, see
offline branch.
Not documented at all yet though
Related: we have lots and lots of stuff that needs documenting. If you're testing a dev or pre-dev feature...please help us make notes and or docs for them.
#needmorehands #andhoursinaday
^ that's for everyone here :) where you = anyone reading! :smile:
@danamlewis : enough hours in my day already... I'm off. Did some Nightcout stuff today, and hope to work on oref0 the coming days again
thanks @danamlewis tracking my steps as I go :smile:
:+1:
@danamlewis to test the offline branch -- best method would be to setup a new rig pulling from that branch, yes? could I use the values from my runagain.sh too?
@scottleibrand what version of jubilinux have you been running?
0.6.0 was merged into Master now.? What's in dev?
ugh, I migrated to heroku and now I'm getting that "The _id field cannot be changed from..." error again :\
@danamlewis We had to learn a bit about what a dynos was. Got that sorted and then restarted them, but still running into problems with rig. Same sort of issue. A loop attempt starts with "Starting supermicrobolus pump-loop..." Then several minutes later we get SMB pump-loop failed. We have attempted this a few times and it still appears that BG is not getting pulled from NS. Anymore ideas?