Pulling the Alarms

[sneakers-the-rat]

OK this is thee alarm system. might be easier to get an overview from the docs: https://ventilator.readthedocs.io/en/gui/alarm.html

Overview (sorry this is all out of order i'm really really hungry and am racing to go eat):

• AlarmType - There a specific set of alarms that can be triggered, rather than any out-of-bounds value, so it's actually an alarm system.
• AlarmSeverity - Explicit enum allows alarm severity to be compared numerically
• Alarm_Rule s describe how an alarm behaves, including what triggers what severity of alarm. They consist of a tuple of (AlarmSeverity, Condition) tuples. They also define whether an alarm latches or not (persistent) alarms are not implemented
• Conditions have essentially one check method that takes SensorValues. They can be subclassed to add iteratively complex behavior (easier to just see for yourself i think), and can also be + added together to require multiple conditions to be true for a given alarm severity.
• Conditions can also declare dependencies like being some transformation (subtract, multiple, any callable) of a ControlSetting . eg 115% of PIP. (tests are not finished for this)
• An Alarm_Rule check s each of its conditions -- each 'multiple (added)' Condition terminates at its first False so they're not super wasteful -- and emits the highest severity alarm that is true
• The default Alarm_Rules are declared in /vent/alarm/__init__.py
• The Alarm_Manager handles all the logic of raising, suppressing, and storing alarms. There can only be one Alarm_Manager instance, so it is safe to use instantiation to get a reference to it. The alarm manager loads the default alarms on creation. The alarm manager accepts SensorValues in its update method, which then checks all of its rules.
• The Alarm_Manager is evented -- it doesn't poll, but can be updated with new SensorValues whenever needed. You are not supposed to poll the Alarm_Manager (like get_alarms) - instead you should add_callback and give it a callable that will be called with an Alarm anytime it is emitted.
• Alarms can be cleared - they won't be raised until the alarm state becomes OFF and back on again.
• Alarms can be snoozed - they wont' be raised until some time has passed
• Alarms can be latched - once an alarm is raised, it won't be turned off until its rule is OFF AND the user calls dismiss_alarm .
• Alarms that increase the AlarmSeverity are always emitted (unless they are snoozed or cleared). Alarms that decrease the AlarmSeverity are only emitted if the alarm is not latched.
• There is only one emit method, alarms are turned off by emitting an alarm with a severity of OFF.
• Alarms that are cleared are added to a list of logged_alarms but this needs to be integrated with whatever logging module @mschottdorf (i believe?) cooks up. Since the Alarm_Manager is evented, each Alarm object is self-descriptive, and turning alarms OFF is implemented using the same methods and objects (rather than by, say, deleting objects), logging should only need to be implemented in a single method that is added to the Alarm_Manager's callbacks.

~Other stuff~

• alarms added to the docs, i think most of it is ~75% documented
• all alarm tests in the coordinator and controller have been commented out, those will need to be rewritten but they shouldn't be radically different. This is also true of the control module and coordinator classes themselves -- the control_module now no longer needs to be involved with alarms, however, and the coordinator only needs to register a callback that will log alarms.
• AlarmSeverity enum has been renamed from GREEN, YELLOW, RED to OFF, LOW, MEDIUM, HIGH
• SensorValues now ensures that it is given a value for every item in values.SENSOR, and takes them as a dictionary rather than by unpacking **kwargs. as such no empty SensorValues objects can be instantiated
• SensorValues has __getitem__ and __setitem__ so sensor values can be accessed and set both as instance attributes but also like a dictionary (sensor['PRESSURE'])
• SensorValues now has an additional_values attribute that keeps track of the values that the controller generates and sends like timestamp, cycle counter, etc. there's certainly a better way of doing that but it works for now.
• SensorValues and the control_module have been updated to also track the current breath cycle (with itertools.count , otherwise just slipped into your existing code @mschottdorf ) -- this is useful for alarms that depend on, well, breath cycles. I'll need some help writing a test to make sure that number is actually accurate and i did it right
• also have added a few GUI tests, but since I'm about to rewrite the damn thing i figured i should wait on that.
• values now has all values in ValueName declared in VALUES. CONTROL and SENSOR are built from VALUE based on two new parameters, control and sensor.
• there's a real real janky mock of pigpio in vent/io/devices/base

~ TODO ~

• there is a skeletal alarm_manager that the gui still uses, i'll be replacing that with interactions with the real alarm manger, just ignore that for now.
• dependencies in conditions need to be tested
• gui needs to be brought to its final form

but otherwise ya what up

[sneakers-the-rat]

i'll go thru and make line-by-line comments as needed after dinner

[coveralls]

Pull Request Test Coverage Report for Build 257

• 422 of 500 (84.4%) changed or added relevant lines in 14 files are covered.
• 17 unchanged lines in 2 files lost coverage.
• Overall coverage increased (+4.7%) to 73.796%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
vent/alarm/alarm.py	42	43	97.67%
vent/alarm/rule.py	23	24	95.83%
vent/controller/control_module.py	13	14	92.86%
vent/gui/alarm_manager.py	1	2	50.0%
vent/gui/main.py	4	5	80.0%
vent/io/devices/base.py	9	10	90.0%
vent/gui/widgets/status_bar.py	4	10	40.0%
vent/common/message.py	27	37	72.97%
vent/gui/widgets/components.py	1	14	7.14%
vent/alarm/alarm_manager.py	126	144	87.5%
<!--	Total:	422	500	84.4%	-->

Files with Coverage Reduction	New Missed Lines	%
vent/gui/alarm_manager.py	2	41.03%
vent/controller/control_module.py	15	84.85%
<!--	Total:	17		-->

Totals
Change from base Build 250:	4.7%
Covered Lines:	2222
Relevant Lines:	3011

---

💛 - Coveralls

[sneakers-the-rat]

one of each alarm type can be active at a time. put another way, all alarm types can be active at the same time. the GUI will manage a coherent display that prioritizes and manages them.

[sneakers-the-rat]

sorry for not merging -- forgot we said for PR submitter to merge after we discuss. Will merge in now