lamemakes / pilot-drive Goto Github PK

It would be great if functionality existed to log the data displayed by the OBD functionality to file on the local system.

This is an option that should exist within the UI rather than the config.json, as a user should be able to very easily enable/disable it, create new logs, and even specify which OBD fields they want logged (see Add a new OBDII/ELM327 stat to query)

This would be a reasonably large feature, requiring sizable changes on both the UI & backend.

Putting this here to keep track and outline the issue in case anyone was feeling up the the task.

Basically Bluetooth will need a refactor. As it stands, the Bluetooth service does not run on it's own Process. It is leveraged by other services (ie. media & phone/ANCS) to easily get BluezMediaPlayer and BluezDevice objects. This approach currently requires the service using Bluetooth to keep track of devices and make appropriate bluetooth state pushes to the UI.

This is icky and adds a lot of complexity & room for error to the overall program, along with making it hard to leverage the Bluetooth service for any service down the line.

The ideal solution here would be to make the Bluetooth service more self-contained, less reliant on external services, and easier to access APIs. This was my initial approach as can be seen here, but this seemed to put a lot of strain on DBus as accessing Bluetooth properties for the latest info/states required accessing of the dasbus proxy every time. Can be it's own process, but I'm trying to avoid process creation unless absolutely needed.

Rage on 🫡

Describe the bug

When PILOT Drive is installed on a host machine that doesn't have bluetooth capabilities, the Bluetooth service breaks with no indication to the user via the UI

To Reproduce

1. Install PILOT Drive on a host that doesn't have Bluetooth capabilities (no physical Bluetooth adapters/hardware)
2. Start PILOT Drive
3. After the dasbus timeout (25000ms) an error will show that the service creation timed out

Expected behavior

A lack of Bluetooth hardware is gracefully handled, and in the UI the user is alerted that there will be limited functionality (Bluetooth media, ANCS, and rfcomm OBD communication are all disabled)

Actual behavior

An error occurs with no indication to the user

Screenshots

Host information:

• OS: Ubuntu
• Version: 22.04

Additional context

While it may seem like this is nearly the full functionality of PILOT Drive now other media avenues such as local files and aux input are on the horizon, so it's important a lack of Bluetooth hardware is supported.

Describe the bug

When a null/improperly specified serial port is specified within the settings.json, PILOT Drive keeps trying to connect resulting in a high resource consumption and a serious slowing down of systems like the Raspberry Pi 4.

To Reproduce

Install PILOT Drive, and in /etc/pilot-drive/config/settings.json copy the following lines to enable vehicle stats, but without a proper port:

   "vehicle": {
        "enabled": true,
        "port": null,
        ...
   }

Expected behavior

After a few connection attempts, a timeout limit is hit and the user is notified in the vehicle tab that the connection to the car failed.

Actual behavior

An attempt to connect to the specified serial port (even if null) is continuously made, spamming logs and severely slowing down the host machine.

The setup tool, located here needs a full overhaul in terms of refactoring. What was originally supposed to be a small script used to setup PILOT Drive has grown significantly and now needs to be broken down and refined into vaguely the following:

1. It needs to be it' own module within the pilot-drive parent folder and like other modules separated into exceptions, constants, and business logic.
2. It needs a better "UI", the traditional y/n prompts work to an extent but when using the interactive aspect of the setup tool, the user can only overwrite the existing PILOT Drive config, as they either: 1. update the config with new settings or, 2. disable the functionality. There should be a third option to allow default settings or skip the prompt all together. The UI envisioned is similar to that of raspi-config if that would make sense in this scenario.
3. Some of the configuration options need to be better tested on actual machines or just implemented. For example, the Raspberry Pi camera functionality exists but has not been implemented in any command line/interactive aspects of the tool.

Describe the bug

When playing a bluetooth track that contains duration and position (progress timestamp) data, the progress bar is frequently not accurate, finishing largely before a song is over, or not completing when a song does.

To Reproduce

1. Connect to PILOT Drive via bluetooth
2. Play an audio track that contains duration & position data
3. Note that the progress bar is frequently not accurate, indicating the song is done much before it actually is.

Expected behavior

The progress bar matches the proper timestamp

Actual behavior

The progress bar is inaccurate to the actually playback timestamp

Screenshots

The progress bar about to complete

The completed progress bar

The actual song progress, not even halfway (jump scare)

Host information:

• OS: Fedora
• Version: 37

Browser information:

• Browser: Mozilla Firefox
• Version: 110

Smartphone:

• Device: Pixel 6a
• OS: Android 13

Additional context

This behavior is seemingly random, and the progress bar seems to be hit or miss, but when it's off it's way off. My guess is that this is due to the setInterval implementation and the inaccuracies of async time keeping

Describe the bug

When utilizing the sudo pilot-drive --setup tool, if a feature is previously enabled (ie. Android/ADB), then setup is ran again to disable said tool (ie. upon being asked to enable Android, opting for no), no changes will be made to the /etc/pilot-drive/config/settings.json and the mentioned feature will remain enabled.

To Reproduce

1. With PILOT Drive installed, enable ADB by changing /etc/pilot-drive/config/settings.json to:

    "phone": {
	"enabled": true,
        "type": "android"
    },

2. Run the PILOT Drive setup tool via sudo pilot-drive --setup
3. Select N when prompted to setup & install an android device

Expected behavior

The phone field in /etc/pilot-drive/config/settings.json is disabled or does not contain the disabled android type

Actual behavior

Nothing is updated in the settings.json

Additional context

This issue relates to #20.