Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

v1.0 - Todo #72

Open
14 of 33 tasks
sneakers-the-rat opened this issue May 29, 2020 · 1 comment
Open
14 of 33 tasks

v1.0 - Todo #72

sneakers-the-rat opened this issue May 29, 2020 · 1 comment
Assignees
Milestone

Comments

@sneakers-the-rat
Copy link
Collaborator

sneakers-the-rat commented May 29, 2020

Let's list the todo items, completion of which will indicate we have reached 1.0. As we list and start each of these things we can create separate issues to track or ask questions, but wanted to take the questions from the software architecture document and juice them into a todo-list taped to the repo.

Comment and i'll add to this list.

I'll make a separate issue for stuff we'd like to have but don't need to have in order to reach v1.0. let me know if anything i've put here needs to be moved there.

  • Controller, Alarm Manager, GUI - Ability for controller to send technical/hardware alarms to alarm manager to be displayed by GUI (reimplement get_alarms in controller, coordinator will poll and send to alarm manager?)
  • Controller, Coordinator, GUI - heartbeating to track state of each component
  • 355b570 - Controller, GUI - Remove temperature/humidity. Not tracked.
  • Coordinator - Ability to restart coordinator and GUI without interrupting each other
  • Controller - top-level try/catch to handle any exception in loop
  • HAL - be able to restart pigpiod, signal to controller that something is wrong with the hardware
  • HAL, GUI - Calibration routine
  • bfd13d9 - GUI - Persistent control state save/restore.
  • GUI - GUI able to check controller state and rejoin coordinator
  • GUI - what happens when you push stop? pause/close routine
  • GUI - User confirmation for potentially dangerous settings
  • GUI - Dependencies between control parameters incl. setting I:E & calculating other values
  • GUI - Touch screen mode?
  • GUI - Lock mode when no alarms are happening
  • bfd13d9 - GUI - Finish final reorganization of components: control panel on left, prototype waveform on top & in white background.
  • GUI - Controls color-coded with prototype wave components, glyphs indicating what they control, error limits also on prototype plot
  • GUI - switch to show pressure v. flow
  • GUI - Statup parameter setting routine including VTE -- agerage three breath cycles
  • GUI - Control to record data
  • Containerization - Make raspbian docker image for distribution
  • Containerization - Implement systemd service that autostarts program on system start and ensures processes remain responsive
  • Testing, Controller - write tests for FDA regulations
  • Testing - System stress test on firstrun: SD card, processor, memory
  • Logging - if system out of storage space even though logs should be cycled, delete logs, clear temp files, and display info message in GUI
  • Logging - v1.0 - Implementing logging #73 - implement logging throughout each module. Use DEBUG level for anything cyclical, INFO for discrete events like user interactions, initialization events, etc.
  • cdbe795 - Logging - Make size limits global rather than per-logger.
  • Exception Handling - Decorator to handle and log exceptions rather than crash on them
  • Exception Handling - Timeout decorator
  • Alarms - detect a cough
  • Alarms - Alarm sounds, and can alarm sounds be played by any object?
  • Documentation - v1.0 - Documentation #74 - but that should be its own separate issue.
  • cdbe795 - Configuration - prefs should maintain persistent system preferences like hardware configuration, update times, etc.
  • Configuration - We need to pull out any hard-coded parameters that should be controllable by the user and add them to vent.common.prefs . prefs should keep a .json file updated in the ~/vent directory.
@sneakers-the-rat
Copy link
Collaborator Author

mayhem mode - fixture to specify what sensor values cause each alarm, then automate testing that throws a lot of them in random orders

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants