When the firmware starts up, it should create a log event indicating this; similarly, when the backend server starts up, it should create a log event indicating this. During hardware faults, would enable troubleshooting about when a loss of connection is due to loss of connection or due to a crash+restart. During normal operation, this also allows us to log when the ventilator was powered on.
When the firmware is unplugged from the computer, it should generate an active alarm for lost connection to the backend; when the firmware is plugged back in, it should deactivate that alarm and generate another (non-alarm) event for connection to the backend is up. This issue is split off from side-remark in #320. We may want to disaggregate the log event codes, so that the firmware's "lost backend connection" and "backend connection is up" events are distinct (and have different messages) from the frontend's "lost backend connection" and "backend connection is up" events. Otherwise the user will see two of each event with no explanation of why they're duplicated. The firmware's events should be triggered by whether or not its Backend driver has received a new StateSegment within some timeout - this is the same approach used by the python backend server.
When the firmware starts up, it should create a log event indicating this; similarly, when the backend server starts up, it should create a log event indicating this. During hardware faults, would enable troubleshooting about when a loss of connection is due to loss of connection or due to a crash+restart. During normal operation, this also allows us to log when the ventilator was powered on.
When the firmware is unplugged from the computer, it should generate an active alarm for lost connection to the backend; when the firmware is plugged back in, it should deactivate that alarm and generate another (non-alarm) event for connection to the backend is up. This issue is split off from side-remark in #320. We may want to disaggregate the log event codes, so that the firmware's "lost backend connection" and "backend connection is up" events are distinct (and have different messages) from the frontend's "lost backend connection" and "backend connection is up" events. Otherwise the user will see two of each event with no explanation of why they're duplicated. The firmware's events should be triggered by whether or not its Backend driver has received a new StateSegment within some timeout - this is the same approach used by the python backend server.