adambrown1
commented
1 year ago - Instead of computing a slightly arbitrary max reading delay from the bad recurrence, use a fixed value from the database. Why? Because this number represents our trust in readings arriving in a timely fashion, rather than anything to do with how often the sensor must be bad before issuing an alarm
- Changed the way we check whether alarms were issued properly to use exceptions rather than return values (probably slightly more robust and certainly easier to keep track of - all exceptions are now caught only by the log_alarm function of AlarmNode before silencing the pipeline)
- When the user presses silence on the website, the level is -1 (meaning universal for all pipelines) instead of 0 (previous default, only silencing level 0 alarms)
- The start command doesn't reactivate silenced pipelines, which has lead to a couple of alarmstorms