These are chat archives for nightscout/intend-to-bolus

20th
Nov 2018
Martin Haeberli
@mhaeberli
Nov 20 2018 00:52
easiest to re-flash and start over … but YMMV and anyway, I always defer to @danamlewis and @scottleibrand
Garrett Webb
@garetis
Nov 20 2018 01:02
It seemed to be going ok, but I just went to change the cgm to xdrip and now I'm unable to connect over SSH or Serial, so not sure
Scott Leibrand
@scottleibrand
Nov 20 2018 03:54
you'll need to get node 8 (and its accompanying npm) installed one way or another
jcorbett80
@jcorbett80
Nov 20 2018 14:27
image.png
updated pi zero WH, TICC1111 no hat . formatted sd card. Used the pibakery setup and the full bootstrap. chose xdrip as the mode. and this is what I keep getting. reset up multiple times. Changed cables. Setup my pi3 same way and plugged ti stick into it directly. Checked the naming of the stick that pi was giving it. I use copy paste on ns name and so on
I have looked at everything in the trouble shooting section
I also reprogrammed TI stick incase of failure and I bought a second one. both do the same
Scott Leibrand
@scottleibrand
Nov 20 2018 14:36
@jcorbett80 looks like the part of the install that installed the Go tools failed. you'll want to re-run oref0-setup and pay particular attention to that part
Andrew Baugh
@baughaw
Nov 20 2018 14:40

Grabbed the latest oref.. Noticed the sensitivity isnt changing.. found this.. Any ideas?

Completed oref0-autons-loop at Sun Nov 18 09:10:03 EST 2018
/bin/sh: 1: oref0-autosens-loop: not found

I'm on master branch

Scott Leibrand
@scottleibrand
Nov 20 2018 14:42
looks like a borked install: I'd pull the latest, re-run npm run global-install and oref0-setup or oref0-runagain
Andrew Baugh
@baughaw
Nov 20 2018 14:43
thanks scott.
live4sw
@live4sw
Nov 20 2018 16:01
Does anyone have experience with display issues that don't affect looping at all? For example - screen occasionally going blank (but working fine with display off and screen always comes on after pressing ESC), or having slightly garbled display/display artifacts?
I'm on my second pump that seems to be working fine except the display is occasionally acting up. Wondering if it's anything to be concerned about, maybe if caused by using lithiums, maybe something else.
Dana Lewis
@danamlewis
Nov 20 2018 16:08
@live4sw no, hasn't heard of that. Don't think it's lithium related
Just sounds like a tired pump, so I'd be a little more diligent about making sure you have CGM alarms and not-looping alarms enabled
live4sw
@live4sw
Nov 20 2018 16:11
Yep, very strange as this is the second pump of mine with this issue and yet almost nothing posted online about it.
Rachel Sandlain
@audiefile
Nov 20 2018 16:22
Hi everyone. I'm trying to view the offline website on the rig. I have the rig and phone/computer on the same network but when I put in the ip in a browser I just get error connection refused. I've tried on both android phone and mac computer (in both chrome and safari). I updated to dev today and re-ran setup and rebooted. I feel like it's something tiny and obvious but I can't figure out what I'm missing. Any ideas? I didn't see any notes for specifying a port anywhere?
Eric
@ecc1
Nov 20 2018 16:35
@jcorbett80 how do you have the TI stick connected to the Pi? SPI is preferable, UART should work but is lightly tested, and USB won't work (on dev branch, that is)
jcorbett80
@jcorbett80
Nov 20 2018 16:48
@ecc1 has something changed? I have always used usb and allow it to use the meowlink to negotiate functionality. I have never had to change a setting before or after setup to get my TI to work. If there is a change is there a post with instructions somewhere? I can look at spi also today after I follow what Scott said to do. And thank you for jumping in to help. It is appreciated.
@scottleibrand thank you. I will try a 4th time and watch what fails.
Eric
@ecc1
Nov 20 2018 16:51
mmeowlink is used by master, but the dev branch uses Go code for the low-level comms, and that doesn't support USB-connected radios I'm afraid.
Here's how to connect a TI stick to a Pi in a way that is compatible with how the Explorer HAT is wired, so the same code will work:
SPI0 CS0 (Pi pin 24) -> debug  pin 5
SPI0 CLK (Pi pin  23) -> debug pin 6
SPI0 MISO (Pi pin 21) -> debug pin 8
SPI0 MOSI (Pi pin 19) -> debug pin 10
any Pi 3.3V pin -> debug pin 2
any Pi ground pin -> debug pin 1
GPIO 4 (Pi pin 7) -> debug pin 7
and then the CC1111 on the TI Stick needs to be flashed with the SPI version of the rfspy firmware (the same firmware used for the Explorer HAT)
jcorbett80
@jcorbett80
Nov 20 2018 16:56
@ecc1 so if I am understanding you correctly we now have to do a hard wire from stick to pi? And where is the SPI rfspy code to flash to stick located and what is it's full name?
Eric
@ecc1
Nov 20 2018 17:14
I think this is the pre-built firmware: https://github.com/EnhancedRadioDevices/subg_rfspy/releases/download/v0.8-explorer/spi1_alt2_EDISON_EXPLORER_US_STDLOC.hex (can other Explorer HAT users confirm?)
And yes, you'll need to use jumpers or wires to connect the TI Stick to the Pi for either SPI or UART connection (or stick to the master branch and your current cc1111 firmware for USB)
jcorbett80
@jcorbett80
Nov 20 2018 17:29
@ecc1 Again, thank you for your help, and thank you for yours @scottleibrand and for everyone that puts so much work into all of this but why was it decided to go this route? the code for sticks and mmeowlink was written. You are asked if using a stik at setup. it should have stayed a redirect to code that would support. Not another instance of shutting someones system down and putting thier health in a bad place just because they did an update. It appeared my stick died based on the logs...now I am sure it simply didn't see it because it no longer was directed to it. So I purchased a new one and got the same error. i have been without a system for a while and have several other very bad health issues that are far worse than my diabetes but also mess up my bloodsugar terribly. Luckily I was born with diabetes and have a 57 yr history working with it so i was able to fight my way through. But this isn't a rout that should happen. And no it doesn't require extra coding. It was written already. The extra coding was to dismiss it and do hat only setup or face the consequences. I know this isn't all you and again i thank you for your help but total system change that also kills the existing systems has happened to me in the past. This is why FDA fights groups like ours. And I love this group, but killing my system each time you want to play with something new is not and ethical approach. Sorry to vent but I have been without for a stretch now...needlessly, and I had to wait a month so i could needlessly waste money, I didn't have at the time, on a stick I didn't need. I am through venting. But along with all of this wonderful advancement if you don't also look at the human side...we have all failed no matter what good comes out of this.
@ecc1 I am going to walk away from the pc for a while and not type anything else until I have calmed a little. i will watch for your verification of the correct firmware.
benfiscal
@benfiscal
Nov 20 2018 17:59
My provider provides me with Enlite sensors (MMT-7008). I have the guardian 2 link transmitter since I’m currently on the 640G pump. Do you know if these sensors can be used with a transmitter that is compatible with OpenAPS compatible insulin pumps?
Eric
@ecc1
Nov 20 2018 18:04

@jcorbett80 I understand your frustration. By all means, stick to the master branch if it was working for you.

Here's my take on how we got to the current state of affairs. Both the software and hardware of the previous platform (decocare/mmeowlink/Python on the software side, and Intel Edison on the hardware side) were no longer sustainable. There wasn't much development on the Python code, and the Edison had been discontinued by Intel. The Raspberry Pi Zero looked like the best choice for a platform that had good community support, price point, etc. even though it's not as good as the Edison for performance or power consumption.

Scott and Dana took the lead in getting a new radio module (the Explorer HAT) for the Pi. But the Pi Zero (unlike the larger Pi models) can barely handle running the Python and node version of openaps -- to the point where it often can't complete a loop iteration in the 5 minutes before a new CGM reading is available.

The Go code is something that I had been using for my own Edison and Pi Zero rigs with a different radio, and it turned out to be relatively easy to make the same code work with CC111x radios like the Explorer and TI Stick use. With a lot of others' help, like @cluckj and @alimhassam, an experimental openaps branch was created that used this instead of mmeowlink. And since it worked on what was expected to be the majority platform going forward, this became the current dev branch.

It's a volunteer-driven, community-based, open source project. There are all sorts of limited resources (development, testing, documentation) that come with the territory, and that sometimes means dropping support for older or less widespread configurations.

Jon Cluck
@cluckj
Nov 20 2018 18:22
yes, to all that, and I think that is the correct firmware too
jcorbett80
@jcorbett80
Nov 20 2018 19:22
@ecc1 I get it. And I understand the limited time and help available. And if this code is truely the best code then it is what should be used. However the documentation points us to use what i used. It was REWRITTEN in order to use the hat on the edison or the pi. two routes were updated in the docs. At that time a single sentence stating that if you don't use the hat with the pi there will be issues to be resolved with the TI stick. 1 sentence. My biggest issue is you may be 100% correct. But if you know it will shut peoples systems down (systems that keep their health in shape) stopping for 1 moment to think about the human beings wearing these things ...and no from this side of the fence Dana does not count...take no offense Dana. What I am saying is you knew what to do because the code was decided by you and Scott, and take the few additional minutes to figure out...ok we need to right ONE as in 1 additional sentence and not shut peoples systems down without their knowelge. That's all I am trying to say. There is no other health industry that willfully takes an existing system, sends you an updated code that shuts it down then later says oh yeah we did that because the code was better. There is a term for that I refuse to say in here because it is something that can't be taken back and if the wrong people see it, it will cause the group long term issue. I love the system but the race to always have more sparkle has to include the time to do it right. If not there needs to be a little bit of slow down to bounce things oiff the wall before throwing it out to users depending on it for the safety of thier health. That's all I am trying to say. i was in many of the groups. I helped to write corrections to the docs, I helped people treoubleshoot in multiple groups. When all i heard was the sd cards die to quick in pi's I tested and tested until I found solutions and my card that I just formatted for this lasted a good year without failure. I posted how. I understand the time and effort. I had my pi zero w running 24/7 long before ya'll could get the same machine to run at all. I get it..I posted how to do it. I know the time and effort it takes. But according to 3 doctors I have for 3 different diseases I have each one says I am dying and should not be alive now. And each one is saying it for just their issue let alone all 3 issues. So I also get the other side of this VERY VERY well. You by not slowing down 1 day to write 1 sentence in the docs that were already being rewritten for the very thing that caused this....I'm not going to say what position my health was pushed into oin here either but it wasn't good. All over 1 day and 1 sentence. This is real. There are people much sicker than me using these. Take a day off from coding to write the updates before pushing it out the door. Then all the coders get a break. Minds are fresh and docs are clean. I am no longer able to spend time in here due to my health. My days are not great anymore. Running an old system that was working 1 extra day would not have put anyone in a bad place. Shutting systems down does. If I was standing in front of you, you would know I am not yelling, but rather trying to make a point that sometimes speed is the biggest slowdown and the biggest time eater. How much time did you waste on just me this morning...due to 1 sentence not written trying to race getting something out. I love all of ya'll. i always have and always will. When Andy finishes the rileylink code for the android apps I will be out of your hair and you will no longer have to fool with me. I would make a reccomendation though. Look at the modular way they are doing it. each module stands alone as far far as the devices used is concerned. So as new is added it is much easier to adjust without killing other. Again I thank everyone for all the work you do. I really do. If you can let me know when you have verified the firmware I will be out of everyones hair. And again...THANK EVERY ONE OF YOU for all that you do.
jgslade
@jgslade
Nov 20 2018 19:55
//>
Cas Eliëns
@cascer1
Nov 20 2018 20:08
Hey @danamlewis I just saw your question about #1266 that you posted on oct 25 (I don't check gitter often enough..) I switched away from mLab so can't test it myself, but it worked for me before and I've heard from someone else for whom it also worked.
wrong 1266 :P
Raymond Richmond
@PedanticAvenger
Nov 20 2018 20:27
General "system architecture" question/discussion. I understand the initial development path of nightscout and leveraging Internet services to build the openaps system up. Then came the "camping mode" later. Now that we are where we are today does it make any sense to have development aim towards "offline/local" capabilities being the default but push to online whenever available automatically? The thoughts came to me this weekend as I was travelling and no Internet on plane, inside congested spaces, etc. Is it a painful change to consider? Is there actually any value?
Dana Lewis
@danamlewis
Nov 20 2018 20:29
@PedanticAvenger it's actually always been offline first, with medtronic CGM and a plugged in dexcom receiver
Have you seen xdrip-js stuff?
Raymond Richmond
@PedanticAvenger
Nov 20 2018 20:31
@danamlewis I've been looking at it, haven't jumped yet for what amounts to a likely "I like to look at the xdrip screen" reason and nothing more definable than that.
Dana Lewis
@danamlewis
Nov 20 2018 20:31
No. It's offline BG to the rig directly
Nothing to do with screens
Raymond Richmond
@PedanticAvenger
Nov 20 2018 20:31
I'd likely only need to change my wifes follower to nightscout client and end result would be the same.
Nono, I use xdrip on my phone and like it. ;)
Dana Lewis
@danamlewis
Nov 20 2018 20:31
Ah I see
Raymond Richmond
@PedanticAvenger
Nov 20 2018 20:33
But with xdrip-js does it keep it on the rig for looping decisions or go up to NS and back down? Or just log to NS?
Dana Lewis
@danamlewis
Nov 20 2018 20:35
Looping plus up to NS when online afaik
Raymond Richmond
@PedanticAvenger
Nov 20 2018 20:38
Well I have something on my list for my alternate rig now once I get the battery curve plotting done.
Garrett Webb
@garetis
Nov 20 2018 21:02
Is there a surefire way to connect to the Edison/Explorer? Wifi SSH was fine but then reinstall and reboot and I can't access it anymore. It was also working for Serial connection, but that doesn't work now either. Does this ever happen? What's my best bet to try to resolve?
Dana Lewis
@danamlewis
Nov 20 2018 21:25
Check and make sure board is seated well, and try to un and reseat?
Scott Leibrand
@scottleibrand
Nov 20 2018 22:29
@jcorbett80 you seem to have a mismatch of expectations around what to expect from a development branch. the Go based pump comms are only present in the development branch, not master, partly due to the issues you highlighted: among other things, we haven't yet perfected backwards compatibility for all existing users, or fully documented the steps needed to transition. if you're choosing to use oref0 dev, you're taking on responsibility, as a developer, for keeping abreast of the changes being made, the communications amongst other developers about those changes, and any updates that have been made to development branches of the documentation as well. please correct me if I'm wrong, but as far as I understand it, the master branch of oref0, version 0.6.3, still supports both the TI stick and the Carelink USB stick, neither of which is fully supported or documented in oref0 dev, version 0.7.0. it sounds like you are interacting with your OpenAPS system as an end user, not as a developer, so I would recommend you stick with the oref0 master branch and not use oref0 dev on your main rig. if you want to play around with oref0 dev, you should first (and perhaps only) do so on a separate development rig.
Dave Gourley
@RadEnder
Nov 20 2018 23:30
Hi All... Building my first rig with an Edison board. The two computers I've tried aren't recognizing the board with both USBs plugged into a Mac running Mojave. LEDs show it has power but doesn't seem to be recognized. I've swapped USB cables as troubleshooting suggests with no joy. Maybe Mojave? Can anyone confirm that Mojave works with the Edison? Any other ideas are welcome too! Thanks!
Garrett Webb
@garetis
Nov 20 2018 23:38
Still a no-go for me as well. I have noticed that when I plug in the Edison to the computer the windows connection sounds works but it isn't showing up in the drive section. It also didn't show up with the cords I have that the serial connection worked before, but thought I would mention it.
jcorbett80
@jcorbett80
Nov 20 2018 23:57
@scottleibrand Hi. Thanks for following up. i may be but I went back and looked. Following the directions in the latest date I did exactly what it said to do. I formatted my sd card so all of the old was gone. It directs you to a pi setup which I did. I.e. using pibakery then the written steps where it says if using pi choose this link. I did the cntrl c instead of the enter since it was pi. It then had me do a step to allow the setup to pick the correct branch for pi since the latest was not yet supported on pi. I did that also. Then when I got to setup of the actual oref0 it gave 2 options (D) the tried and tested tables which I chose. Or another option with not fully tested items that may fail. I assumed that was the developer. I did all steps multiple times with the same results. Have I taken a wrong path in that flow?