You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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:
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
The text was updated successfully, but these errors were encountered: