TEMPer2V1.3

Interface type: HID
Common name: TEMPer2
TEMPered status: works, since 2012-08-05 (thanks to mirkt and Fishb0ne)
USB IDs: 0C45:7401
Usable interface number: 1
Manufacturer string: RDing
Product string: TEMPer2V1.3
Subtype ID: 2
Temperature sensors: 2 (internal + external) FM75
Humidity sensors: 0

---

This device has one internal and one external temperature sensor, which appear to be FM75 or compatible sensor chips.

I first heard about this subtype on 2012-03-08, when mirkt added a comment on relevak's blog, reporting that it works with a slightly modified version of Cray's pcsensor program, and included which offsets it uses.

This allowed me to add most of the code to support it, but lacked one crucial piece of information, namely how to tell it apart from the other devices with the same USB IDs. Because of that, this device was misidentified as a TEMPerV1.2 - which caused the code to believe it only had the internal sensor, but I believe otherwise worked fine (since these devices are quite similar).

That missing piece of information was provided by Fishb0ne on 2012-08-03 (in issue 6). Using that information, I changed the code to properly recognize the device, which means it now knows about (and reads) both sensors, as confirmed on 2012-08-05.

Fishb0ne's information also included the USB device strings, which led me to rename this device from TEMPer2.2 to TEMPer2V1.3, to make it easier to recognize.

---

This device is very similar to the TEMPerV1.2 device in how it works, it really just adds another sensor.

To get the temperature, query with 01 80 33 01 00 00 00 00. A typical response is 80 04 1d 10 1d 60 32 46, where the temperatures are in the third to sixth bytes.

To calculate the temperature, use the FM75 method.

The internal sensor has its high byte in offset 2 and its low byte in offset 3.

The external sensor has its high byte in offset 4 and its low byte in offset 5.

---

Like the TEMPerV1.2 device, this device responds to the same two additional (non-temperature reading) queries (at least Fishb0ne's did).

The first query, 01 82 77 01 00 00 00 00 (which is now used for identification), gave the response 82 02 00 00 1d 60 32 46, where it seems the first four bytes are significant - as the last four are the same as what was returned from the last temperature query.

This strengthens my theory that the second byte gives the length of the valid data in the response - but both bytes are zero, so I still don't know their meaning.

The second, meanwhile, gave similar but not identical responses as the TEMPerV1.2: writing 01 86 ff 01 00 00 00 00 gave these responses:
54 45 4d 50 65 72 32 46 followed by
31 2e 31 50 65 72 32 46.