Add support for ThermoPro TP862b Wireless Dual-Probe Thermometer

[n6ham]

Add support for ThermoPro TP862b TempSpike XR 1,000-ft Wireless Dual-Probe Meat Thermometer.

https://buythermopro.com/products/tp862b-tempspike-xr-wireless-meat-thermometer

Correctness of the data format verified using two different devices with 2 probes for each.

Output sample:

{"time" : "2026-01-28 19:47:48", "model" : "ThermoPro-TP862b", "id" : 54, "color" : "black", "is_docked" : 1, "temperature_int_C" : 16.700, "temperature_amb_C" : 20.100, "flags" : 31, "mic" : "CRC"}
{"time" : "2026-01-28 19:47:49", "model" : "ThermoPro-TP862b", "id" : 197, "color" : "white", "is_docked" : 1, "temperature_int_C" : 17.000, "temperature_amb_C" : 17.100, "flags" : 25, "mic" : "CRC"}
{"time" : "2026-01-28 19:47:51", "model" : "ThermoPro-TP862b", "id" : 54, "color" : "black", "is_docked" : 0, "temperature_int_C" : 16.800, "temperature_amb_C" : 21.400, "flags" : 31, "mic" : "CRC"}
{"time" : "2026-01-28 19:47:54", "model" : "ThermoPro-TP862b", "id" : 197, "color" : "white", "is_docked" : 0, "temperature_int_C" : 17.000, "temperature_amb_C" : 18.400, "flags" : 25, "mic" : "CRC"}
{"time" : "2026-01-28 19:48:30", "model" : "ThermoPro-TP862b", "id" : 197, "color" : "white", "is_docked" : 1, "temperature_int_C" : 17.200, "temperature_amb_C" : 26.600, "flags" : 25, "mic" : "CRC"}
{"time" : "2026-01-28 19:48:31", "model" : "ThermoPro-TP862b", "id" : 54, "color" : "black", "is_docked" : 1, "temperature_int_C" : 26.200, "temperature_amb_C" : 20.000, "flags" : 31, "mic" : "CRC"}
{"time" : "2026-01-28 19:49:30", "model" : "ThermoPro-TP862b", "id" : 76, "color" : "black", "is_docked" : 1, "temperature_int_C" : 16.900, "temperature_amb_C" : 19.800, "flags" : 31, "mic" : "CRC"}
{"time" : "2026-01-28 19:49:33", "model" : "ThermoPro-TP862b", "id" : 10, "color" : "white", "is_docked" : 1, "temperature_int_C" : 17.100, "temperature_amb_C" : 21.400, "flags" : 26, "mic" : "CRC"}
{"time" : "2026-01-28 19:49:37", "model" : "ThermoPro-TP862b", "id" : 76, "color" : "black", "is_docked" : 0, "temperature_int_C" : 16.900, "temperature_amb_C" : 20.800, "flags" : 31, "mic" : "CRC"}
{"time" : "2026-01-28 19:49:40", "model" : "ThermoPro-TP862b", "id" : 10, "color" : "white", "is_docked" : 0, "temperature_int_C" : 17.100, "temperature_amb_C" : 21.700, "flags" : 26, "mic" : "CRC"}
{"time" : "2026-01-28 19:50:26", "model" : "ThermoPro-TP862b", "id" : 76, "color" : "black", "is_docked" : 1, "temperature_int_C" : 17.100, "temperature_amb_C" : 21.500, "flags" : 31, "mic" : "CRC"}
{"time" : "2026-01-28 19:50:26", "model" : "ThermoPro-TP862b", "id" : 10, "color" : "white", "is_docked" : 1, "temperature_int_C" : 17.200, "temperature_amb_C" : 21.000, "flags" : 26, "mic" : "CRC"}

[zuckschwerdt]

Very well written, thanks!

• "Docked" likely should be a (bool) int, e.g. int is_docke = (probe & 0x40) >> 4; ... DATA_INT, is_docked,
• "internal_C" and "ambient_C" should conform to other temperature keys, maybe "temperature_int_C" and "temperature_amb_C" or like other existing keys: "temperature_1_C", "temperature_2_C"

[zuckschwerdt]

If I understand correctly you get two wireless probes for one set, right? If both are sending you would get alternating values in the temperature fields and would need to sort them by color when displaying?
Perhaps the keys should be per probe, e.g. "temperature_w_amb_C", "temperature_w_int_C", "temperature_b_amb_C", "temperature_b_int_C" -- or some other scheme with short keys, I guess 1 and 2 won't do as there is no way to know which one would be 1...).
That way logging will always get stable values on four temperature "channels".
In that case remove the "color" key and output the temps conditional with DATA_COND.

[n6ham]

If I understand correctly you get two wireless probes for one set, right? If both are sending you would get alternating values in the temperature fields and would need to sort them by color when displaying? Perhaps the keys should be per probe, e.g. "temperature_w_amb_C", "temperature_w_int_C", "temperature_b_amb_C", "temperature_b_int_C" -- or some other scheme with short keys, I guess 1 and 2 won't do as there is no way to know which one would be 1...). That way logging will always get stable values on four temperature "channels". In that case remove the "color" key and output the temps conditional with DATA_COND.

Very good point. As a first time contributor - I really appreciate suggestions!

UPD: added color back to have something to identify the probe not through the presence of the temp fields in the payload

[zuckschwerdt]

The decoder looks good to me. Last suggestion would be to remove the "color" output, it will toggle and not be a good fit for e.g. time series DB. If really needed the sending probe can be identified by the docked and temperature keys already.

[zuckschwerdt]

To put it antother way, imagine a display in e.g. Home Assistant, would a field of black/white be useable?
We use a similar approach with e.g. weather stations that split values into different messages: we don't report the message type but only the values.

[n6ham]

@zuckschwerdt here's my rationale around this. Please let me know if I'm overthinking it

1. It makes perfect sense to maintain 1 message per 1 device and make various readouts conditional.
   For example - I have a Maverick XR-50 thermometer with 4 wired probes that can be disconnected from the main unit.
   From the rtl_433's perspective - signal comes from 1 device - the base station, which may or may not carry readout for any of the 4 probes.

2. ThermoPro TP862b is different in this regard because the head unit does not transmit anything - it's a "dumb" receiver with display. The two probes are completely independent from each other and from the head unit too. Either one or both probes can be used without the head unit and as far as I can tell - their payload doesn't have any information about whether they are being "listened" by the same or different head units. Thus in this case - it's more semantically correct to treat them as two independent devices producing two independent messages, instead of two partial messages associated with the same device.

3. Having a "color" value in the message allows me to publish messages coming from either probe into color-specific MQTT topic on HA. Having separate topics allows me to avoid "overwriting" data from the other probe (given that we probably should not color-code each and every output, including id).

We use a similar approach with e.g. weather stations that split values into different messages: we don't report the message type but only the values.

Imo, this isn't a proper analogy, since the two probes are independent. It just happens so that they are sold in b+w pairs with a display unit, but nothing prevents you from using one or more probes from another set. I.e. a proper analogy would be two weather stations and whether we should or should not combine their readouts in the same message.

I'd prefer to have the color in the message, since it has a practical value in HA/MQTT setup. Although, I see a situation when someone won't need to sort the messages by the color code and would rather publish them into the same topic. In such case - we probably should color-code all device specific values (including id)?

WDYT?

[zuckschwerdt]

Okay, makes sense to see it as two independent sensors. The "Color" should be part of the ID then -- which I now see is already the case.
Sorry for the confusion, if the two sensors do not share anything not even the ID then treat it as if it's two distinct instances.
Remove any color prefix from the keys (like you had before...) and provide the color key as a convenience to recognize the IDs. Sorry again, I hadn't inspected your output samples careful enough.

[n6ham]

The "Color" should be part of the ID then -- which I now see is already the case.

Technically, the "color" bit is a part of the second byte (b[1]) in the payload, whereas id is the first byte (byte[0]). It looks like id doesn't change, so it's a proper HW identifier of a particular probe. The reason why I think the color bit isn't a part of the id - the second byte also contains the docked/undocked bit, which does change. So, the id can be used to discriminate two different hardware probes, but it doesn't carry information about probe's color.

Sorry again, I hadn't inspected your output samples careful enough.

No worries! Thank you for looking into this.

I will update the code and update the output sample in the description later today, when I get back home from work (I'm in PST tz)

[n6ham]

Hello @zuckschwerdt ,

I've updated the code & verified the output (it's in the PR description).
Ready for review