Reverse-engineered another TPMS sensor type ("WODHMIEY", APP: "ITPMS (K)")

[mf76130]

I got new sensor, did add them to HA using my Shelly BT and a script on it, maybe you want to add them for others into your system.
AI did make a summary of what we did and what might be helpful for you:

Reverse-engineered another TPMS sensor type ("WODHMIEY", app "ITPMS (K)")

Product

• Seller/Brand: WODHMIEY
• Product: "TPMS Tire Pressure Monitoring System Motorcycle/Car" (Amazon.de, ASIN B0GWH88YSV)
• Companion app: ITPMS (K) (Android package name starts with com.zl.dev.tire.itpms)
• Sensor marking: Each sensor has a QR code sticker printed with a plain-text ID (e.g. 305DBE), which is scanned for pairing. This ID shows up identically as the device name in the app ("Front wheel-305DBE") and matches the first 3 bytes of the BLE MAC address.

Important: the kit contains two different chip types!

The kit ships with at least two different BLE implementations that look identical but speak completely different protocols:

1. "Woan" type (MACs b0:e9:fe:xx:xx:xx and b0:a6:04:xx:xx:xx): Manufacturer Data company ID 0x0969 (Woan Technology, Shenzhen — the same manufacturer behind SwitchBot). Structure closely resembles SwitchBot's officially documented format (Flags + Manufacturer Data with embedded MAC + Service Data UUID 0xFD3D). Key finding: over several hours and multiple full pressure cycles (0 → 2.4 bar), not a single byte changes except a rolling counter. Live readings clearly are not present in the advertisement for this type — likely only retrievable via a (possibly encrypted) GATT connection. Not analyzed further.

2. "305DBE" type (MAC 30:5d:be:11:11:11, i.e. a fixed 11:11:11 suffix — looks like an OEM default address rather than a randomized one): this is the type that actually carries live readings in the advertisement! Described in detail below.

This issue covers only type 2 ("305DBE").

Advertisement structure (type "305DBE")

Example raw packet (full hex string, as output by a Bluetooth scanner):

0201060303b0fb12ffac00c03e54000a17008d28111111be5d30

Breakdown into AD structures:

Bytes	Meaning
02 01 06	Flags: LE General Discoverable, BR/EDR Not Supported
03 03 b0fb	Complete List of 16-bit Service UUIDs: 0xFBB0
12 ff ac00 [...] 11 11 11 be 5d 30	Manufacturer Specific Data (Length 0x12, Type 0xFF)

Temperature formula (confirmed twice)

Temperature(°C) = U2(decimal) − 55

Confirmed data points:

• U2 = 0x54 (84) → 84−55 = 29 °C ✓ (app showed 29 °C)
• U2 = 0x56 (86) → 86−55 = 31 °C ✓ (app showed 31 °C)

Pressure formula (preliminary, only 2 calibration points)

Pressure(bar) ≈ (U7(decimal) − 2) / 103

Calibration points:

• Stable "near-0-bar" state (repeated identically 3×) → U7 = 0x02 (2) → 0.00 bar (tire was effectively deflated)
• Stable state after refilling → formula yielded 2.41 bar, app showed 2.4 bar at the same time (0.01 bar off)

This formula is only roughly calibrated (linear, 2 points, no guarantee for higher pressures or edge cases). Additional calibration points over time would help refine it or reveal a non-linear relationship.

Behavioral note: caching while stationary

While the vehicle is stationary, the sensor keeps re-sending the same (stale) reading for extended periods (observed: up to ~1 hour), even if the actual pressure changed in the meantime. It only takes a fresh measurement after (presumed) vibration/movement or some internal wake-up interval. While actively working on the tire (deflating/inflating), updates were noticeably more frequent (seconds to a few minutes). This is harmless for home automation purposes (pressure barely changes while parked), but important to know when calibrating.

Open questions

• Meaning of U0, U1, U3, U5 not determined (likely status/alarm/battery flags)
• Battery level not decoded
• Pressure formula calibrated with only 2 points — additional reference measurements at other pressures would be valuable
• The pairing QR code printed on each sensor was not analyzed further — might be relevant for a GATT connection/encryption, but wasn't needed for plain advertisement decoding

Suggestion

This format could be added as a new "Type D" (or similar) in tpms_ble, alongside the existing types A (TPMSII app), B (SYTPMS app), and C (Michelin). Detection signature: Manufacturer Data company ID 0x00AC combined with the payload structure described above (9 bytes + reversed MAC).

Happy to provide additional raw data logs (including other pressure/temperature states) if useful.

[bkbilly]

Thanks for taking the time to help me add support for these new TPMS Devices.
As I don't own a device like that, I can't be sure that it will work, so I would love your feedback on this.

[mf76130]

sure whenever you have it ready to test, tell me and i can test.

[bkbilly]

I've pushed the change and I've created a new release so you should be able to test it.

[mf76130]

you are very fast, updating and lets see whats happening

[mf76130]

i did have my logging running Temp: 32 Druck: 1.74
15:09:18

but when i try to add a device to TPM_BLE it says nothing found on the network.
These are very rarely sending data.
i'll keep an eye on it

[bkbilly]

The add device doesn't do anything. The devices are auto discovered.
Usually these sensors transmit data when the pressure changes.

[mf76130]

As we got wrong data using my script on the shelly, we (AI and me) did analyse the Android APK for these sensors, below the detailed info from AI, what should have the correct data:

New TPMS sensor type decoded ("WODHMIEY" / "Mintsy" app) — confirmed via decompiled app source

Product

• Seller/Brand: WODHMIEY
• Product: "TPMS Tire Pressure Monitoring System" for motorcycle/car (Amazon.de, ASIN B0GWH88YSV)
• Companion app: Mintsy, Android package com.zl.dev.tire.itpms
• Underlying SDK/vendor namespace: com.wicarlink.zl — this looks like a white-label SDK used across many similarly-branded TPMS apps, so this protocol is likely shared by several other rebranded products
• Sensor marking: each sensor has a QR code sticker with a plain-text ID (e.g. 305DBE) used for pairing; this ID matches both the device name shown in the app and the first 3 bytes of the BLE MAC address

How this was confirmed

Initial decoding was done by manually reverse-engineering captured advertisements and cross-checking against the app's displayed values. This worked for temperature but produced wildly inconsistent pressure readings. To resolve this, the companion app's APK was decompiled (JADX) and the actual parsing code was located and inspected. All fields below are taken directly from the app's own source, not guessed — see code excerpt at the bottom.

Advertisement structure

Example raw advertisement (full hex, as reported by a BLE scanner):

0201060303b0fb12ffac00be3356000a76009628111111be5d30

Bytes	Meaning
02 01 06	Flags: LE General Discoverable, BR/EDR Not Supported
03 03 b0fb	Complete List of 16-bit Service UUIDs: 0xFBB0 (used by the app as a quick device-recognition filter, together with the fixed prefix 0201060303B0FB)
12 ff ac00 [9 payload bytes] [6 bytes reversed MAC]	Manufacturer Specific Data (Length 0x12, Type 0xFF)

Pressure formula

if (overflow_flag == 1):
    pressure_kPa = (U1 + 256) * 3.144
else:
    pressure_kPa = U1 * 3.144
pressure_bar = pressure_kPa / 100

The "overflow flag" referenced above corresponds to a separate byte (bytes[10] in the app's own indexing) used only when pressure exceeds what a single byte can hold (~8 bar). In our own byte numbering this lines up with U6. For the normal range (well below the overflow threshold), the simplified formula is:

pressure(bar) = (U1 × 3.144) / 100

Verification

Raw payload c1 4e 58 00 0a 76 00 96 28 → U1=0x33? — using a separately captured packet be 33 56 00 0a 76 00 96 28:

• U1 = 0x33 = 51 → 51 × 3.144 = 160.3 kPa = 1.60 bar — matches the app's displayed value (1.6 bar, confirmed stable over time) ✓
• U2 = 0x56 = 86 → 86 − 55 = 31 °C — matches app ✓

Important: byte U7 ("our" indexing) is not pressure — it's a checksum!

Earlier (incorrect) reverse-engineering attempts assumed the last payload byte before the MAC carried the pressure value, which produced wildly inconsistent readings (jumping between e.g. 0.1 and 2.5 bar within seconds while the real, physical pressure was constant). This is now explained: that byte is CheckSum2, which changes whenever any other byte in the packet changes — it has no relation to the actual pressure.

Behavioral notes

• The sensor does not transmit on every BLE advertisement interval with a fresh measurement; it appears to only update around every ~1–30 minutes while the vehicle is stationary, and more frequently while in motion/vibrating.
• Status byte (U4 in our numbering) values 1 ("leakage") and 2 ("inflating") are explicitly used by the app to trigger different alarm logic, suggesting the sensor itself flags rapid pressure changes.

Suggestion for tpms_ble

This could be added as a new device type, identified by:

• Manufacturer Data company ID 0x00AC
• Fixed advertisement prefix 0201060303B0FB (Flags + Service UUID list) — used by the official app itself as the detection filter
• Payload layout and formulas as described above

Given the shared com.wicarlink.zl SDK namespace, this protocol is likely reused by other rebranded/white-label TPMS products beyond "WODHMIEY"/"Mintsy".

Happy to share additional raw captures or the relevant decompiled source snippets if useful.

[mf76130]

just 10 minutes ago, the device was discovered, but with the wrong values, i assume you did not yet update the code, but at least the device was discovered and i could add it to HA