-
Notifications
You must be signed in to change notification settings - Fork 50
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected data from device (data[4] = fb, want 0x0d) #41
Comments
I don't have the device, so it's unlikely that I'll be able to add support of the new revision. I'll keep this issue open, maybe someone else will be able to reverse engineer the protocol. |
How should one reverse-engineer the new protocol? install usb filter driver on windows and dump the communications? |
There is no ready-to-go solution. You can use everything you have: find something from the producer or analyse what you already have. Dumping the communications might be a good starting point. |
I can share ssh (raspberry pi) with connected new device, if you can make update and may be it can helps you: https://medgadgets.ru/wp-content/uploads/2015/03/AN135-CO2mini-usb-protocol.zip |
There is not easy, but very good workaround. I soldered pins to serial port inside device and connected Wemos D1 Mini in 3d printed case with esphome firmware. It seems protocol at serial port not changed, works very good and adds wireless functionality, easy integrate with home assistant. I prefer this solution :) |
I've mailed ZyAura last week but got no response. Seems like sniffing the communications of the windows software is the only option now to make it work through its USB port. |
You may want to read https://hackaday.io/project/5301-reverse-engineering-a-low-cost-usb-co-monitor. I'm almost sure you'll need IDA Pro. |
Guys, I've just bought the device off dadget.ru (AKA masterkit.ru) and got the same error message. Have looked into the protocol, and it turns out we just don't need decode_buf for this device. Replaced it with memcpy and voila! |
Here you go: tobotras/co2mon@c60a11b |
you are my hero! |
@tobotras nice, I didn't expect they are making devices without this encoding. Thank you, I added your commit to master. Can you attach output of |
@dmage, many thanks for the tool, to start from! Here you go: Bus 001 Device 012: ID 04d9:a052 Holtek Semiconductor, Inc. USB-zyTemp |
There is a way in doing guesswork trying with and without encoding :-D |
Try this patch:
Device: mt8057s |
See dmage#41 for details
See dmage#41 for details
So this is equivalent to tobotras' change referenced in a comment posted one year before yours - that was merged into master, at that time. |
FWIW, the 'TFA AIRCO2NTROL MINI CO2 Monitor' (EAN 4009816027351, Kat.-Nr. 31.5006.02, ID-NR. 31.010 180, recently bought from Amazon.de) also only works without decoding, i.e. with It would be great if co2mond would auto-detect new-style devices, i.e. ones where the data isn't encoded. Especially since the for those device required
That means a new user basically has to find this issue in order to use this software. Perhaps we are lucky and the release_number and or the serial_number USB device attribute are unique between new -style and old-style devices. My device shows:
Perhaps somebody with access to an old-style device can share their relase_number/serial_number attributes. Alternatively, the next best thing would be an auto-detection. Last but not least a small hint in the |
My old-style device:
|
This looks promising, i.e. we have:
(where serial_number == iSerial and release_number == bcdDevice) Thus, one could use either of those to automatically switch decoding on/off. I'm leaning towards release_number. Of course, one could still provide |
That means, by default, co2mon uses the USB device's release number to auto-detect whether deoding/descrambling of the payload is necessary. fixes dmage#41
It seems there is new revision of ZGm053U hardware with new protocol, bought at dadget.ru. Doesn't works with apps from dadget.ru, but works with latest windows software from http://www.zyaura.com/
Does anyone have the same problems? Is there any chance to implement new protocol?
The text was updated successfully, but these errors were encountered: