Differences

This shows you the differences between two versions of the page.

--- hardware:tbox [2026/08/12 12:31] – external edit 127.0.0.1
+++ hardware:tbox [2026/08/12 13:37] (current) – [Remote preconditioning is in the firmware] steini
@@ Line 173: / Line 173: @@
 ===== Remote preconditioning is in the firmware =====
-Although the printed manuals say the car has no remote climate, the capability **is present in the TBox firmware** — it was simply orchestrated by the OEM cloud, which is now gone.
 The telematics app contains the remote-control machinery: routines to **check preconditions**, **wake the MCU**, and drive **A/C, rear-defrost and door-lock** remote-control state. The one feature traced end to end is a **mid-trip battery pre-heat** (warm the pack before a fast-charge stop):
-  * **Trigger is cloud-only.** It fires on a command field delivered by the (dead) cloud; **no local trigger exists in the code**, which is why it no longer works.
+  * **Trigger is cloud-only.** It fires on a command field delivered by the (dead) cloud; **no local trigger exists in the code**.
-  * **Pre-checks before it acts:** HV system on, DC-DC idle, on-board charger idle, **SoC > 10 %**, **battery minimum temperature < 15 °C**, **range > 20 km** — classic "skip if already charging, already warm, or nearly empty" logic.
+  * **Pre-check:** HV system on, DC-DC idle, on-board charger idle, **SoC > 10 %**, **battery minimum temperature < 15 °C**, **range > 20 km** — classic "skip if already charging, already warm, or nearly empty" logic.
-  * **How the command reaches the car:** not an ordinary broadcast frame — the TBox sends a **security-gated UDS routine over the diagnostic CAN**, and the MCU relays those bytes to the bus. The only frame the TBox emits on its own is a network-management **wake frame**.
+  * **How the command reaches the car:** the TBox sends a **security-gated UDS routine over the diagnostic CAN**, and the MCU relays those bytes to the bus. The only frame the TBox emits on its own is a network-management **wake frame**.
-The MCU side confirms the mechanism: it defines a **remote CAN-message descriptor** carrying //which bus//, //data source//, a **"requires HV on"** flag and a **repeat-count + cycle-time** — i.e. the Linux side can ask the MCU to send a parameterised, repeated CAN message gated on vehicle power. Recognised **wake sources** include an **RTC timer**, the charge signal, CAN activity, the modem RING line, USB and ACC — so the TBox can **wake itself on a schedule** with the car parked.
+The MCU defines a **remote CAN-message descriptor** carrying //which bus//, //data source//, a **"requires HV on"** flag and a **repeat-count + cycle-time** — i.e. the Linux side can ask the MCU to send a parameterised, repeated CAN message gated on vehicle power. Recognised **wake sources** include an **RTC timer**, the charge signal, CAN activity, the modem RING line, USB and ACC — so the TBox can **wake itself on a schedule** with the car parked.
 **What that means for reviving preconditioning:** you cannot ride the original cloud (see below), so the practical path is **local** — with root on the TBox, invoke its own remote-control routine directly, or replay the UDS command from your own CAN node.