As Lloyd points out this is the kind of things that could be recorded and made accessible using the FHIR AuditEvent.
The specific examples you mention could be intercepted and formatted to fit into a FHIR AuditEvent. There are similar events that are profiled in the DICOM specification for use when DICOM devices have these general configuration events, system started, system shutdown, address assigned, connection failure, etc.
Specifically to recording when a connection fails, this is a good one for FHIR AuditEvent. As the healthcare layer will know that it attempted to connect, why it was trying to connect, and it can record any specifics about why it failed to connect.
This said, I would not generally recommend that events that are already recorded in a different log format be simply reformatted unless there is a specific use-case for that. Meaning, that the existing log format is likely to be just as usable even when it is not in the FHIR format. I am thinking of your examples of starting timers and bluetooth pairing. There might be a need for the specific FHIR AuditEvent structure, but not clear to me why these would need to be in FHIR format.