Cannot read firmware identifier from device

Question

Cannot read firmware identifier from device

eski-dev opened this issue 5 years ago · comments

root@raspberrypi:/home/pi/temper/# ./temper.py
Bus 001 Dev 005 413d:2107 TEMPerX_V3.2 Error: Unknown firmware TEMPerX.V3.2: b'80800a534e200000800109dd4e200000'
root@raspberrypi:/home/pi/temper# ./temper.py -l
Bus 001 Dev 006 413d:2107 * ['hidraw3', 'hidraw4']

Bought this "TEMPer2" off Amazon a few months back and finally got around to attempting setup. Been a bit of a headache as most software solutions don't seem to support this model. Any thoughts on resolving this issue?

Jon Krake · Answer 1 · Sat Apr 06 2019 04:04:56 GMT+0800 (China Standard Time)

I am also having this issue. It will work once, then not work 3 or 4 times, then work again.

Sometimes I get this:
./temper.py --verbose
Bus 001 Dev 007 413d:2107 None Error: Cannot read firmware identifier from device

Sometimes this:
./temper.py --verbose
Firmware value: b'6c645f56332e3120'
Data value: b'80800bbe4e200000'
Bus 001 Dev 007 413d:2107 ld_V3.1 Error: Unknown firmware ld_V3.1: b'80800bbe4e200000'

Toorr · Answer 2 · Fri Jun 14 2019 00:51:07 GMT+0800 (China Standard Time)

Hi,

Did anyone found a solution to this issue?

I'm having the exact same behaviour as @1024jon

Thanks

Psykus · Answer 3 · Tue Jun 25 2019 04:49:50 GMT+0800 (China Standard Time)

@1024jon @Toorr Are both of you also using a Raspberry Pi? I've had the Temper device for a while and used it previously on a desktop PC install of Ubuntu and never had any issues. But now when I try to use it with a Raspberry Pi 2 I am having the same firmware identifier issue. Sometimes the temper script reads the temperature successfully but I will then get errors 10 times in a row.

I figured it might be a power supply issue so I tried a couple of different ones (1.8A, and an Anker multi USB port power supply with 2.8A per outlet) with the same issue. I still think it could be limited to the RPI but not sure, just trying to help narrow down the issue.

Jon Krake · Answer 4 · Tue Jun 25 2019 05:13:41 GMT+0800 (China Standard Time)

Hey, I am using it on a Pi 3 B+. Ive tried multiple all with the same result. I couldn't seem to find a correlation or a reliable way to make it work every time.

Toorr · Answer 5 · Tue Jun 25 2019 23:34:06 GMT+0800 (China Standard Time)

Hey,

I'm using a Pi 3 as well. I monitor the temperature with Zabbix and then to a graph and I get the error every 3-4min approximately for like one minute then I receive the actual value again, really strange.

Jon Krake · Answer 6 · Wed Jun 26 2019 04:01:38 GMT+0800 (China Standard Time)

Yep I am doing the same thing. These temper things worked fine until they changed the internals or whatever they did a few months ago.

Nigel Stewart · Answer 7 · Sun Nov 17 2019 15:48:12 GMT+0800 (China Standard Time)

I think I'm seeing something similar, but on a Linux PC, and only on the USB3 port.
It alternates between reporting TEMPerX_V3.3 and V3.3 as the firmware version.
Interestingly it doesn't seem to matter the time between queries.

$ sudo ./temper.py --verbose
{'vendorid': 16701, 'productid': 8455, 'manufacturer': '', 'product': '', 'busnum': 3, 'devnum': 4, 'devices': ['hidraw6', 'hidraw7']}
Firmware query: b'0186ff0100000000'
Firmware value: b'54454d506572585f56332e3320202020' TEMPerX_V3.3    
Data query: b'0180330100000000'
Data value: b'8001096c4e200000'
Bus 003 Dev 004 413d:2107 TEMPerX_V3.3 24.12C 75.42F - - - -

$ sudo ./temper.py --verbose
{'vendorid': 16701, 'productid': 8455, 'manufacturer': '', 'product': '', 'busnum': 3, 'devnum': 4, 'devices': ['hidraw6', 'hidraw7']}
Firmware query: b'0186ff0100000000'
Firmware value: b'56332e3320202020' V3.3    
Data query: b'0180330100000000'
Data value: b'800109794e200000'
Bus 003 Dev 004 413d:2107 V3.3 24.25C 75.65F - - - -

Looking at usbmon it appears that sometimes we get back 8 bytes + 8 bytes for "TEMPerX_V3.3"

ffff8bbf12568480 3499963474 S Ii:3:003:2 -115:8 8 <
ffff8bbd78c23600 3500020088 S Io:3:003:2 -115:8 8 = 0186ff01 00000000
ffff8bbd78c23600 3500027267 C Io:3:003:2 0:8 8 >
ffff8bbf12568480 3500031178 C Ii:3:003:2 0:8 8 = 54454d50 6572585f
ffff8bbf12568480 3500031194 S Ii:3:003:2 -115:8 8 <
ffff8bbf12568480 3500103256 C Ii:3:003:2 0:8 8 = 56332e33 20202020
ffff8bbf12568480 3500103275 S Ii:3:003:2 -115:8 8 <
ffff8bbed5d0dcc0 3500203547 S Io:3:003:2 -115:8 8 = 01803301 00000000
ffff8bbed5d0dcc0 3500211199 C Io:3:003:2 0:8 8 >
ffff8bbf12568480 3500287173 C Ii:3:003:2 0:8 8 = 800109c4 4e200000
ffff8bbf12568480 3500287190 S Ii:3:003:2 -115:8 8 <
ffff8bbf12568480 3500388291 C Ii:3:003:2 -2:8 0

..but otherwise we only get the second 8 bytes for "V3.3"

ffff8bbf12568480 3490849699 S Ii:3:003:2 -115:8 8 <
ffff8bbec3e66780 3490908167 S Io:3:003:2 -115:8 8 = 0186ff01 00000000
ffff8bbec3e66780 3490914470 C Io:3:003:2 0:8 8 >
ffff8bbf12568480 3490990481 C Ii:3:003:2 0:8 8 = 56332e33 20202020
ffff8bbf12568480 3490990500 S Ii:3:003:2 -115:8 8 <
ffff8bbec3e66780 3491090818 S Io:3:003:2 -115:8 8 = 01803301 00000000
ffff8bbec3e66780 3491098487 C Io:3:003:2 0:8 8 >
ffff8bbf12568480 3491174555 C Ii:3:003:2 0:8 8 = 800109c4 4e200000
ffff8bbf12568480 3491174573 S Ii:3:003:2 -115:8 8 <
ffff8bbf12568480 3491275613 C Ii:3:003:2 -2:8 0

Perhaps for 413d:2107 we should expect 16-bytes in total and retry a few times?

Nigel Stewart · Answer 8 · Sun Nov 17 2019 17:49:19 GMT+0800 (China Standard Time)

I implemented retrying up to ten times and filed #16

Feedback welcome, please include specifics of devices that work or not.

Brian Ealdwine · Answer 9 · Sun Dec 15 2019 06:46:18 GMT+0800 (China Standard Time)

I don't think you should use #16. I think there are effectively two separate bugs here:

Bug 1: The hardware is slow as heck, or has some other issue that causes a very slow response.
Bug 2: The hardware sometimes sends the wrong firmware ID.

My fixes are this:

After writing to the device, wait a full additional tenth of a second (!). This provides a consistent response for me.
On my system, if V3.3 is found, I change it back to TEMPerX_V3.3, and make a python warning about it. This keeps the warning on stderr, and so it doesn't interfere with using temper.py in a script reading stdout.

Brian Ealdwine · Answer 10 · Mon Dec 16 2019 08:46:36 GMT+0800 (China Standard Time)

I have created PR #19 to address the two issues with the following:

select call time is increased to 0.2 from 0.1
When hardware 413d:2107 is present and V3.3 is the firmware, warn, and use TEMPerXV3.3 instead.

This prevents both the "Cannot read firmware identifier from device" issue and the "Unknown firmware: ..." issue.

However, the workaround for the latter could later be determined to be weak, if we find out that other versions of the hardware/firmware also produce "V3.3" instead of the proper string. In that case, it may just be better to retry instead of producing an error or assuming the firmware ID based on the presence of the bug.

Nigel Stewart · Answer 11 · Mon Dec 16 2019 09:23:41 GMT+0800 (China Standard Time)

Indeed, that was the rationale for #16, it does respond appropriately around half of the time, retrying a few times seems fine in practice.

Brian Ealdwine · Answer 12 · Tue Dec 17 2019 01:38:27 GMT+0800 (China Standard Time)

#16 simply doesn't address the "Cannot read firmware identifier" issue. It does, however, address the "unknown firmware" issue which you mentioned.

If you're trying to reproduce the original issue, the 'Cannot read firmware identifier' issue is very prevalent when using 1-second polling.

With your PR, use the following script in Xonsh to run it every second:

import time

while True:
    python3 ./temper.py
    time.sleep(1)

..I consistently get the "Cannot read device firmware identifier" issue -- more than 50% of the time. I do not get the alternating firmware identifiers issue, so your pull does seem to address that issue.

I do think you're right that retrying is better for the "unknown firmware" issue. My PR previously warned and assumed the version, but a simple retry isn't enough to warn about. In light of that, I've switched #19 to use a simple recursive retry.

tmo26 · Answer 13 · Sat Dec 21 2019 19:56:43 GMT+0800 (China Standard Time)

I implemented retrying up to ten times and filed #16
Feedback welcome, please include specifics of devices that work or not.

Tried today with 0c45:7401 TEMPer2_M12_V1.3 (white plastic case) and with/without your retry implementation. Here is the result:

pi@rpi2:~/nigels/temper_retry $ sudo ./temper.py --verbose
Firmware query: b'0186ff0100000000'
Firmware value: b'54454d506572325f4d31325f56312e33' TEMPer2_M12_V1.3
Data value: b'800417b012702e33'
Bus 001 Dev 036 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'800417b012702e33'

before retry-implementation:

pi@rpi2:~/nigels/temper $ sudo ./temper.py
Bus 001 Dev 036 0c45:7401 None Error: Cannot read firmware identifier from device
pi@rpi2:~/nigels/temper $ sudo ./temper.py
Bus 001 Dev 036 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'8004178011c02e33'
pi@rpi2:~/nigels/temper $ sudo ./temper.py
Bus 001 Dev 036 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'8004178011c02e33'
pi@rpi2:~/nigels/temper $ sudo ./temper.py
Bus 001 Dev 036 0c45:7401 None Error: Cannot read firmware identifier from device
pi@rpi2:~/nigels/temper $ sudo ./temper.py
Bus 001 Dev 036 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'8004178011c02e33'

after retry-implementation:

pi@rpi2:~/nigels/temper_retry $ sudo ./temper.py
Bus 001 Dev 036 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'800417a012302e33'
pi@rpi2:~/nigels/temper_retry $ sudo ./temper.py
Bus 001 Dev 036 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'800417a012302e33'
pi@rpi2:~/nigels/temper_retry $ sudo ./temper.py
Traceback (most recent call last):
  File "./temper.py", line 432, in <module>
    sys.exit(temper.main())
  File "./temper.py", line 425, in main
    results = self.read(args.verbose)
  File "./temper.py", line 342, in read
    results.append({ **info, **usbread.read() })
  File "./temper.py", line 269, in read
    return self._read_hidraw(self.device)
  File "./temper.py", line 177, in _read_hidraw
    firmware = self._read_hidraw_firmware(fd, self.verbose)
  File "./temper.py", line 157, in _read_hidraw_firmware
    raise RuntimeError('Cannot read device firmware identifier')
RuntimeError: Cannot read device firmware identifier
pi@rpi2:~/nigels/temper_retry $ sudo ./temper.py
Bus 001 Dev 036 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'800417a012302e33'
pi@rpi2:~/nigels/temper_retry $ sudo ./temper.py
Traceback (most recent call last):
  File "./temper.py", line 432, in <module>
    sys.exit(temper.main())
  File "./temper.py", line 425, in main
    results = self.read(args.verbose)
  File "./temper.py", line 342, in read
    results.append({ **info, **usbread.read() })
  File "./temper.py", line 269, in read
    return self._read_hidraw(self.device)
  File "./temper.py", line 177, in _read_hidraw
    firmware = self._read_hidraw_firmware(fd, self.verbose)
  File "./temper.py", line 157, in _read_hidraw_firmware
    raise RuntimeError('Cannot read device firmware identifier')
RuntimeError: Cannot read device firmware identifier

Nigel Stewart · Answer 14 · Wed Dec 25 2019 10:41:04 GMT+0800 (China Standard Time)

Interesting.
I did a similar stability check of #16 PR on my Linux PC, seems fine.
The #19 PR also worked just fine on this setup.

I also have an RPi1 and a 3B+ which I will also try for 413d:2107.

$ while true; do sudo ./temper.py; sleep 1; done
Bus 003 Dev 011 413d:2107 TEMPerX_V3.3 24.1C 75.3F - - - -
Bus 003 Dev 011 413d:2107 TEMPerX_V3.3 24.2C 75.5F - - - -
Bus 003 Dev 011 413d:2107 TEMPerX_V3.3 24.1C 75.4F - - - -
Bus 003 Dev 011 413d:2107 TEMPerX_V3.3 24.1C 75.4F - - - -
Bus 003 Dev 011 413d:2107 TEMPerX_V3.3 24.1C 75.4F - - - -
Bus 003 Dev 011 413d:2107 TEMPerX_V3.3 24.1C 75.4F - - - -
...

Nigel Stewart · Answer 15 · Wed Dec 25 2019 11:17:56 GMT+0800 (China Standard Time)

For a second round of testing of both #16 and #19 on Raspberry Pi model B.

$ rev=$(awk '/^Revision/ { print $3 }' /proc/cpuinfo) && curl -L perturb.org/rpi?rev=$rev
Revision : 000f
Model    : B
Memory   : 512 MB
Overvolt : No
Released : Q4 2012
Notes    : (Mfg by Qisda)

I found that PR #16 is stable for select >= 0.2
I found that PR #19 is stable for select >= 0.4

I agree that both easing the select timeout and retrying seem necessary for 413d:2107 to work on slower hardware platforms.

I've updated PR #16 accordingly.

In a nutshell #16 is being more generous about retrying and #19 is being more generous about timing out on the select. Being generous "enough" for both of these seems appropriate to me.

Comment: Perhaps it would be better to test again with the system under CPU and/or IO load.

Brian Ealdwine · Answer 16 · Fri Jan 03 2020 07:26:13 GMT+0800 (China Standard Time)

I'll retry #16 and see if it works for me -- thanks for your work, @nigels-com.

Brian Ealdwine · Answer 17 · Fri Jan 03 2020 07:30:32 GMT+0800 (China Standard Time)

#16 works for me now, I'm good with it. I think this bug can be counted as fixed -- excepting perhaps the possibility, as @nigels-com said, that it fails under high load, which I haven't tested.

I'll withdraw my PR as #16 works fine now.

Brian Ealdwine · Answer 18 · Sat Jan 04 2020 00:48:18 GMT+0800 (China Standard Time)

@tmo26 can you confirm that the issue is addressed in #16 now?

Brian Ealdwine · Answer 19 · Sat Jan 18 2020 14:20:17 GMT+0800 (China Standard Time)

No response for 15 days, and this looks fixed by #16 to me.

Brian Ealdwine · Answer 20 · Wed Nov 04 2020 02:45:00 GMT+0800 (China Standard Time)

This issue can be closed.

tmo26 · Answer 21 · Wed Nov 25 2020 00:57:26 GMT+0800 (China Standard Time)

Sorry for the late reply :(

Still the same with the latest temper.py

pi@rpi2:~/temper-py_new $ sudo ./temper.py
Bus 001 Dev 005 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'800418d0ffff2e33'
pi@rpi2:~/temper-py_new $ sudo ./temper.py
Traceback (most recent call last):
  File "./temper.py", line 432, in <module>
    sys.exit(temper.main())
  File "./temper.py", line 425, in main
    results = self.read(args.verbose)
  File "./temper.py", line 342, in read
    results.append({ **info, **usbread.read() })
  File "./temper.py", line 269, in read
    return self._read_hidraw(self.device)
  File "./temper.py", line 177, in _read_hidraw
    firmware = self._read_hidraw_firmware(fd, self.verbose)
  File "./temper.py", line 157, in _read_hidraw_firmware
    raise RuntimeError('Cannot read device firmware identifier')
RuntimeError: Cannot read device firmware identifier
pi@rpi2:~/temper-py_new $ sudo ./temper.py
Bus 001 Dev 005 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'800418d0ffff2e33'
pi@rpi2:~/temper-py_new $ sudo ./temper.py
Bus 001 Dev 005 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'800418d0ffff2e33'
pi@rpi2:~/temper-py_new $ sudo ./temper.py
Bus 001 Dev 005 0c45:7401 TEMPer2_M12_V1.3 Error: Unknown firmware TEMPer2_M12_V1.3: b'800418d0ffff2e33'
pi@rpi2:~/temper-py_new $

Brian Ealdwine · Answer 22 · Wed Nov 25 2020 05:16:55 GMT+0800 (China Standard Time)

@tmo26 Are you using master, or the version on PyPI?

Edit: Actually, that version isn't even supported. I mean, the traceback shouldn't occur, which is a recurrence of the issue, but the latter three tries are an indicator that the device isn't supported. You should open a separate issue for that device.

Brian Ealdwine · Answer 23 · Sun Nov 29 2020 11:41:14 GMT+0800 (China Standard Time)

@tmo26 will you open an issue on ccwienk/temper?

tmo26 · Answer 24 · Tue Dec 01 2020 01:34:36 GMT+0800 (China Standard Time)

@tmo26 Are you using master, or the version on PyPI?

Master of urwen/temper produced the output shown above

@tmo26 will you open an issue on ccwienk/temper?

I would like to, but how do I create an Issue when there is no "Issues" button visible?

Brian Ealdwine · Answer 25 · Thu Dec 03 2020 03:52:45 GMT+0800 (China Standard Time)

Good point. I'll talk to the repo's owner, I'm just a maintainer.

…

On Mon, Nov 30, 2020 at 12:34 PM tmo26 ***@***.***> wrote: @tmo26 <https://github.com/tmo26> Are you using master, or the version on PyPI? Master of urwen/temper produced the output shown above @tmo26 <https://github.com/tmo26> will you open an issue on ccwienk/temper <https://github.com/ccwienk/temper>? I would like to, but how do I create an Issue when there is no "Issues" button visible? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAS4PT5VKD52PZ7SV7AVCJ3SSPJTXANCNFSM4G7AGCLQ> .

Brian Ealdwine · Answer 26 · Sat Dec 05 2020 01:12:18 GMT+0800 (China Standard Time)

@tmo26 There you go.