Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Client] - Car Config Page #255

Open
Tracked by #256
jr1221 opened this issue Dec 6, 2024 · 0 comments
Open
Tracked by #256

[Client] - Car Config Page #255

jr1221 opened this issue Dec 6, 2024 · 0 comments
Labels
angular-client Development Focused in the Frontend difficult A task most likely involving research

Comments

@jr1221
Copy link
Contributor

jr1221 commented Dec 6, 2024

Description

Right now, Scylla has car config endpoints. Car configurations are used to control certain aspects of the car. For example cooling fan speed. Car commands can be variable, meaning if someone (probably Jack) wants to control a certain part of the car, they can deploy new commands on the fly (we'll get to security). These commands are published as topics over MQTT, which can be received by the client and displayed dynamically (meaning if a new config is added, are UI can adjust based on the another being published under the car commands).

Just so you know and don't go looking, currently there is no legitimate implementation of these "car commands" on the car. There are two mock car config's that have values A B C.

Each config command is just a key/value list, and are all floats (keys being the arguments titles to the car command). For example fan cooling may have a key/value list (speed/10, lights/0) 0 being lights on or lights off (this is made up and not actually what the cooling fan may use).

note on security:
car commands are specifically publish as topics to ensure that the car code has control over what commands can be sent. That way someone can't turn off the car without an explicit addition of that command in the embedded code.

Acceptance Criteria

Can set key/value pairs and see them update, on the backend. (you can ask Jack or Wyatt about testing this when your finished, or just want to prove that your backend calls will work)

Proposed Solution

Each config is identified by the key, and has:

  • Editable: list of data floats,
  • Viewable list of data values, key labeled

In theory you edit the floats, click send or save or something, and then the viewable list matches the data you sent, confirming the command worked.

We will eventually want to build a more concrete GUI for commonly used car commands. However, you will be building a dynamic way to view these commands and submit theme in a form format. For specific design, you could use a drop down selector and then have a generic form template (which will pop up when a certain command is selected), with the drop down containing the list of topics received from scylla which are given to it from the MQTT mentioned above on the car.

You could also just have scrollable list of forms... however that get's complicated fast. (probably don't do this)

If think of a better way to display the forms in a different just ask Jack or Wyatt about your idea... maybe draw a sketch.

Tip:
look over the backend config routes to see what is possible and setup on the backend to determine your approach to the UI and logic of your config page.

Mocks

Coming soon

@jr1221 jr1221 mentioned this issue Dec 6, 2024
18 tasks
@bracyw bracyw added angular-client Development Focused in the Frontend medium A more complex task labels Jan 12, 2025
@bracyw bracyw changed the title [Client] - Car config [Client] - Car Config Page Jan 15, 2025
@bracyw bracyw added difficult A task most likely involving research and removed medium A more complex task labels Jan 15, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
angular-client Development Focused in the Frontend difficult A task most likely involving research
Projects
None yet
Development

No branches or pull requests

2 participants