ethanjli
commented
3 years ago We may also need to log alarm mute/unmute events.
There are "weird"/edge cases to consider about how alarm muting behavior should work in the frontend (from the firmware's software button for alarm muting) and firmware (from the hardware membrane button for alarm muting) when the backend's connection to the frontend and/or backend has been lost. This includes generation of log events. Maybe the most robust approach is that the frontend's mute/unmute button is disabled when its connection to the backend is lost; otherwise we might encounter some tricky data inconsistency issues (e.g. if the frontend, while disconnected from the backend, can be muted, the alarm mute event may not be logged; or it might trigger an incorrectly-timed mute once it reconnects to the backend, if we don't also make sure timestamps are synchronized and checked; and if the user tries to mute/unmute alarms from the frontend but hears that firmware alarms haven't muted/unmuted, that would be confusing). And the firmware can always mute/unmute its audio & LED alarms, via the hardware membrane button for that functionality - the frontend simply won't update its display accordingly if a connection to the backend has gone down. And no matter what, if the backend is disconnected from the firmware and frontend, it should generate an audio alarm and it won't be made aware of any alarm mute requests, so its alarm can't be muted anyways - though this is the worst case.
Right now alarm muting isn't handled by the backend or firmware. We should implement backend simulator and firmware support for it. The mute needs to automatically return after 2 minutes if not manually returned (see https://github.com/pez-globo/pufferfish-software/pull/348#issuecomment-849206700 for more discussion)