Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • 08:44
    petervoogt commented #3003
  • 07:14
    karper5000 commented #3003
  • Jan 22 15:54
    StephenBrown2 commented #3007
  • Jan 22 15:54
    StephenBrown2 commented #3007
  • Jan 22 09:52
    MilosKozak closed #1545
  • Jan 22 09:52
    MilosKozak closed #2999
  • Jan 22 09:52

    MilosKozak on master

    Update README.md (compare)

  • Jan 22 09:50
    MilosKozak edited #3007
  • Jan 22 09:46
    MilosKozak closed #2996
  • Jan 22 09:45
    MilosKozak opened #3007
  • Jan 22 09:43
    MilosKozak commented #3006
  • Jan 22 09:42
    MilosKozak closed #3004
  • Jan 22 09:42
    MilosKozak commented #3004
  • Jan 21 21:43
    classchneider edited #3006
  • Jan 21 21:42
    classchneider edited #3006
  • Jan 21 21:37
    classchneider edited #3006
  • Jan 21 21:37
    classchneider edited #3006
  • Jan 21 21:34
    classchneider edited #3006
  • Jan 21 21:32
    classchneider edited #3006
  • Jan 21 21:32
    classchneider edited #3006
jhaydraude
@jhaydraude
Back to expiration, I also include reservoir level as part of expiration. The distinction may be important for the system, but as a user, all I want to know is "When do I need to do a pod swap" and I don't care if it's because I timed out or because I ran out of insulin
teleriddler
@teleriddler
Reservoir levels are reported BUT it is not an exact science with the Omnipod as we don't know how much insulin the users puts in the pod. The 2 beeps triggers at a certain point but it is an inexact measurement. Therefore we can only report what insulin has been delivered and thus have made 50+ Units denotation. When it falls below 50+ units, text turns yellow and then displays an unit increment amount left (IE 45, 44, 41, etc) As boluses, TBRs and SMBs are delivered.
Expiration across days is on the list for improvement and we have already heard from Omnicore users the request for a DnD window (IE sleeping). So if a pod change will occur when someone is sleeping a notificaton will be given before that time.
Right now, you can set the expiration for X hours before 80 hours. 72 is recommended by Insulet but the 8 hour grace period is also factored in. If you set it to 10 hours then you will get a warning 2 hours before the 72 hour period. All calculations are done from the max 80 hours. When 80 hours is reached the pod will scream and we recommend that users set the expiration to at least 9 hours before.
Actions Tab: what icons are no longer used? Careportal information is all relevant. Battery change is now only conditionally shown for OrangeLink/EmaLink. TDD we cannot display due to the way the pod relays reservoir information, but it is on the board for future improvement. Everything else is AAPS core functions.
teleriddler
@teleriddler
Carb Entry: I still enter carbs first and then open the calculator. You can enter them directly in the calculator and with the advanced switches (tick boxes) you can enable or disable COB, Trend, etc. However I like loop to run once with COB after I enter carbs and then use the calculator. Also with SMB I just turn on the percentage in the calculator to deliver 2/3 (66%) of the recommended bolus and let the SMB take care of the tail. I agree it could be easier and I would also like to see improvements for Fat/Protein calculation but this looks like core AAPS and not Omnipod driver specific. These would be good suggestions for AAPS core.
jhaydraude
@jhaydraude
Actions Tab: what icons are no longer used? I currently (2.8.1) have whitespace where the prime/fill, pump battery change (you've addressed that) and Extended Bolus buttons live.
teleriddler
@teleriddler
Pizza: Same, I enter 2/3 bolus using percentage with SMB on and have the tail take care of the rest. I also set an alarm for a few hours later to remind me to check and manually bolus more if I need.
jhaydraude
@jhaydraude
Sorry, I have to do my real job for an hour but will be back.
teleriddler
@teleriddler
Hm....prime/fill should not appear (but I am using OrangeLink) and I also don't have extended bolus listed. You have your pump type set to RileyLink correct? I will check that and agree those should not be there. Careportal/Actions tab was one of the last things we changed and we waited a bit as we new devices were in active development.
Bolus Wizard Screen is getting crowded: You can turn the advanced options viewing on/off by checking/unchecking the eye icon. I agree with being able to dynamically change the bolus percentage (+1 from me). There are some users on the German de.Loopercommunity.org that are doing a refresh on the UX and some of the things you mention are being actively developed to make the layout more intuitive and compact.
Can I ask what type of phone/screen size you are using/targeting?
Profile Overview screen from NSPROFILE tab is nice. Why don’t we see it with Local Profiles? I agree with you here, it is very nice and I was looking for it (the graph especially) on the Profiles tab.
teleriddler
@teleriddler
Granularity of the + and - buttons in target BG dialogues is too fine. : I usually open the number pad dialog and manually enter but yes it would be nice to adjust how they increment (I use mg/dL and I think +5 would be fine but really number pad is fastest to get the exact BG entered).
From your document it looks like many of the Omnipod items have been addressed (Aside from Actions Tab extra icons, and blackout window for pod change notifications). The rest seem like AAPS core UX improvements suggestions in which I think the best method is to create a PR for submissions and review/comments.
jhaydraude
@jhaydraude
To be clear -- the buttons I mentioned are ones that are NOT appearing and whose whitespace I would like to repurpose. It's working as designed. That said, even though EmmaLink and OrangeLink both support batteries, my Rileylink does not and until I buy a new radio it will continue to not support battery reporting. To me, an ideal solution is to make visible buttons flow around invisible buttons rather than leaving space for them regardless of why the invisible button isn't there.
"Granularity of the + and - buttons in target BG dialogues is too fine. : I usually open the number pad dialog and manually enter" me too, but I would usually rather not . "Tap tap" is easier than "tap, wait for keyboard, backspace, type".
jhaydraude
@jhaydraude
Can I ask what type of phone/screen size you are using/targeting? -- My test devices all have large screens -- Xiaomi A1, Samsung S10, Samsung Note 9. I've stopped working on my UX for tiny screen because I no longer use a standalone android watch. As I mentioned these modifications are all things I currently do just for myself so I don't bother trying to support any devices that I don't own (which is why I'm coming here to have this conversation and see if there's interest in sharing what I'm doing)
From your document it looks like many of the Omnipod items have been addressed (Aside from Actions Tab extra icons, and blackout window for pod change notifications): Do you want assistance with any of these? I have already built the blackout window a few times.
Milos Kozak
@MilosKozak

@MilosKozak and other holders of the keys to the roadmap: How do you prefer that one suggests feature enhancements they've already built? Since the days of AAPS/Omnicore, I have been maintaining my own fork of AAPS that includes several UX tweaks that I find help usability (especially for Omnipod). With each official update you put out, I apply my changes to my fork (working on 2.8.1 now). Now that Omnipod is part of the main codebase with 2.8 and is less of a moving target, it makes sense to see if the broader community is interested in what I've been working on. Should I create issues and submit PRs against them? Do you want to go over some of my use cases to assess their spot in the roadmap? Anything else?

you can create PR to dev branch for discussion

or if you have only ideas you can open topic in issues
teleriddler
@teleriddler
@jhaydraude yes, the blackout window would be of interest since it is on the roadmap. As for the phone types it is good to know what you are using/testing against. There are still a lot of users that utilize small screens (mainly parents buy these phones for their kids as they are easy to carry and can't play a lot of games on them) so that has to be considered in design. However, applying your own personal patches is what is great about open source. I do think many of the ideas in your document merit consideration for improvement. I am not sure if they are active in this channel but @osodebailar and @rig22 have been working on overall UX improvements and have submitted PRs for their new designs (you may have seen icon updates in the latest versions due to them). Floating layout and works well but I personally found trouble with buttons expanding to fill the remaining space (becoming very large). I am currently reworking the pod management UX in the Omnipod driver screen, as well as taking a stab at reworking the Pod overview status screen. Would be happy to chat via PM and exchange ideas or collaborate. Thanks again for posting the list and it is encouraging to see that some of the items on it were pre-emptively addressed.
jhaydraude
@jhaydraude
Excellent. I've been meaning to join this discussion for a couple years now. Happy to contribute. While I submit a few small PRs related to the list I would like to talk through some thoughts around the DnD/Blackout window. I can imagine something like that being part of an Alerts plugin which would allow other drivers to register alert conditions and provide users with a central place to manage alerts and notifications. Or it can just be tied to Omnipod and its expiration.
Milos Kozak
@MilosKozak
cat? :)
Andy Rozman
@andyrozman
cleaning keyboard...
rICTx-T1D
@rICTx-T1D
Hi, can anyone give a forecast when omnipod dash is supported by AAPS?
dvdv
@dvdv_gitlab
I don't think the dash protocol is even fully reverse engineered yet
Andy Rozman
@andyrozman
@rICTx-T1D Not very soon. Devs are still trying to work it out how communication work (underlaying BT one). Most of the real work, just started. While we had access to source code, we didn't have access to Pods, which is getting better now that Dash is becoming more available... So if you want to Loop with Omnipod, go with Eros for now, it might be a long time before Dash will be supported.
teleriddler
@teleriddler
To comment further, the groundwork that has been put place place for the Eros pod is a huge step in getting DASH communication integrated once decoded. Many of the routines and processes are the same for Eros and DASH pods, just the communicaton signals/order might change or maybe not at all once decrypted. A lot of the driver work for Eros at first was getting the pod communication decoded and the sequences documented (this was a large effort by many people) using tools like RFSpy, RFCat, CE_Debugger, etc. However after that was done, then the software framework needed to be built to execute the commands, integrate safety checks and scheduling, the UX, feedback and logging, etc. Much of this can be reused for the DASH pods communication.
rICTx-T1D
@rICTx-T1D
@teleriddler @andyrozman thanks for your information
amosxo
@amosxo
Hi, I am trying to create an apk from version 2.1 from MilosKozak/AndroidAPS github repository but I get the following error:

A problem occurred configuring root project 'MilosKozak1'.

Could not resolve all artifacts for configuration ':classpath'.
Could not find com.jakewharton:butterknife-gradle-plugin:9.0.0-SNAPSHOT.

amosxo
@amosxo
Is it a known issue? I am just following the instructions of https://androidaps.readthedocs.io/en/latest/EN/Installing-AndroidAPS/Building-APK.html where I replaced nightscout with MilosKozak and then I do VCS->Git->Benches...->Checkout Tag or Revision and I select 2.1.
Andy Rozman
@andyrozman
@amosxo Why would you build so old version?
amosxo
@amosxo
Because Milos suggested me this in order to migrate my AndroidAPSPreferences version by version until I reach the most recent one i.e. 2.8.1.1.
Andy Rozman
@andyrozman
... and yes it seems like this (remote) artifact was removed. There is nothing you can do there, unless you find maven repostiry that still has that old version of butterknife, then you could add that repository... Or you could take newer version of that artifact and hope it will work...
amosxo
@amosxo
When I load the old AndroidAPSPreferences extported from version 2.0 to the new version directly its does work and I have to go though the goals again.
Ok but how can I take a new version of this artifact? I am not very familiar with android Studio
Andy Rozman
@andyrozman
go into build.gradle in app/ and change it there
Dirceu Semighini Filho
@dirceusemighini
Does anybody know where it's stored the sensorage info? How can i access it at the pump plugin classes?
Andy Rozman
@andyrozman
@dirceusemighini What are you trying to do?
Dirceu Semighini Filho
@dirceusemighini
I'm integrating a new device for communicating to medtronic 7xx pumps, as those pumps often miss some sensor readings, I'm trying to use the get bg history command to fill the gaps. So whenever I have a missing BG reading, I'll trigger a get bg history command. But when the sensor is at warm up, it doesn't return a valid value for BG and this would trigger a lot of unusefull commands do the pump, and i want to avoid that. So if the sensor age is bellow 2h I wouldn't care about missing BG history values, but I couldn't found this values a way to find it's values, at pumpstatus neither at pumpservice. Looking for it is very hard, because sage (the abreviation of sensor age) matches a lot of things.
jotomo
@jotomo
@dirceusemighini See (invocations of) method info.nightscout.androidaps.db.DatabaseHelper#getLastCareportalEvent
Andy Rozman
@andyrozman
Why not just add CGMS reading to the current driver? If you will have separate "device" that the comminicates with pump, this will disrupt communication of original pump driver
Dirceu Semighini Filho
@dirceusemighini

@dirceusemighini See (invocations of) method info.nightscout.androidaps.db.DatabaseHelper#getLastCareportalEvent

thanks @jotomo

Why not just add CGMS reading to the current driver? If you will have separate "device" that the comminicates with pump, this will disrupt communication of original pump driver

In my case this device does read the pump data, including bg and does the ackt commands to the pump, like bolusing, suspending and reactivating.

Andy Rozman
@andyrozman
So you will replace driver tested by over 100 of people, with your experimental one, hoping it works correctly.
Dirceu Semighini Filho
@dirceusemighini
I don't want to replace the current driver, I want to add a new communication device to the AAPS, so it will fit more pumps. They work different, with this one that I'm implementing the pump communication logic is at the firmware, and the communication is async.
Andy Rozman
@andyrozman
1 device to support all current pumps?
Andy Rozman
@andyrozman
Only problem is that PumpDriver framework requires sync communication...