Protocol reverse engineered from real captures and analysis in
https://github.com/merbanan/rtl_433/issues/2133 and the earlier
https://groups.google.com/g/rtl_433/c/VJSPl7h0848 thread, re-derived from
scratch and cross-checked against 18 real messages from 3 independent
devices (ID, level, and battery-low all confirmed; no whole-message
checksum found). RF timing (short_width/long_width) is a best estimate
from real captures in both threads, not live-verified end-to-end -- see
file header.
Protocol reverse engineered from real captures and analysis linked in
https://github.com/merbanan/rtl_433/issues/1951 (dottoreD/rtl_433_tests)
and cross-checked against 963 real examples (927 Learn + 36 On/Off), plus
independently confirmed action codes from crasu/gnu-heating. Modulation
timing is a best estimate (see file header) pending live hardware or a
raw capture that decodes end-to-end.
https://github.com/merbanan/rtl_433/issues/2014: the protocol was fully
reverse-engineered in the issue (OOK PPM timing, checksum, 2's-complement
temperature confirmed via a freezer test, battery-low bit confirmed via
an old-vs-fresh-battery comparison, even a working Arduino sketch) but
never ported into rtl_433 before the reporter lost interest.
Verified against all of the issue's distinct examples via -y, including
a low-battery reading and a second physical unit from a neighbor's
device. One correction: the original post's "-22.6 C" label for one
capture doesn't match the checksum-verified 2's-complement decode (which
gives +22.6 C) -- that label predates the freezer test that established
the actual encoding, so it looks like an early mislabeling rather than a
real discrepancy.
The wire checksum is only 4 bits, too weak to reject noise reliably on
its own -- enabling this against the full rtl_433_tests corpus produced
two dozen false positives on unrelated weather-sensor protocols with
similar OOK/PPM timing. Added a flags-nibble check and a plausible
temperature range, both satisfied by every real capture available, which
eliminates all of them.
https://github.com/merbanan/rtl_433/issues/2025: same SP372-chip-family
OOK/Manchester encoding as tpms_imars_t240.c (#1820, confirmed the same
by @zuckschwerdt in comment #34). Unlike #1820, this issue has real
device-display PSI/C readings paired with raw codes, which is what lets
this one be an actual verified decoder instead of a guess.
B3/B4 are still an affine function of B0, and temperature/pressure follow
the same byte-sum shape guessed for #1820: temperature_C = temp_offset -
(B2+B5)%256, pressure_kPa = (pressure_offset - (B5+B6)%256) * 2.5. Two
physical units are confirmed, each with its own checksum and offsets
(0xfb: 224/273, 0x64: 153/201), both fit against real ground truth in
the issue: 9/10 and 3/3 distinct temperatures match exactly, pressure
matches within ~0.5 PSI (manual gauge reading precision).
https://github.com/merbanan/rtl_433/issues/1820: OOK, Manchester encoded,
50 us half-bit signal mistaken for XOR/stream-cipher encryption for years,
since only a tail-byte and a low-nibble check were ever confirmed.
B3 and B4 are each an affine function of B0 (B3 = B0 - k1, B4 = k2 - B0),
making (B3 + B4) mod 256 a fixed per-unit checksum. Two physical sensor
units are confirmed in the issue's captures, with checksums 0x41 and
0x3c; both are recognized here.
Verified against all 9 real packets in samples2.zip plus 37 codes derived
from a separate text dump in the issue, cross-checked byte-for-byte
against the community's own manual decode posted in the thread.
No temperature/pressure mapping: no capture in the issue pairs a raw code
with a numeric ground-truth reading, so only the validated raw code is
output for now.
Per maintainer feedback, one decoder shouldn't emit multiple protocol
interpretations of the same payload under one model key:
https://github.com/merbanan/rtl_433/issues/1734#issuecomment-4957207247
schrader_SMD3MA4 and the new schrader_NIS315G3 share the same wire-format
decode (checksum, flags, id) via a common helper, differing only in
pressure scale (/5 vs /4) and model name. Both are enabled by default,
so a single physical transmission produces two output records; use -R
to select just one if that's undesirable.
FSK_PCM, 200us bit width, aa2dd4 sync word, byte-add checksum. Protocol
fully reverse-engineered by the community in
https://github.com/merbanan/rtl_433/issues/1757 (solved since 2021, but
never turned into a compiled decoder). Verified against the reporter's
real captures and cross-checked against their transmitter's own serial
console output, which matches digit for digit. Registered as protocol
351.
Adapts the decoder from PR #3568 by Paul Antaki. Shares the Govee FSK
envelope reverse-engineered by Reece Neff for the H5059 (PR #3493):
sync word 2c 4c 4a, 128-byte XOR key, CRC-16/AUG-CCITT.
Both probe temperatures and humidity are packed into one 32-bit
little-endian word by the device's own firmware: 11 bits each for
probe1/probe2 (0.1 C/count, zero-anchored at -40 C) and 10 bits for
humidity (0.1%/count). Confirmed by dumping and disassembling the
H5112's FR8016HA firmware -- it contains a sensor-packing function
with this exact symmetric layout. Probe 2 is read directly as an
absolute value like probe 1: no per-device state, no wrap-count
tracking, no cold-start dependency.
Two frame types: msg_class 0x13 periodic report (~10 min interval,
full sensor data + 10-entry history buffer at ~1-minute intervals) and
msg_class 0x71 triggered status response (reply to gateway poll, same
sensor fields, no history).
Beyond the original PR, two guards make the separation from the other
Govee-family decoders structural rather than priority-dependent:
each msg_class must carry its exact documented payload length (57 or
28 bytes), and frames whose humidity decodes above 100% RH are
rejected -- the latter is the mirror of H5310's dec[9] == 0xff status
check, since a genuine H5310 status reply always decodes here as an
impossible 102.3% RH. Priority ordering (5, between H5310's 0 and
H5059's 10) remains as belt-and-braces only.
Verified against all 3 real captures from the companion
rtl_433_tests#505 PR -- two room-temperature devices (one with the
history buffer) and one fridge/freezer device (probe1 ~2.3 C, probe2
~-24.0 C) -- all match exactly. Also verified the H5310 status frames
that previously double-decoded as garbage H5112 records (102.3% RH)
under -y are now rejected by the humidity guard. Full local regression
suite: no new false positives.
Adapts the decoder from PR #3564 by Paul Antaki. The H5310 shares the
Govee FSK framing reverse-engineered by Reece Neff for the H5059 water
leak detector (PR #3493): sync word 2c 4c 4a, 128-byte XOR key, and
CRC-16/AUG-CCITT. This adds the four H5310-specific payload layouts:
- Temperature Update (LL=0x10): forced report or unit-change action
- Periodic Update (LL=0x3d): autonomous ~10-minute broadcast
- Status Reply (LL=0x1f): response to a gateway poll
- Ping (LL=0x1c): connectivity heartbeat, no temperature/battery data
Temperature formula T_C = (raw - 33168) / 10.0, confirmed against the
sensor's own display across two physical units (Pool and Spa) at
multiple temperatures. Wire encoding is always Celsius regardless of
the display unit setting.
Runs at default priority (0); H5059 runs at priority 10 so H5310 claims
shared-envelope frames first (see the companion commit for that fix).
Reviewed in the original PR by neffrw (the H5059 decoder's author).
Verified against all 7 real captures from the companion
rtl_433_tests#503 PR, across both physical units (Pool id_wire
0xf8a79cb2, Spa id_wire 0x71b09cb2) and all 4 frame types -- all match
exactly. Full local regression suite: no new false positives.
Adapts the decoder from PR #3561 by Steven Bontius, who reverse
engineered the protocol (documented at
https://github.com/StevenBontius/watts-wfht-ha/blob/main/docs/WATTS_WFHT_RF_PROTOCOL.md)
for a newer, LCD-display generation of Watts underfloor heating
thermostat -- unrelated to the existing watts_thermostat.c decoder,
which targets an older ADEV-based generation with a completely
different protocol (PWM vs. this one's Manchester, different frame
layout, no CRC-16).
Verified against:
- The 2 worked examples in the protocol doc (independently recomputed
both CRC-8 and CRC-16/CMS in Python against the documented
parameters; both check out).
- All 3 real captures from the companion rtl_433_tests#502 PR (pairing,
on, off) -- decode correctly, including the ~2 Hz pairing cadence,
the A-B-A setpoint jitter around a real transition, and the 0.0 C
setpoint on the "off" capture.
Full local regression suite: no new false positives.
Adapts the decoder from PR #3446 by Jacob Maxa, who reverse engineered
the protocol for 5 related sensors in TFA's ID+ series (30.3901.02,
30.3902.02, 30.3905.02, 30.3906.02, 30.3908.02) and confirmed the
CRC-32 parameters with the maintainer.
Fixes found while investigating the PR (which is still open, blocked
on unaddressed review feedback):
- The preamble/length bounds check compared the found sync offset
against a fixed bit-length constant instead of the actual row length.
This wrongly rejected valid short frames (30/24 bytes) unless enough
trailing bits happened to be present for the longest 36 byte variant,
and never actually verified the full frame fit in the row before
reading it. Now reads the length byte first and validates against
the row length directly.
- The "model" data line used a runtime-built string; project convention
(enforced by tests/symbolizer.py) requires a fixed string per model.
ID-A0/ID-A6 share an identical frame layout, so they're merged into
one switch case reporting both "model" lines guarded by DATA_COND
(the same pattern used throughout fineoffset.c, oregon_scientific.c,
and ~17 other decoders for same-layout model variants); ID-A3/A4/A5
have genuinely different field sets, so each keeps its own data_make()
call.
- Humidity lost its decimal digit through a plain int cast; kept as a
scaled double like temperature.
- A stray nibble of the status byte had leaked into the printed id
string; now a clean 4-byte/8-hex-char id.
- crc32_reveng() wasn't static, and used a #include "logger.h" +
print_logf() instead of decoder_log().
No raw .cu8 captures were available to verify this decoder against
(checked both this repo and rtl_433_tests), but the PR's own doc-comment
included 6 worked examples (hand-transcribed hex for ID-A0/A3/A5 and
three sequential ID-A4 readings) that all validate against the CRC-32
above -- real device data, not fabricated. The 3 ID-A4 frames are also
internally consistent as a sliding window (each one's "current" reading
matches the next frame's "1 reading ago" value), further confirming the
field layout. Verified all 6 decode correctly, plus CRC-failure and
no-preamble rejection. Full local regression suite: no new false
positives.
Adds the decoder from PR #3498, with fixes found by testing against
the real captures in rtl_433_tests#400 (all 6 captures decode exactly
matching their physical readouts):
- Fixes the 24-bit device ID: it was raw-pointer-cast into a native
uint32_t, which byte-reverses it on little-endian platforms (the
vast majority of rtl_433 users). Now extracted into a 3-byte buffer
and combined manually, matching how the temperature fields (which
already used ntohs() correctly) avoid the same class of bug.
- Fixes the dead "preamble not found" check: bitbuffer_search()
returns unsigned, so `if (offset < 0)` could never be true. Now
compares against the actual sentinel (bits_per_row[0]).
- Changes "mic" from a raw DATA_INT checksum byte to the standard
DATA_STRING "CHECKSUM", matching every other decoder's convention.
- Fixes the checksum formula (0x56 + id bytes + sum of the 8
temperature bytes) & 0xff, confirmed against all 6 real captures.
Enabled by default now that it's verified reliable.
- Adds the previously-undecoded 8 bit sequence counter (sent as a
duplicated byte, increments by 2 each repeat), gated on the row
having enough bits so short/synthetic frames still decode.
- Uses add_bytes() and decoder_log() on checksum failure, matching
sibling decoders (esun_en2053, ambientweather_wh31e).
- double -> float for the temperature accumulators.
Verified against all 6 real captures in rtl_433_tests#400 and the
full local regression suite (no new false positives).
FSK PCM with Manchester-encoded data, 10x repeated 72-bit blocks each
carrying a field ID and a 3-digit value validated by fixed position
markers. Cleans up brace/indent style and removes a dead assignment
from the original PR (merbanan/rtl_433#3443).
Verified against 18 real captures across three recording sessions
(field IDs 3, 5, 8, 14), all matching the ground truth documented in
the linked test-data repo's commit history (values stepping by 10 up
to 50).
Reworks PR #3321 (closes#2983): fixes a buffer overflow where the
10-character dipswitch string had no room for its null terminator and
bled into the adjacent factory-code buffer on every real packet, changes
id to DATA_INT per review feedback, renames dipswitches/facswitches to
dipswitch/facswitch to match the existing convention in cardin.c, and
trims the bit extraction to the 36 valid bits instead of reading 1 bit
past the row length.
Verified against 6 real captures and all 12 BitBench codes from the
issue thread.
Decoder for SmarTire TPMS sensors used on Aston Martin Vantage/DB9
vehicles (2005-2011), using OOK PCM framing with differential Manchester
coding and CRC-7 checksum validation.
Ported from merbanan/rtl_433#3072 (originally by Bruno OCTAU/ProfBoc75),
closes#3067.
Decoder for the Vivint V-DW21R-345 door/window sensor, closely related
to the Honeywell/2GIG (Ademco) 345 MHz protocol: OOK Manchester with a
0xFFFE preamble and CRC-16 based integrity check (packed 12-bit CRC for
0x7a/0x79/0x74 event frames, standard 16-bit CRC for 0xd0 power-on
frames).
Incorporates the full issue thread, including the 2026 follow-up
discussion which corrected and extended the original 2020 analysis:
- The 32 bit id decodes to the sensor's printed TXID label by splitting
it into a 12 bit and a 20 bit decimal number (confirmed against 3
independent sensors' labels).
- The counter is bytes 1-2 (not 2-3 as first guessed), confirmed against
a ~14000 message capture with a steadily incrementing count.
- The open/closed door state could not be determined: a bit that matched
the small original 2020 sample by coincidence fails on ~35% of the
larger labeled capture, and nobody in the thread found a working
formula, so it is intentionally not exposed.
- Added the 0x74 "heartbeat" event type alongside 0x7a/0x79.
Verified against all 4 raw captures plus 88 payloads transcribed from the
issue thread (all decode with valid CRC).
Closes#1504.
Generic-brand two-probe BBQ/meat thermometer, FCC ID 2APN2-EN2053,
sold e.g. as Feelle Digital Thermometer. Reverse engineered from the
captures, audio recording and annotated codes posted in the issue.
The checksum byte, unsolved in the issue thread, packs four even-parity
flags and a modulo-8 sum of the four message bytes; it matches all 37
known-good messages across both probe channels.
The BIOWIN / 2measure / Bioterm No. 270208 weather station from issue
#1476 turns out to transmit the exact Holman WS5029 older-PWM frame,
same preamble, layout and xor_shift_bytes checksum, but OOK modulated
instead of FSK. Register the existing decoder for OOK as well.
The wind direction field, unresolved in the issue, was recovered by
testing bit windows against the reporter's compass annotations and
matches the Holman layout. No barometric pressure is transmitted, the
display console likely measures it locally.
Reverse-engineered from real captures and analysis in the issue
discussion. OOK PPM, 30 bits repeated ~9 times: a 16-bit id (observed
fixed on the one unit tested), a 13-bit temperature, and a parity bit
(XOR of all 30 bits is always 1).
Source: https://github.com/merbanan/rtl_433/issues/1223
Reverse-engineered from Clayton Smith's gr-elster project and real
captures posted in the issue thread. FSK Manchester-encoded, whitened
with 0x55, CRC-16/X-25 protected. Disabled by default pending wider
field-testing; the protocol is only partially reverse-engineered
(the hourly-usage sub-command decode is a port of the reference
implementation, not independently confirmed against a real capture).
Source: https://github.com/merbanan/rtl_433/issues/1196
Decoder for the Martec MPLCD combined light dimmer/fan speed remote:
OOK PWM, 22-bit frame with a reflected/inverted channel ID, 7-bit
dimmer level, 2-bit fan speed, and a 4-bit nibble-sum checksum. The
remote holds its own state and resends the full light+fan setting on
every button press.
Ported from merbanan/rtl_433#3133 (originally by clockbrain/Don
Ashdown). Verified against the 3 sample captures from
merbanan/rtl_433_tests#474 — all decode with valid checksums and match
the documented expected values exactly (channel/speed, and a
progressive dimmer sweep for the long-press sample).
Decoder for RFXMeter/RFXPower devices, using X10RF-like PPM framing
with an address-complement check and a nibble-sum checksum.
Cleaned up and rebased from merbanan/rtl_433#2142 (originally by
Christian W. Zuckschwerdt), closes#2141. Verified against the sample
captures from that issue.
Co-authored-by: Christian W. Zuckschwerdt <christian@zuckschwerdt.org>
Decoder for the TR-502MSV remote for RC-710DX smart sockets, based on
merbanan/rtl_433#2921 by Filip Kosecek.
Applies the simplifications requested in review (direct mask/shift
field extraction instead of bit reformatting helpers, table lookups
for socket/command strings) and resolves the previously unknown 2-bit
checksum: U1 = C ^ S2 ^ S0, U0 = O ^ S1, derived from the sample table
posted in the PR discussion and verified against all 13 captured
samples in filipkosecek/rtl_433_tests#467.
Co-authored-by: Filip Kosecek <filip.kosecek@gmail.com>
Remote Grill Thermometer with probe (FCC ID TXRFPT0912), sold under
the RF-T0912 model number. Decodes a 16-bit Fahrenheit temperature
with an 8-bit checksum, repeated across multiple rows for reliable
detection, and reports an overload condition.
Co-authored-by: Ethan Halsall <ethanhalsall11@augustana.edu>
Adapted from Christian Zuckschwerdt's untested sketch in PR #3113 and
fixed/verified against real hardware captures in issue #3112 (thanks to
yashikada for testing and reporting the corrected bit layout). Supports
both of the HCS362's transmission modes: PWM (mode 0) and Manchester
(mode 1), sharing a single decode callback that branches on the demod
modulation.
Co-authored-by: Christian W. Zuckschwerdt <zany@triq.net>
Based on PR #1875: several size_t values (from strlen(), fread(),
list_t.len, struct addrinfo::ai_addrlen) were implicitly narrowed to
int/unsigned/socklen_t, which triggers MSVC C4267 warnings on x64
Windows builds. Adds explicit casts and widens a few parameter/local
types to size_t where that is the semantically correct type.
Excludes the original PR's mongoose-related mg_send() casts, and
drops two hunks (flex.c, honeywell_cm921.c) that no longer apply
since the affected code was refactored away since 2021.
Co-authored-by: obones <1314739+obones@users.noreply.github.com>
TPMS decoder for the Schrader MRXBC5A4 sensor (also sold as
MRXBMW433TX1), used on BMW vehicles. Decodes id, pressure, and
temperature, and verifies the packet's 2-bit C1C2 integrity check.
Based on merbanan/rtl_433#1702 by drid, with the C1C2 integrity
check formula derived by merbanan from RDC test tool data.
Adds an alternate decoding of the Honda/Continental KR5V2X remote as a
separate decoder alongside continental_car_remote, adapted from
gusgorman402's unmerged PR #2767 (honda_kr5vxx.c) with cleanup to match
project style. The two decoders disagree on bit layout and checksum for
the same physical hardware.
