Cannot read firmware identifier from device
eski-dev opened this issue · 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?
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'
Hi,
Did anyone found a solution to this issue?
I'm having the exact same behaviour as @1024jon
Thanks
@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.
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.
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.
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.
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?
I implemented retrying up to ten times and filed #16
Feedback welcome, please include specifics of devices that work or not.
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 toTEMPerX_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.
I have created PR #19 to address the two issues with the following:
select
call time is increased to0.2
from0.1
- When hardware
413d:2107
is present andV3.3
is the firmware, warn, and useTEMPerXV3.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.
Indeed, that was the rationale for #16, it does respond appropriately around half of the time, retrying a few times seems fine in practice.
#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.
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
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 - - - -
...
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.
I'll retry #16 and see if it works for me -- thanks for your work, @nigels-com.
#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.
No response for 15 days, and this looks fixed by #16 to me.
This issue can be closed.
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 $
@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.
@tmo26 will you open an issue on ccwienk/temper?
@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?
@tmo26 There you go.