Research: Tire Pressure Monitors for 2013 Mazda CX-9

[tclancy]

Please find all the information you can about talking to tire pressure monitors for this car via RF.

Full car description from NHTSA

Manufacturer: MAZDA MOTOR CORPORATION

DBAs: Mazda Motor Corporation

Vehicle Type: MULTIPURPOSE PASSENGER VEHICLE (MPV)

Model Year: 2013

Make: MAZDA

Model: CX-9

Body Class: Sport Utility Vehicle (SUV)/Multi-Purpose Vehicle (MPV)

VIN: JM3TB3CV0D0420001

[metaframework-dispatch-bot]

Labeled priority:medium. Research task — find TPMS RF information for 2013 Mazda CX-9 (VIN: JM3TB3CV0D0420001). Queued for dev agents.

[metaframework-dispatch-bot]

Research: TPMS for 2013 Mazda CX-9 (VIN: JM3TB3CV0D0420001)

Quick Reference

Parameter	Value
Frequency	315.000 MHz (North America)
Modulation	FSK with Manchester encoding
Sensor Type	VDO/Continental
OEM Part #	BHA4-37-140A (primary); BDGF-37-140, BBM2-37-140B (variants)
rtl_433 Decoder	Try #186 (Hyundai-VDO) or #156 (Abarth-124Spider), both at 315 MHz
Encryption	None
Rolling Codes	None — static sensor IDs
Sensors	4 (no spare tire sensor)
Battery Life	5–10 years (not user-replaceable)

---

OEM Sensor Details

The primary OEM sensor is BHA4-37-140A (VDO/Continental), used across 2012–2020 Mazda models. No trim-level variations found — all CX-9 trims use the same sensor. Aftermarket programmable replacements (Autel MX-Sensor, Dorman Multi-Fit) can clone the original sensor ID, avoiding the need for ECU relearn.

RF Protocol

• Packet structure: 10 bytes Manchester-encoded
  • Preamble (sync) → State byte → Sensor ID (4 bytes, 32-bit) → Flags/repetition → Pressure (1 byte) → Temperature (1 byte) → Battery/status → CRC-8
• Pressure conversion: raw × 1.375 = kPa (or raw × 0.1974 ≈ psi)
• Temperature conversion: raw - 50 = °C
• CRC: CRC-8, polynomial 0x07, init 0xaa, covers all 9 data bytes
• Data rate: ~19,200 chips/s with 35 kHz deviation
• Transmission interval: ~60s when parked (event-driven); ~1-2 Hz when driving (accelerometer-triggered)

rtl_433 — Important Caveat

⚠️ Both decoders (#186 Hyundai-VDO and #156 Abarth) were designed for 433 MHz (European) sensors. Your 315 MHz sensors use the same VDO protocol family but at a different frequency. Prior research (issue #1) confirmed Register #156 works on Mazda at 315 MHz — this is because the Abarth 124 Spider is built on the Mazda MX-5 platform and shares the VDO protocol.

Recommended command sequence:

# 1. Start with no filter to see all decodings
rtl_433 -f 315000000 -M level

# 2. Once you see your sensors, try the targeted decoder
rtl_433 -f 315000000 -R 156 -M level

# 3. JSON output for HA integration
rtl_433 -f 315000000 -R 156 -F json

# 4. Direct MQTT publishing
rtl_433 -f 315000000 -R 156 -F "mqtt://localhost:1883,retain=1"

Note: Sensors transmit infrequently when parked. Drive briefly to trigger transmission.

TPMS Relearn Procedure (2013 CX-9)

If replacing sensors, the CX-9 has automatic relearn:

1. Inflate all tires to placard pressure (~32 psi) when cold
2. Turn ignition ON (engine off), wait 15 minutes
3. Drive at ≥25 km/h (16 mph) for ≥10 minutes
4. ECU automatically learns new sensor IDs

No button press or dealer tool required. Programmable aftermarket sensors (Autel, Dorman) can clone the original ID, skipping relearn entirely.

Home Assistant Integration

Architecture: rtl_433 → MQTT → HA auto-discovery

The easiest path is the rtl_433 MQTT auto-discovery add-on (pbkhrv/rtl_433-hass-addons). Once rtl_433 decodes a sensor, HA entities are created automatically:

• sensor.*.pressure_kpa
• sensor.*.temperature_c
• binary_sensor.*.battery_ok

Manual template for PSI conversion:

template:
  sensor:
    - name: "Front Left Pressure (PSI)"
      unit_of_measurement: "psi"
      state: "{{ (states('sensor.abarth_124spider_0xID_pressure_kpa') | float(0) * 0.145038) | round(1) }}"

Map sensor IDs to tire positions by reading the ECU-registered IDs via OBD-II (ELM327 + Mazda Enhanced Diagnostics), then cross-reference with rtl_433 decoded IDs.

Sensor ID Mapping via OBD-II

You can read the 4 registered sensor IDs from the ECU using an ELM327 adapter and Mazda Enhanced Diagnostics software. This tells you which hex ID corresponds to which wheel position (FL/FR/RL/RR), which you then use to label the HA entities correctly.

Security Notes

• Passive monitoring is legal (US, FCC Part 15 — receive-only)
• Do NOT transmit on 315 MHz without a license (felony under 47 USC §301)
• TPMS sensors are spoofable from ~38m (demonstrated at Defcon 2010) — no practical risk for monitoring your own vehicle, but worth knowing the protocol has zero authentication

Physical Specs

• Weight: 30–40g per sensor — requires wheel balancing when replaced
• Operating range: -40°C to +125°C
• Pressure range: 0–350 kPa (0–51 psi)
• Battery: Sealed lithium cell, not user-replaceable; 5–10 year lifespan

Recommended Next Steps

1. Verify reception: rtl_433 -f 315000000 -M level while near the car (drive briefly to trigger sensors)
2. Confirm decoder: Try -R 156 first (known to work from issue Research Task: Tire Pressure Monitoring #1 research), then -R 186 as fallback
3. Map sensor IDs: Once decoding, note the 4 sensor IDs and use OBD-II to map them to tire positions
4. Wire to HA: rtl_433 -f 315000000 -R 156 -F "mqtt://localhost:1883" → HA auto-discovery

Key Sources

• rtl_433 Abarth TPMS decoder source
• Reverse engineering TPMS protocol (Mazda 5)
• rtl_433 MQTT auto-discovery for HA
• Mazda TPMS Relearn Procedures
• Signal Identification Wiki – TPMS

[tclancy]

Closing — researched but not pursuing. Practical reception of 315 MHz TPMS requires the RTL-SDR to live within ~5–20m of the parked vehicle, which would mean a permanent Pi (or similar) in the garage. The marginal benefit (tire pressure on a dashboard) doesn't justify the dedicated hardware footprint. Research summary preserved in earlier comment for future reference if priorities change.

[tclancy]

Reopening this as part of a larger home dashboard idea. Don't want to bother with Home Assistant yet, just have the data available much like the Hyundai/ BlueLinky service so we could alert on tire pressure and show data in a general home dashboard.

[metaframework-dispatch-bot]

Scoping memo — TPMS ingest for a home dashboard

Reopen context: you want tire-pressure data available "much like the Hyundai / BlueLinky service" so a future home dashboard can read it, deliberately skipping Home Assistant.

Before code, checking the shape with you. One important framing correction, then a proposed architecture, then open questions.

The Bluelinky analogy only holds at the API layer

Bluelinky polls Hyundai's cloud endpoint — the car's telematics unit uploads over cellular and the service just reads a REST API. TPMS is the opposite: there is no cloud, no API, and no cellular uplink. The only way to read it is to demodulate the sub-GHz RF broadcast the sensor emits.

That inverts the deployment story: instead of a small poller anywhere on your LAN, you need an SDR physically near the parked vehicles — the original close cited the ~5–20 m range as the reason to shelve this. That constraint hasn't changed. What can change is whether the reception is worth it now that it's feeding a home dashboard, not just an HA card. Confirming that trade-off is question 1 below.

Everything above the reception layer does look Bluelinky-shaped: SQLite behind a small JSON API, one row per reading, dashboard hits it.

Proposed architecture (four boxes)

[ RTL-SDR + rtl_433 ]          # "capture" — garage/driveway-side
        │  (JSON events over MQTT or stdout)
        ▼
[ tpms-ingest daemon ]         # "ingest" — dedupe + normalize + write
        │
        ▼
[ SQLite: readings + vehicles ]
        │
        ▼
[ tpms-api ]                   # "read" — Flask/FastAPI JSON endpoints
        │
        ▼
[ home dashboard consumer ]    # future; out of scope for slice 1

Boxes 2/3/4 can collapse into one process — Bluelinky-style, this is a small Python service. Box 1 is the only piece that must live near the cars.

Where each piece runs — needs your pick

Box	Options
Capture (rtl_433)	(a) new Pi Zero 2 W in the garage (~$25 + antenna, dedicated); (b) piggyback on plexpi if it's already close enough to the cars; (c) mobile RTL-SDR in a car for drive-time data
Ingest + API	(a) same host as capture (all-in-one); (b) plexpi alongside bluelinky/fuelbot; (c) homelab (network-visible, but capture host now needs to push events to it)
Frequency scheduling	(a) one SDR, time-slice — e.g. 5 min on 315 MHz, 5 min on 433 MHz — parked cars only need to be caught once every 60 s so this works; (b) two SDR sticks ($30–40 each), one per band, no schedule

Cheapest reasonable path: Pi Zero 2 W in the garage running rtl_433 + ingest + SQLite + API. Homelab and future dashboard read over LAN. Time-sliced single SDR to start.

Data model sketch

CREATE TABLE vehicles (
  id           INTEGER PRIMARY KEY,
  slug         TEXT UNIQUE,      -- 'cx9', 'santafe', 'camaro'
  make         TEXT,
  model        TEXT,
  year         INTEGER,
  vin          TEXT,
  frequency_hz INTEGER,
  decoder      TEXT              -- rtl_433 register number, e.g. 'r156'
);

CREATE TABLE sensors (            -- one row per physical sensor
  vehicle_id   INTEGER,
  sensor_id    TEXT,              -- hex, from rtl_433
  position     TEXT,              -- 'FL' | 'FR' | 'RL' | 'RR' | NULL until mapped
  PRIMARY KEY (vehicle_id, sensor_id)
);

CREATE TABLE readings (
  ts             INTEGER,          -- unix seconds, UTC
  sensor_id      TEXT,
  pressure_kpa   REAL,
  temperature_c  REAL,
  battery_ok     INTEGER,
  raw_json       TEXT,
  PRIMARY KEY (ts, sensor_id)
);
CREATE INDEX readings_by_sensor_ts ON readings(sensor_id, ts DESC);

Retention: keep raw readings 30 days, then daily-min/max/last aggregates forever. Dashboard is fine off the aggregates for anything older than a week.

API shape (Bluelinky-flavored)

GET /api/vehicles                       → [ {slug, make, model, year, ...}, ... ]
GET /api/vehicles/{slug}/tpms/latest    → { pos: {kPa, psi, °C, battery, ts, stale}, ... }
GET /api/vehicles/{slug}/tpms/history?since=&until=  → time series
GET /api/health                         → { last_event_ts, receiver_ok }

latest returns per-position readings so the dashboard doesn't have to know sensor IDs. stale: true when the last reading is older than N minutes (parked-and-quiet vs. receiver-down are distinguishable via /health).

Setup ritual (one-time)

1. Confirm reception with all 3 vehicles — literally run rtl_433 -f 315M -R 156 (etc.) in the garage and watch for decoded packets. Drive if needed to wake sensors.
2. Record the four hex sensor IDs each vehicle broadcasts.
3. Map sensor → position. No RF-level way to do this — the sensor doesn't know where it's mounted. Two options: (a) OBD-II read of ECU-registered IDs (Mazda enhanced diagnostics + ELM327; Research Task: Tire Pressure Monitoring #1 research covered this); (b) manually swap one tire at a time, note which ID starts dropping. (a) is nicer, (b) is free if you already do a tire rotation.
4. Seed sensors table with the mapping.
5. Sensors sold with rolling replacements: assume static IDs for lifetime of sensor. Add a re-map step whenever a sensor is replaced or tires rotated to a different set of rims.

Open questions

1. Hardware footprint — the original close said "not worth a dedicated Pi in the garage." Is the home-dashboard reframing enough to flip that, or are we betting there's already a host close enough (plexpi? existing Pi?) that can host the capture?
2. Vehicles in scope — all three, or start with one? Cheapest slice-1 is one vehicle on one frequency.
3. Drive-time data — parked-only misses "tire got low while driving." OK to punt (parked-only for slice 1), or is drive-time reception explicitly on the roadmap?
4. Sensor→position mapping — go with OBD-II (nicer, one-shot dongle needed) or manual-swap ritual (free, requires a tire session)?
5. Language / stack — Python (fits fuelbot/bluelinky-adjacent pattern, easy SQLite + Flask) OK? Alternative: Rust for a smaller-footprint garage-side daemon.
6. Homelab dashboard integration — is the future consumer of /api/* a new dashboard service you'll build, or does something existing already own it?

Once you answer 1–3, I can slice this into GitHub issues (capture, ingest, API, dashboard-integration) and start on slice 1.

[tclancy]

1. I think the plexpi is close enough. If not, it can be moved
2. Just the Mazda for now. Hyundai is covered well enough, Camaro is old enough it appears the TPMS have stopped working
3. No drive-time
4. Not really worried about which tire, I just want to know if any are low.
5. Don't mind either way as long as there's library support. In case you just mentioned Rust because it's in a garage :)
6. New dashboard

[metaframework-dispatch-bot]

Done: TPMS slice-1 ingest + JSON API for the 2013 CX-9 shipped as PR #11. Reads rtl_433 JSON on stdin, writes to SQLite, exposes /api/vehicles/mazda-cx9/tpms/{latest,history} + /api/health for the future home dashboard. Systemd units + install ritual for plexpi under deploy/plexpi/. 43 tests pass. Scope kept to your Q1–Q6 answers: parked-only, Mazda-only, any-tire-low, Python, new-dashboard target.