@PopcornPam_twitter as long as you were already running dev before that should be all you need
@danamlewis Missing from the notes about 0.6.0... how to change the pushover alerts to only alert you to a certain amount of carbs required?
Is bilinear the proper curve for Humalog?
(Trying to find the link for the Dev notes, can't find it)
@YYCMichael testing that fix on the bluetooth now. Will let you know how it goes. Does look like a BlueZ change though. I suspect that the only thing that really needs changing is replacing the bluetoothd launcher line with this one
sudo /usr/local/bin/bluetoothd --experimental
@PopcornPam_twitter yeah, that means you're up to date. you can watch the oref0 repo on github.com if you want to get email notifications when we merge new stuff to dev
@scottleibrand Had my first test of enhanced SMBs in dev 0.6.0 yesterday. Absolutely amazing to watch how it handled it and got it smoothly back. No overshooting! I only gave my carb count when starting to eat. Congratulations on what seems like a very successful implementation. Question is, what consequence does it have to give inaccurate carb counts? Too low estimate? Will it affect autosense/autotune? You mentionend a new way of carb counting?
@PieterGit Hi Pieter, before Sulka coded the GVI and PGS parts of the NS reports, I had suggested the "mean total change" metric, which is an sum of all the absolute 5 min deltas in every 24 hours. PGS is very dependent of the target range, as you probably already noticed... Any comments about those various variability parameters ?
@YYCMichael - that Bluetooth fix doesn’t seem to have worked for me. May require me to go back to the drawing board.
And reflash...
I never PRed sonmething I changed locally but this should change. I did a modification of src/oref0/bin/openaps-install.sh. I thought like getting the changes with git pull I can push my changes up to get them into the community version. But that won’t work and I think I have some basic lack of git knowledge. Can someone assist me?
@CaptainBalou if you make a pull request @scottleibrand and @danamlewis will see it so if you find that section of the code on github and modify it the same way you did, and follow the directions on how to make a pull request they will review it and add it. If not they normally say why it was not added http://openaps.readthedocs.io/en/latest/docs/Resources/my-first-pr.html?highlight=pull%20request
read that link and just follow the instructions, it is very easy. Just adding your name to a list
Hi Dude. I see this on pushing:
root@captainsloop1:~/src/oref0# git push
fatal: remote error:
You can't push to git://github.com/openaps/oref0.git
Use https://github.com/openaps/oref0.git
root@captainsloop1:~/src/oref0#
fatal: remote error:
You can't push to git://github.com/openaps/oref0.git
Use https://github.com/openaps/oref0.git
root@captainsloop1:~/src/oref0#
I read this link but I cannot see any cli commands in there. I reread it...
I searched for „push“ but had no hits.
it is all done on the webpage (from what I remember checking the link myself now)
On the webpage? Really? Oh dear. So copy&paste session… :-D
lol or just change the section you changed?
how much code did you change?
Not much. A few lines. But it would be so easy to just enter „git push“ and everything gets done automagically.
yeah but I am no help to you doing that at (sadly)
I am still TRYING to learn the basic code (javascript) along with how github works
Me too. And I still hope someone jumps out of a corner and says „it works with git push as well…just do this or that…“ ;-)
Probably just an issue of git:// instead of https:// urls. But I don’t know. Still wating for the one jumping out of a corner...
sorry man I got stuck on a call still on that call :(
@CaptainBalou to do it "properly" from the CLI without copy-paste you'll want to clone the repo, set up your own repo as your git remote on the rig, push to there, and then PR.
sorry if this has been asked -- couldn't find any info but I'm on NS 10.0 and for some reason my purple (openAPS) forecast line as showing up in the past. Is this something on my end or..
Did you check your NS site and make sure it didn't get unchecked
Ie check the three dot drop down; also check your settings and make sure show forecast is checked
thanks Dana.. I did do all those things.. funny part is (read murphy's law) it's now displaying as normal yet all morning has been showing the "forecast" in the past despite several refresh and typical fix-it maneuvers...go figure once I post this question...
:smile:
@cameronrenwick usually I see that when the rig with the last enact hasn't uploaded its NS data yet. it usually self-resolves once it runs through another clean loop and uploads its results
yup I think that's what it was...I had really flaky wifi this morning... would have been a lovely pie crust (flakey!)... all better now...
Hi guys! Just a quick question: We are on Apidra ATM and using the previous dev w/l
w/o problems. If we were to change to the current Dev and the new Insulin Action curves, is there anything I need to think k about? Current DIA 3.5-ish. Just cahnge to DIA 5?
*change
@Mackwe For what it's worth, I didn't really have to change anything other than what I specifically wanted to change when I did the dev upgrade
But curves weren't one of them
@jaylagorio No, I know I can just run a new Dev version over the current one. I was more asking if there is anything I should change or think about when going from the bilinear algorithm to the "correct" curves?
Ah, I get it now. And I should have been more correct when I said the curves wasn't one of them - specifically I didn't use the Fiasp curve, but I did use the Novorapid curve instead of bilinear
Let me double check one thing real quick
So full disclosure, I missed a line in here: openaps/oref0#650
I didn't set the DIA on the pump so although the curve was set it may not have been having the intended impact - although I will say I've been having really good results with just meal announcements
if you just change the curve in preferences and don't set a higher DIA on your pump, it will use a DIA of 5 hours. you can and should try higher DIA if you ever see BG trending low a few hours after a large meal with lots of boluses: it won't affect the loop's activity around the peak time (45-90m) and will just cause it to be a bit more conservative to prevent lows 3-6 hours afterward.
Oh, that's good then
woohoo I have gone 2 for two expanding (ruining) my 3.7V, 2000mAh, 5C LiPo Batteries. I have a new battery on the way, dont think that is going to happen when my new Lithium Ion Battery Pack - 3.7V 4400mAh battery gets here.
ugh. do you know what triggered it?
Yikes
I think over charging both times I left it plugged in and came back to a much thicker battery on my bed side table
dont understand though because I thought that the boards cut off when the batteries got full
this last time I left it charging for like 14 hours so I take the blame
yeah, the charging circuits are designed to prevent overcharging. shouldn't matter how long you leave the rig plugged in for, it won't keep charging them that long. I leave ours plugged in for weeks or months
more likely it'd be physical trauma that would trigger that (not necessarily right away)
that is likely then, when I use those batteries I do not use cases
and I have two 3 year olds and a 4 year old at our house
we have our batteries wrapped in a taped-on business card to prevent punctures, and then the whole thing goes in one of Dana's tallygear soft cases
yeah I think I may use protective foam along with the neoprene case I just got.
Are many people just inputting carbs into their NS site now for larger carb meals like ... A hamburger (using FIASP) I have done this with lower carb items 46 and below but have been scared to go higher
My highest is also 45 but I'm hoping to try around 60 this evening to see how it looks
yeah, my BGs are actually more stable when I don't bolus and just input the carbs using night scout.
Right!?
Dana has been successfully doing no-bolus (carb entry only) on meals up to 90g+ of carbs for several weeks now. we're now using some slightly more aggressive tweaks that haven't yet been merged to dev (like openaps/oref0#683)
@scottleibrand If 5 hours means peak between 45-90 mins, that would be spot on. I'll just go ahead and try it then! :-)
@scottleibrand yup that is why I wanted to update today I have been reading the chatter but have one broken battery :(
@scottleibrand I took a look at that one the other day, if you wanted to merge now I'll update when I go home before dinner
ok, Dana just gave me a verbal :+1:, so that one is now merged
Awesome!
@Mackwe the peak is configurable in preferences.json. it defaults to 75m for rapid-acting and 55m for ultra-rapid, which seem to work well. changing DIA doesn't change the peak time, just the width and length of the subsequent tail
@scottleibrand Oh, I see! That sounds fair. I'll just change the time to slightly less and go for it then. No need to change anything else?
I would recommend setting the curve to rapid-acting (or ultra-rapid for fiasp), watching that, and then extending pump DIA to 6h or 7h after you spend some time watching how it behaves at 5h. I haven't seen anyone who really needs to override the peak time: I think there's one parent who did so, but I'm not sure if he measured any further improvement as a result: the defaults are really good there and probably don't need to be changed.
@scottleibrand Noted. Will try defaults then. Thanks!
@CaptainBalou to do it "properly" from the CLI without copy-paste you'll want to clone the repo, set up your own repo as your git remote on the rig, push to there, and then PR.
Thanks Scott. I understood. So I can send my changes up to my repo. But then I have to PR those changes again to the community, right? So I cannot get around using the github website, correct?
You can do it from the website, too, same idea - fork, make edits in your fork, submit the Pr. Sometimes I find web easier but if you've made the changes on command line, might be harder. Depends on what feels easiest to you.
Easiest for me would be changing it on my rig, using a command to get it to the approval process. But I don’t thing this will work. But don’t think further about that. I am just able to change so bash scripting work. So I don’t PR a lot.
That will work, if you have initialized yours as a git repo forked or cloned from the community's
Since the pebble isn't sold any more, is there another smartwatch known to work with the edison rig?
But if that didn't happen somehow on the front end, that's when it can get gnarly
@regdubbed you can still get Pebble's
And still what most of us would recommend
just as a follow up to the peak time and Fiasp, I've left my peak at 55(default) and my dia at 5 with eSMB set a 60 min. I thought that would be a good "start" but several days in it's working like a trooper... as always YDMV but for me.. this is a good arrangement. Will certainly report when I get a few weeks in
:+1: thx for continuing to share
@danamlewis Hmm, ok. My git knowledge is low. So I decided to change the few lines directly in the website and if I want to have it more comfortable in the future I think I’ll have to dive into GitHub to understand how thing work.
Ok, then it will be a pebble... Thanks
@CaptainBalou you can do pulls, merges, and pushes all with command-line git if you have permissions on the repo you're working on. pull requests are a github.com thing, though, and I don't know of any CLI way to do those
Confusing. :-) I am good in computer networks but will never get a professional coder in this life. ;-)
Is there an easy way to try out my rig (open loop) on Nightscout data? I mean look at what the loop proposes and see if that makes sense. Would give me a better feeling than just going live...
@CaptainBalou that's what I said 3 years ago when I started learning python and js to do DIYPS and NS stuff
No no no, don’t try what I see you want to try! :-D
(Data comes from a 640g at the moment, rig will use a veo)
@regdubbed just do your rig with the CEO pump and it not connected. Or you can set it to be % temp mode so you can see Rec's without it setting temps
But might be easier to monitor it with setting the temps on the non connected veo and you visualizing it on NS
Not sure if I get it... You mean not connect the CGM on the Veo?
your rig would get the CGM data from NS and set temps on the Veo
I don't think your 640 CGM works with the veo anyway
^ that.
Sure. Thats why I want to try it before swirching pump/CGM/everything ;)
Right. So, set it up to talk to the Veo when it's not connected to you. Get CGM data from NS (via the 640h
I can't remember if it was @Bal00 or someone else also doing the 640 CGM source, whoever that was may have some tips
Ok, that means, when my rig is unable to get CGM data from the Veo (because I disconnected the transmitter), it will automatically pull data from NS?
assuming you enter your NS URL during setup, yes
Sounds good, I'll try that right now
eSMB is working great for me so far. I haven't had to bolus for a meal for almost 2 full days now. I do have one question though. My blood glucose was 82 and it's been probably a week or two since I've had a low glucose value (which is incredible by itself) so I felt just a tad on the low side and ate a granola bar and immediately logged the 22grams of carbs. eSMB then immediately gave me over 1 unit total worth of SMB's which caused a slight dip further. In this case it wasn't a problem, but I'm wondering with eSMB should I not announce rescue carbs?
Anecdote for you - I don't announce rescue carbs and it's been OK
But my rescue carbs are like 5g
That's when looping, when not looping it can be as much as 15g
With new Autotune in dev, you'll want to log carbs so it doesn't tune rescue with meals. But you can set a one point higher than normal temp target to block SMB's.
Also which version of dev are you on? Absolute latest? We are adding in some threshold stuff to make sure won't SMB when minBg below 70, so make sure to grab a fresh dev if it's been even a few days
Creating iftt buttons for a rescue carb amount plus a slight high temp target (say 110 instead of 100) is handy for this.
Hi All, question re autotune: the log from last night shows
mealCarbs at zero at around 11:30 am, and then the carbs from every meal are added to mealCarbs until it hits 209 and stays there until midnight. It looks like the mealCOB never hits zero before the next meal so all of the meals coalesce into one. Does this mean that autotune only tunes CR over this time (11:30 to midnight)? Is this the expected behaviour? Our kid's meals weren't particularly close over the day. There were also a few periods of lost data overnight (Dex question marks) - would that play havoc with the autotune algorithm?
@efidoman what Dana said. But also, even Fiasp isn't that fast: any insulin you dose won't have a noticeable effect on blood sugar for at least 30m, and longer for smaller SMBs. so if you were still drifting down after doing rescue carbs, it was for the same reason you were drifting down before doing them.
@scottleibrand I think we just encountered an error in dev: OpenAPS did not SMB as expected because
IOB 4.89 > max_iob 4The IOB amount was correct, but those were manual boluses and there were no SMBs and hardly any high-temping in the hours before. From my understanding max_iob should still only take IOB from high-temping and SMBs into account.
@drnoname82 we changed that behavior: with eSMB it's hard to reliably distinguish manual boluses from SMBs, so we stopped trying, and now use total IOB to compare against max_iob
that may mean you want to raise your max_iob value to give eSMB more room to work. Dana ended up raising hers by 50%
the other reason we changed it was because she's doing no-bolus now, so there literally aren't any manual boluses in that scenario.
@scottleibrand Ok. I understand the problem, but that makes max_iob relatively powerless as a safety constraint. I am still somewhat worried about our recent problem with the sudden way too high BG readings from the G5. In that case max_iob would have prevented a very serious incident. Now this is not the case anymore.
Would it maybe make sense to automatically change max_iob relative to the amount of COB?
when COB is fully covered it disables maxSMBBasalMinutes-sized larger boluses and drops down to 30m-basal-sized ones
and when BG rises significantly, it counts that as carb absorption, which reduces COB further
what was the pattern you saw with the too-high readings from the G5? was it a sudden spike up? did it come back down quickly? remain elevated but flat?
Yes, but still 30m-basal-SMBs every 5 minutes in the middle of the night would be a disaster had they gone unnoticed
we also recently added a check that will disable SMBs when BG delta is > 10%, so a sudden spike up from a noisy sensor or calibration jump won't result in too much overreaction
if you don't want SMBs in the middle of the night, you can disable the enableSMB lines that allow it
for example, only allow it to run as long as COB > 0 or a low temp target is running
It was a perfectly reliable sensor that went from normal values to 300something from one reading to the next and stayed there
how long did it remain elevated?
We fortunately woke up to the alarm and swapped the sensor after a few readings. It had no tendency to come down. Serum BG was normal and stable
surprised it didn't go to ???
usually the dexcom algorithm is pretty good about detecting readings that it doesn't trust and switching off until the sensor settles out
any acetaminophen involved?
and how old was the sensor?
My worries are not about the SMBs, more about the "loss" of max_iob as a safety constraint against whoknowswhat. The wrong reading was on Xdrip+, the noise level was high all of a sudden and I am sure the Dexcom algorithm would have prevented this incident.
Nope, no acetaminophen, true sensor problem. Day 6, first problem of this sort in several years of using Dexcom sensors.
ah, yeah. I really dislike the way xDrip+ is missing so many of the safeties in the official Dexcom algorithms
I would prefer to fix this in xDrip+, and have it not report high-noise readings as SGVs (but still report them as raw)
- @danamlewis - nice advice about ifttt button for "rescue carbs" including a one point higher than normal temp target. That is good to know. I did a pull of dev on Sunday morning at 7am ET.
also keep in mind that you don't have to raise max_iob. it is actually more conservative now, and will set a neutral temp if you've already bolused enough for the meal, until IOB comes down below max_iob. if you can't use the official Dexcom app and have to use a less-trustworthy DIY solution, you may not want to give oref0 a higher max_iob to allow it to fully dose for meals, and continue to do that manually, until you or someone can improve the xDrip+ app to appropriately use noise levels to decide what to report as SGVs
Yup, that is an issue in XDrip+. But with all the Libre-to-CGM-solutions etc. I still wonder if there might be a way not to "give up" max_iob.
I wonder if we should put some code into oref0 to disable SMBs on unreliable CGM sources like xDrip+, Libre, etc.
I talked to @jamorham about the SGV/raw issue. I think I will also open an XDrip+ issue.
yes, please do. if you think it'd help, I'll be happy to comment on it that I think it's an important safety issue and am considering workarounds to disable oref0 features for xDrip+ users if it can't be fixed there
I've experienced some very rare glucose readings over 1000 from what must have been a bad dexcom sensor or a g5 transmitter battery that needed changing. The 10% threshold in the code would have prevented an SMB for such a rise. However, I went into the xdrip-js rig code that I'm using and put in thresholds to ignore out of range glucose values from the g5
@danamlewis - is it possible to do two json posts with a single ifttt button push?
Puh, that makes me really consider going back to the Dexcom app until it is fixed. That was our first ever problem with XDrip. I think the OpenAPS safety constraints are perfectly fine as long as BG data is reliable. Would it be hard to let OpenAPS differentiate between "manual/basal insulin" and "OpenAPS insulin"? That would make max_iob more useful as a safety constraint and those relying on OpenAPS to cover their entire meal insulin could simply allow more "OpenAPS insulin"
yes, it is impossible to reliably differentiate a manual / easy bolus from an SMB of the same size.
we can differentiate bolus wizard entries, but I don't really want to design safety features that not everyone can rely on
@efidoman you don't have to do two json posts. they can be combined like this:
{
"enteredBy": "DoButton",
"eventType": "Temporary Target",
"reason": "Low Treatment",
"carbs": 5,
"targetTop": 110,
"targetBottom": 110,
"duration": 45,
"insulin": null
},
@efidoman also FWIW, the SMB rise threshold is only on the 5m delta: if BG remains elevated, it can still SMB if that's warranted based on the higher (but no longer fast-rising) values.
"iob above basal and bolus wizard" sounds like a useful constraint to me. I understand it is not an absolute safety constraint, but still a description of what I would want to allow OpenAPS to do.
But of course this is mostly a BG data quality issue. I will open the XDrip issue tomorrow and let you know
As we were talking, OpenAPS safely brought her BG back in range ;) This is amazing, thank you so much!
@drnoname82 per openaps/oref0#685 I'm moving in the other direction, toward eliminating all bolus vs. basal distinctions for purposes of oref0 dosing decisions. I'll probably re-add some reporting functionality for people who want it, but at this point am unlikely to reverse course on what we compare against max_iob, as any heuristic I can think of is less safe than simply comparing net IOB (from all sources) against max_iob
@scottleibrand - I have not experienced a g5 system giving high BG consistently. Only one sensor giving a single very high > 1,000 number on a few rare occasions then immediately back to normal the next 5 minute update. I have experienced a g5 issue where the sensor filament was bad (i.e. kinked or something) and it gave consistent low numbers when BG wasn't low. I would not suggest disabling SMB for dexcom sensors as they are the most accurate out there in my opinion. I do think that doing SMB's on something like Libre would be very dangerous because I found the Libre sensors to be wildly innacurate in both directions with consistent innacuracy.
thx, good feedback. I'm not sure if it's worth changing anything in oref0 at this point, but it might be good to put in some notes into the SMB docs explicitly recommending that people looping with Libre not use SMB. If any of you agree, a PR to that effect would be most welcome.
@efidoman there's an example of how to do the carbs plus target in the list of examples for ifttt targets
any chance someone can check my cat-pref file? It seems to cause a few hiccups and I "think" it's ok but...
{
"max_iob": 6.5,
"max_daily_safety_multiplier": 3,
"current_basal_safety_multiplier": 4,
"autosens_max": 1.2,
"autosens_min": 0.7,
"rewind_resets_autosens": true,
"autosens_adjust_targets": true,
"adv_target_adjustments": true,
"maxCOB": 120,
"override_high_target_with_low": false,
"skip_neutral_temps": false,
"bolussnooze_dia_divisor": 2,
"min_5m_carbimpact": 8,
"carbratio_adjustmentratio": 1,
"autotune_isf_adjustmentFraction": 0.5,
"remainingCarbsFraction": 1,
"remainingCarbsCap": 90,
"unsuspend_if_no_temp": false,
"maxSMBBasalMinutes": 60,
"enableSMB_with_bolus": true,
"enableSMB_with_COB": true,
"enableSMB_with_temptarget": true,
"enableUAM": true,
"curve": “ultra-rapid”
}
"max_iob": 6.5,
"max_daily_safety_multiplier": 3,
"current_basal_safety_multiplier": 4,
"autosens_max": 1.2,
"autosens_min": 0.7,
"rewind_resets_autosens": true,
"autosens_adjust_targets": true,
"adv_target_adjustments": true,
"maxCOB": 120,
"override_high_target_with_low": false,
"skip_neutral_temps": false,
"bolussnooze_dia_divisor": 2,
"min_5m_carbimpact": 8,
"carbratio_adjustmentratio": 1,
"autotune_isf_adjustmentFraction": 0.5,
"remainingCarbsFraction": 1,
"remainingCarbsCap": 90,
"unsuspend_if_no_temp": false,
"maxSMBBasalMinutes": 60,
"enableSMB_with_bolus": true,
"enableSMB_with_COB": true,
"enableSMB_with_temptarget": true,
"enableUAM": true,
"curve": “ultra-rapid”
}
Curvy quotes. Fix the quotes to be straight quotes
On ultra-rapid
Do you remember @danamlewis , we searched two hours in my rig. :-)
;)
thx! funny I actually just used the same quotes but exchanged the word within from when I updated to 0.6.0 dev non git... could those curvy quotes be in the update perhaps?
On a plane with super bad wifi that keeps eating half my replies, so I vote you check :D and see
Shouldn't be, but worth checking
Also check the 0.6.0 Pr and let me know if it's got curvy quotes in the verbal example? Can fix that later if so..
when I look at it on terminal the quotes are straight... I wonder if as I cut/paste my perfs to a word doc that maybe word has done this... I'll edit the pref tho just to be safe...
Yea. If you copied and pasted over that likely did it
If you're on a Mac you can change default to never do curvy quotes when pasting
k here it is again with the edit done straight into pref... (no cut/paste to word etc). Sorry for this again but it's the only way I can check as terminal looks like straight quotes for both...
{
"max_iob": 6.5,
"max_daily_safety_multiplier": 3,
"current_basal_safety_multiplier": 4,
"autosens_max": 1.2,
"autosens_min": 0.7,
"maxCOB": 120,
"autosens_adjust_targets": true,
"bolussnooze_dia_divisor": 2,
"min_5M_carbimpact": 8,
"carbratio_adjustmentratio": 1,
"autotune_isf_adjustmentFraction": 0.5,
"remainingCarbsFraction": 1,
"remainingCarbsCap": 90,
"rewind_resets_autosens": true,
"adv_target_adjustments": true,
"unsuspend_if_no_temp": false,
"enableSMB_with_bolus": true,
"enableSMB_with_COB": true,
"enableSMB_with_temptarget": true,
"enableUAM": true,
"curve": "ultra-rapid",
"maxSMBBasalMinutes": 60
}
"max_iob": 6.5,
"max_daily_safety_multiplier": 3,
"current_basal_safety_multiplier": 4,
"autosens_max": 1.2,
"autosens_min": 0.7,
"maxCOB": 120,
"autosens_adjust_targets": true,
"bolussnooze_dia_divisor": 2,
"min_5M_carbimpact": 8,
"carbratio_adjustmentratio": 1,
"autotune_isf_adjustmentFraction": 0.5,
"remainingCarbsFraction": 1,
"remainingCarbsCap": 90,
"rewind_resets_autosens": true,
"adv_target_adjustments": true,
"unsuspend_if_no_temp": false,
"enableSMB_with_bolus": true,
"enableSMB_with_COB": true,
"enableSMB_with_temptarget": true,
"enableUAM": true,
"curve": "ultra-rapid",
"maxSMBBasalMinutes": 60
}
interesting...now the quotes are straight... hmm.. may be worth a note
TBH wish we could automate wrong quote shape fix
Here's a way to check for them, even if your terminal font doesn't distinguish them:
$ iconv -f ascii -t ascii
<paste text to be checked here>
CTRL-D
You'll get an error message if there are any non-ASCII characters
ya not too sure if that was simply a word thing (and therefore didn't have any impact on what my rig was doing) or if it did indeed cause some problem. I know that when I updated to 060 dev I merely back-spaced the word within the quotes and exchanged it for ultra-rapid.... weirdness ..
thanks Eric! great tip!
@ecc1 wondering about adding that somehow as an autocheck tho? Possible?
(And either flagging as error, or being able to autofix..)
Yes, you can run that command on whole json files, redirect the output to /dev/null, and just check the error status
:clap:
That would be swell
That would also be hugely helpful for Autotune one-off runners
For their manually created profile.json
@tim2000s : try the whole sequence. I had to definitely do sudo hciconfig hci0 name $HOSTNAME or the fix would fail