bluerobotics / bluerobotics/BlueOS

core: frontend: notify when devices disconnect

Open
#2,655 1 comment 0 reactions 0 assignees View on GitHub
core enhancement triage ui
Dominant language
Vue
Stars
453
Forks
151
Avg merge
1d 3h
Merged PRs (30d)
174

Description

### Current behaviour

Currently if we lose access to a peripheral that isn't the autopilot then BlueOS generally doesn't provide any kind of consistent or obvious warning about it, so the operator may not realise until a point where it's problematically late.

In addition, issues like #2569 can be indicative of a hardware problem from a loose connection / damaged cable, which either results in unpleasant interface bugs with repeating or disappearing devices, or gets hidden by smarts that assume it's the same device but still don't provide a meaningful warning to the user.

### Expected or desired behaviour

It seems worthwhile to:
1. try to detect if any connected device (serial, camera, ethernet, etc) drops out, and provide a notification of it
- and maybe services (wifi, internet, etc) and extensions too?
1. keep track of when devices last dropped out, and if it was recently and happened more than once provide a warning about potential hardware/connection issues

We could potentially create a service for this, that either monitors all devices at the hardware level, or that provides an API for device managers and drivers to give basic status/event updates with things like the name and type of a given connection (and maybe some relevant metadata if appropriate, like last recorded temperature and/or validity/status), and then the service can be in charge of the (configurable?) notifications and the repeated disconnection tracking + warning. That could optionally provide MAVLink notifications/warnings too, at the user's discretion, and could provide aggregated telemetry to provide to the user's BlueOS Cloud account so they can identify known issues with vehicles.

### Prerequisites

- [X] I have checked to make sure that a similar request has not already been filed or fixed.

Contributor guide

No contributing guide indexed for this repository

Research direction

No files, tests, or entry points are named. Start by narrowing the proposed scope and identifying the existing device managers, notification path, and status APIs involved. Done would require an agreed design and clear acceptance criteria for detecting disconnects and presenting repeated-failure warnings.

Written by the indexing model from the issue text.

Assessment

Domain
frontend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
15/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.