The USB ID Matched. The Sensor Chip Didn't.
What actually happened reviving a decade-old sensor from the parts box
The Problem
Years ago, when I did astrophotography from a Windows machine, I used a TEMPerHUM: a USB stick with a temperature and humidity sensor inside, meant to log conditions alongside a night of imaging. At some point the software stopped getting updates and the device went in a box. PCsensor's last official Windows release for this device line, version 24.5, shipped December 2016. The sensor itself dates to around 2011. Nothing had touched either side of that pairing in roughly a decade.
The stick ended up plugged into PiPiece, the astrophotography rig this project runs. Nothing read it. Reviving it looked like a straightforward reverse-engineering job: find the command bytes, decode the response, done.
The Insight
The command bytes weren't the interesting part, and I want to be straight about that rather than overclaim it. Sending 01 80 33 01 00 00 00 00 to query the sensor turned out to be exactly what's hardcoded in urwen/temper, a Linux driver with history stretching back years, and the same family of command used by edorfaus/TEMPered. That sequence is a long-established community standard. I didn't discover it.
What actually mattered was narrower, and it only showed up once I went looking for whether prior art existed at all. This device's USB ID, 0c45:7402, isn't one sensor. TEMPered's own device list marks that ID "works probably" for something it calls TEMPer2HumiV1.x, built around a Sensirion SHT1x chip, with its own formula coefficients. A separate issue on that same project documents another device answering to the identical USB ID, called TEMPerHumM12V1.2, built around a completely different chip (a Si7006) with a completely different formula. I queried my own stick's firmware identity live off the wire and got a third string, TEMPerHumV1.1, that doesn't exactly match either of those, or any case branch in urwen's driver. Three names, three chips, three formulas, one USB ID.
That's the actual trap. Grabbing whichever open-source driver claims to support 0c45:7402 and trusting its output would have been a coin flip on whether it happened to be the right sensor generation for this specific stick.
What I Built
Rather than match on the USB ID and hope, I read the device's own firmware string, confirmed it didn't match a known profile, and derived the decode from the live response itself: repeated queries, checked the values held steady the way a real sensor reads (not the way a misread offset flickers), and cross-checked the result against that day's outdoor weather log before trusting it. That became a small Python reader talking straight to /dev/hidraw, wired into a Node cache, into every capture's metadata sidecar, into the stacked FITS header, and into a status panel that distinguishes "no sensor" from "sensor present and not answering."
The Takeaway
The sensor still works because USB HID never stopped being USB HID; a class-compliant device from 2011 enumerates on a 2026 kernel the same way it enumerated on Windows 7, no vendor driver required. That part really is just old hardware outliving its software. But the lesson worth keeping is narrower and less flattering than "I cracked an undocumented protocol": a shared USB ID is not a shared protocol, three genuinely different sensor chips can hide behind the same four hex digits, and the only way to know which one you're holding is to ask the device itself what it says its name is.
The full protocol notes, the firmware-string comparison, and the working integration are in the PiPiece repo, linked below.
Built with Claude Code, reviewed by me.