Comment Search

my preference is to keep UI alarms sequentially next to each other if you don't mind.
Let me know if you would like me to remove them.

RESOLVED

It's needed for heater monitoring. so, reserving it for future.

Why 590? Magic number - use #define.

updated and removed

RESOLVED

RESOLVED

RESOLVED

you can remove the
!== ""

These broadcast changes look like temporary test changes. Restore before merging this branch to staging.

Removed.

FP Versions

Should clear immediate property be TRUE for these alarms that do not stop? Or is f/w clearing the condition when back in range?
If we are not stopping anything when these alarms occur, should we set auto resume to TRUE?

Beta and Alpha are swapped here. Beta should be -14.... and Alpha should be 0.0.

Consider keeping the transition to spent chamber fill pending until balancing chamber cycle completes.

Is this assignment needed? Seems like it would already have to be FALSE to get into the if.

Same comment - pend transition until BC cycle completes.

Align comments

What is this code doing? Why no comments? Is it necessary?

MIN_TIME_BETWEEN_AIR_TRAP_FILL_LOW_PRESSURE_ALARM_EXEMPTIONS_MS (as a suggestion).
Also be more descriptive in comments.

What does this comment mean?

Change to "available" properties (e.g. priority low).

Just set the 2 local array variables here outside the loop so you don't need the switch statement inside the loop.

Alarm should be handled inside of setAirPumpState().

The removed code changes are dead code due to condition of "if" condition check at top level ( ALARM_TABLE[ a ].alarmClearOnly). these alarms have property of 'clear only' as 'TRUE" in the alarm table. hence condition always be false and the removed code changes never executed.