[bug] Car does not enter sleep mode 2026 Y P HW4

[DrStrangeglovebox]

App version

v2.16-beta.4

Hardware

ESP32 (PR

Tesla firmware version (if applicable)

No response

What happened

Left AtomS3 Lite + TJA1051T/3 enabled overnight. The car does not enter deep sleep.

What you expected to happen

Enter deep sleep

Steps to reproduce

Enable (Fsd On, Force FSD on, Anti Nag on)

Screen output / counters

No response

[hypery11]

Thanks for the detailed report, @DrStrangeglovebox. Short version: this is expected for an AtomS3 build running in Active mode, not a regression.

What's happening:

• Force FSD and Anti-Nag both require Active mode, which puts the CAN controller in normal mode where the ESP32 ACKs bus traffic and transmits its echo frames. An always-on node that keeps ACKing/TXing can keep the car's gateway from going quiet, so the car never drops to deep sleep. Any permanently-powered Active CAN node behaves this way unless it power-manages itself.
• The automatic "CAN silent → ESP32 deep sleep" watchdog currently exists only for the LilyGO T-CAN485 board — it's gated behind BOARD_LILYGO. The AtomS3 Lite isn't a shipped target (there's no AtomS3 env in platformio.ini), so whatever custom env you built doesn't include the sleep handling at all — the device never sleeps and never pauses TX on idle.

What to do tonight:

• Switch to Listen-Only when you park (button single-click, or the dashboard toggle). Listen-Only is fully passive — the controller can't ACK or transmit — so it won't hold the bus awake and the car will sleep normally. Trade-off: Anti-Nag / Force FSD don't run in Listen-Only (they need TX), so it's "sleep at night, Active when driving."
• For a permanent install, note OBD-II pin 16 is always-on +12V, so the ESP32 itself keeps drawing regardless. Covered in HARDWARE.md under power/sleep.

Open item on our side: porting the idle-detect / deep-sleep watchdog beyond LilyGO (the M5/AtomS3 TWAI peripheral can do a CAN-RX wake source, so it's feasible), plus an optional "auto-drop to Listen-Only after N minutes of CAN silence." I'll track that as a follow-up. If you can share the exact custom env / build flags you used for the AtomS3 Lite, that helps me scope it.

[DrStrangeglovebox]

On the MYP 26 X179 #16 is unfortunately unpopulated. I draw from X962M #3 or #5.

I will change to 485 in time.

[jangshik]

On the MYP 26 X179 #16 is unfortunately unpopulated. I draw from X962M #3 or #5.

I will change to 485 in time.

how to you query this screen? normal service mode?

[hypery11]

Thanks @jangshik — useful harness note. Good to know X179 #16 is unpopulated on the MYP and people are pulling +12V from X962M (#3/#5) instead; I'll fold that into the HARDWARE.md power section so others don't chase a dead pin.

For the sleep question itself: the core issue is still that an Active-mode node keeps the bus awake (and the AtomS3 Lite build has no deep-sleep watchdog — that's LilyGO-only right now). Where you take +12V from changes the standby draw but not whether the car sleeps — that's driven by the device ACKing/TXing on CAN. Listen-Only when parked is the working stopgap; an idle-detect/auto-Listen-Only is the roadmap fix.

[DrStrangeglovebox]

how to you query this screen? normal service mode?

Normal service mode

[hypery11]

Thanks for confirming — normal service mode, got it. So nothing unusual there. The sleep behavior itself is still the same root cause: an Active-mode node (Force FSD / Anti-Nag on) keeps the bus awake, and the AtomS3 Lite custom build has no deep-sleep watchdog (that's LilyGO-only today). Listen-Only when parked is the working stopgap; an idle-detect / auto-Listen-Only is the roadmap fix. If you share the exact custom env/build flags you used, I can scope adding the sleep path for the AtomS3.

[DrStrangeglovebox]

flipper-tesla-fsd\esp32\platformio.ini file:

[env:m5stack-atoms3-lite]
platform = espressif32
board = esp32-s3-devkitc-1
framework = arduino
monitor_speed = 115200
upload_speed = 921600

; Flash settings for AtomS3 Lite (8MB)
board_build.flash_size = 8MB
board_build.flash_mode = qio
board_build.partitions = default_8MB.csv
board_upload.flash_size = 8MB
board_upload.maximum_size = 8388608

build_flags =
    -D CAN_DRIVER_TWAI
    -D PIN_CAN_TX=2          ; Grove Yellow (G2)
    -D PIN_CAN_RX=1          ; Grove White  (G1)
    -D PIN_LED=35
    -D PIN_BUTTON=41
    -D ARDUINO_USB_CDC_ON_BOOT=1
    -D ARDUINO_USB_MODE=1

lib_deps =
    adafruit/Adafruit NeoPixel@^1.12.0
    Links2004/WebSockets@^2.4.0

[hypery11]

Thanks — that's exactly what I needed (Grove G1/G2 = GPIO 1/2, TX=2/RX=1, ESP32-S3 board).

Two things off this:

1. The AtomS3 Lite env is worth making official. If you open a small PR adding your [env:m5stack-atoms3-lite] block to platformio.ini, I'll merge it — that gets the next AtomS3 Lite user a working build out of the box (and helps [fixed] [compat] M5Stack AtomS3 Lite (ESP32-S3) + TJA1051T/3 Mini CAN Unit <ModelY><Year 2026><HW4><Firmware 2026.14.6><EU > #106). I'd rather it land under your name since you've verified the Grove pins on real hardware; I can't test that wiring myself. Worth a one-line note that the Grove pin mapping can vary by CAN unit.

2. The sleep itself is the bigger piece. The deep-sleep watchdog is BOARD_LILYGO-gated today; the S3 TWAI peripheral can wake on CAN RX, so porting the idle-detect plus an "auto-drop to Listen-Only after N min of CAN silence" to the AtomS3 is feasible — I'll track that as the actual [bug] Car does not enter sleep mode 2026 Y P HW4 #109 fix, with your env as the board target to build it against.

[ssw0209-sys]

@hypery11

App version
v2.16-beta.6

Hardware
ESP32 (waveshare esp32 s3 rs485 with X179)

Tesla firmware version (if applicable)
2026.14.3

When i Activate [AP-First] function on dashboard, Car wake up every 30 minutes(At least) at Parked.