Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Decide when CAN read-only is turned off, and who can do it

Open
#72 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
rust
Domain
embedded-iot

Research direction

Start with docs/can.md and the existing set_can_read_only(false) behavior; the issue also points to identity check #49, logger #44, and debug toggle #12. Compare the listed unlock and relock policies, including the constraint that MQTT cannot unlock the bus, and check the TWAI mode-switching cost. Done means the policy is documented, implemented with tests for relock conditions and MQTT, and defines the debug toggle.

Written by the indexing model from the issue text.

Description

enhancement

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

Problem

Every command issue says "only send while read-only is off and the car identity check passes". The identity gate exists (#49) and the SavvyCAN logger forces read-only (#44), but nothing calls set_can_read_only(false) and no document says when that should happen, who may trigger it, or when the bus locks again. Each command would otherwise invent its own answer.

Options

  • Automatic. The bus unlocks once the identity is confirmed (and, say, a bonded phone is connected). Simple, but the car is controllable with no deliberate action from the owner.
  • Explicit. A system command from a bonded phone (BLE only, never MQTT) turns control on. Off at every boot, and it locks again after a timeout, on disconnect or on a bus fault. Needs a contracts message and app UI.
  • Per command. The bus leaves listen-only only while a command is being sent. The ESP driver rebuilds the TWAI controller when the mode changes (see docs/can.md), so check what that costs and what it does to the bus before considering this.
  • Development only. A BLE toggle in debug builds (the item in #12 and contracts#21), regardless of the choice above.

Questions

  • What locks the bus again: phone disconnect, car asleep, bus-off, a logger session, a timeout?
  • What does the app show (read-only or control enabled), and which contracts field carries it?
  • Is switching between listen-only and normal mode repeatedly safe on a real car?
  • MQTT must never unlock the bus, whatever is chosen.

Done when

The policy is written in docs/can.md, implemented with tests (including the relock conditions and that MQTT can't unlock), and the debug toggle from #12 is defined within it.

Dominant language
Rust
Stars
1
Forks
0
Avg merge
14h 32m
Merged PRs (30d)
21

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

  • No Dockerfile or Docker Compose file
  • No pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenCarControls/firmware

All issues in OpenCarControls/firmware

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.