Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Check the vehicle state before sending each command

Abierto
#73 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Activo
Stack tecnológico
rust
Área
embedded-iot

Línea de trabajo

Read the command handlers and state handling around the existing command flow, then review related issues #14, #11, and #37–#42 for context. Add a shared precondition check before command frames are built, with fixture state tests and documentation of the rule. Done means the first implemented command uses the helper and rejected commands receive a failed CommandResponse.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

enhancement

Part of the prerequisites for real commands (tracking issue to follow). Related: #14, #11.

Problem

The generic "command availability" work (#14, contracts#13) is a larger feature and will come later. Until then, a command handler that just sends frames could, for example, open the charge port or close a window while the car is driving, or act on a state that went stale when the bus fell silent. All E-GMP commands are still "Not implemented" (#37–#42), so this can be settled before the first one lands.

Proposal

  • A shared check that runs before a command's frames are built. Each command declares the state it needs, and a command that doesn't hold is answered with a failed CommandResponse and a clear message. A dedicated status code comes with contracts#13.
  • State freshness counts as a precondition. Don't act on state older than N seconds, or while the bus is silent (see #11).
  • The response is always sent, including when the command is rejected because read-only is on or the identity isn't confirmed.
  • Consider a minimum interval between repeats of the same command, so a stuck button can't flood the bus.
  • Each command PR lists its preconditions in its description and in docs/. Candidates to settle per command from real behaviour: not driving (charge port, trunk and frunk), car awake, current state differs from the requested one.

Done when

There is a helper and tests with fixture states, the docs describe the rule, and the first implemented command uses it.

Lenguaje dominante
Rust
Estrellas
1
Forks
0
Merge medio
12 h 49 min
PR fusionados (30 d)
19

Preparar el entorno

Abrir en Codespaces

Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.

  • Sin Dockerfile ni archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de OpenCarControls/firmware

Todos los issues de OpenCarControls/firmware

Issues similares

Más issues de Rust

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.