"Found device", then no output
Hello,
when i start the binary, the only output i get is "Found device", then nothing happens. Any idea why it doesn't work?
Thanks!
Best regards, Kevin
Just now an output happend:
# ./co2monitor /dev/hidraw0
Found device
CO2(37407)
CO2(37407)
Failed to send measurement to Influx
CO2(37404)
But the values don't seem quite right. The device was built on 03/21, maybe they changed the encryption?
Quiet possible - my device is a few years older, so maybe something changed. How long did you have to wait for the output? The decrypted packages have a checksum and the implementation discards readings where the checksum didn't match. So maybe these readings are falty, but still happened to have a valid checksum by pure luck?
The first output appeared instantly ("Found device"), the output with values appeared after around 30 seconds. My device came without a manual, maybe it was used and / or is somehow faulty.
If i find something out, i will report back.
Same issue with the replaced device. They seem to have updated the firmware.
Henryk Plötz used the ZG application for windows in his blog. The software he linked (v1.0.0) doesn't work with my device, but the latest version 2.4.4.7 does work. So they must have changed something.
Similar for me - bought an TFA CO2Monitor 2021-11, plugged it in, installed hidapi via brew first, compiled the binary on my M1 Apple Silicon, executed the binary target/release/co2monitor under macOS 11.6.1, and got:
Found device
CO2(53786)
CO2(53786)
Failed to send measurement to Influx
CO2(53786)
CO2(53786)
Failed to send measurement to Influx
The hardware info returned by sysinfo on the Mac about the CO2Monitor USB device is:
Product ID: 0xa052
Vendor ID: 0x04d9
Version: 2.00
Vendor: Holtek
Sorry to hear that :-( If I find some time I might decompile the latest windows binaries and try to figure out what's going on. I don't own a newer device, so this issue is hard to track down...
No reason to be worried, you provided it kindly, it’s open source.
Any way I can help debugging this? Unexperienced with USB debugging but I have basic tech skills and with sufficient thrust I can do some gdb …
It could help to capture the traffic between the windows binary and the device. If you want to have a go at it, see https://desowin.org/usbpcap/
Contacted you via email.
Interesting... the captured data looks very familiar.
- The initialisation seems identical.
- The device seems to send the same amount of data in the same intervals
- I think even the decryption and checksum stuff is the same
So I guess they only changed the sensor/controller and it is sending data that we can't decode. Could you try to look inside which sensor they use in later models? My version could easily be opened by taking the back cover off. Inside is a ZGM053U sensor with a RAD-AP05B-QL111 Controller
Please find images attached: ZGM053U & sensor/PCB overview


The newer units report different values for iSerial and bcdDevice ...
- working unit (manufactured 11/18): lsusb-working.txt
- non-working unit (manufactured 11/21): lsusb-non-working.txt
There's no change in the data format but it turned out that the newer units do not longer "encrypt" the data. Just skip the decryption part and and have fun with the new sensor ...
diff --git a/src/zytemp.rs b/src/zytemp.rs
index 8d9ed2f..ba7111d 100644
--- a/src/zytemp.rs
+++ b/src/zytemp.rs
@@ -35,7 +35,7 @@ pub fn initialize<'a>(api: &'a hidapi::HidApi) -> hidapi::HidDevice<'a> {
pub fn read_data(device: &mut hidapi::HidDevice) -> Reading {
let mut data = [0u8; 8];
device.read(&mut data).ok();
- let decrypted = decrypt(data);
+ let decrypted = data;
validate_checksum(&decrypted).ok();
match decode(decrypted) {
@mnhauke, just tried your changes and they work with my device. Thank you!
Found device
Temperature(20.850006)
Temperature(20.912506)
CO2(831)
Temperature(20.912506)
CO2(831)
Temperature(20.912506)
CO2(831)
Ah, great catch - I'll try to come up with a version that conditionally decrypts depending on the usb meta data