bluerobotics / bluerobotics/BlueOS
core: frontend: notify when devices disconnect
- 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