Reading logger gives struct.error

[stretch4x4]

I am getting the following traceback when trying to read one of my dataloggers currently. I think I have seen similar previously but usually rerunning my script solves it. However, the same logger fails on both get_data() and get_devinfo() currently repeatedly.

Traceback (most recent call last):
  File ".\build_excel - Copy.py", line 23, in <module>
    for row in device.get_data():
  File "C:\Python27\lib\site-packages\elitech\__init__.py", line 120, in get_data
    devinfo = self.get_devinfo()
  File "C:\Python27\lib\site-packages\elitech\__init__.py", line 94, in get_devinfo
    res = self._talk(req, DevInfoResponse(self.encode))
  File "C:\Python27\lib\site-packages\elitech\__init__.py", line 68, in _talk
    response.read(self._ser)
  File "C:\Python27\lib\site-packages\elitech\msg.py", line 222, in read
    res)
struct.error: unpack requires a string argument of length 160

Not sure if a newer version of pyserial would help as it seems quite old?
If there is any other information I can provide to help debug this, let me now.

[stretch4x4]

Not sure what has changed (other than a lot more data points) but the script ran fine this morning.
So I won't be able to reproduce this bug reliably anymore.

[BjornFJohansson]

I now have the same problem... I reinitialized on a windows computer and it seems to work fine....

06:46 $ elitech-datareader --command devinfo --encode=utf8 /dev/serial/by-id/usb-1a86_USB_Serial-if00-port0
Traceback (most recent call last):
  File "/home/bjorn/anaconda3/envs/elitech-datareader/bin/elitech-datareader", line 8, in <module>
    sys.exit(main())
  File "/home/bjorn/anaconda3/envs/elitech-datareader/lib/python3.9/site-packages/scripts/elitech_device.py", line 27, in main
    command_devinfo(args)
  File "/home/bjorn/anaconda3/envs/elitech-datareader/lib/python3.9/site-packages/scripts/elitech_device.py", line 152, in command_devinfo
    dev_info = device.get_devinfo()
  File "/home/bjorn/anaconda3/envs/elitech-datareader/lib/python3.9/site-packages/elitech/__init__.py", line 94, in get_devinfo
    res = self._talk(req, DevInfoResponse(self.encode))
  File "/home/bjorn/anaconda3/envs/elitech-datareader/lib/python3.9/site-packages/elitech/__init__.py", line 68, in _talk
    response.read(self._ser)
  File "/home/bjorn/anaconda3/envs/elitech-datareader/lib/python3.9/site-packages/elitech/msg.py", line 194, in read
    alarm, temp_unit, temp_calib, humi_upper_limit, humi_lower_limit, _, humi_calib, _) = unpack(
struct.error: unpack requires a buffer of 160 bytes

[akeonly]

I have the same problem, I used to be able to download data from RC5 with elitech-datareader command.
*I'm on ubuntu

~$ elitech-datareader --command get /dev/ttyUSB0 > fan_replacement.txt
Traceback (most recent call last):
File "/usr/local/bin/elitech-datareader", line 8, in
sys.exit(main())
File "/usr/local/lib/python3.8/dist-packages/scripts/elitech_device.py", line 23, in main
command_get(args)
File "/usr/local/lib/python3.8/dist-packages/scripts/elitech_device.py", line 68, in command_get
device.get_data(callback=output)
File "/usr/local/lib/python3.8/dist-packages/elitech/init.py", line 120, in get_data
devinfo = self.get_devinfo()
File "/usr/local/lib/python3.8/dist-packages/elitech/init.py", line 94, in get_devinfo
res = self._talk(req, DevInfoResponse(self.encode))
File "/usr/local/lib/python3.8/dist-packages/elitech/init.py", line 68, in _talk
response.read(self._ser)
File "/usr/local/lib/python3.8/dist-packages/elitech/msg.py", line 194, in read
alarm, temp_unit, temp_calib, humi_upper_limit, humi_lower_limit, _, humi_calib, _) = unpack(
struct.error: unpack requires a buffer of 160 bytes

[BjornFJohansson]

Mine stopped working after using the windows software that you can download from the elitech site. Perhaps it updates the reader somehow. Now it only works with their software on windows.

[PhilipPlant]

Everything was working well last week under Ubuntu 20.04, now this happens with a week's worth of data (325 log entries):

$ elitech-datareader --command devinfo --value_only /dev/ttyUSB0 
Traceback (most recent call last):
  File "/usr/local/bin/elitech-datareader", line 8, in <module>
    sys.exit(main())
  File "/usr/local/lib/python3.8/dist-packages/scripts/elitech_device.py", line 27, in main
    command_devinfo(args)
  File "/usr/local/lib/python3.8/dist-packages/scripts/elitech_device.py", line 152, in command_devinfo
    dev_info = device.get_devinfo()
  File "/usr/local/lib/python3.8/dist-packages/elitech/__init__.py", line 94, in get_devinfo
    res = self._talk(req, DevInfoResponse(self.encode))
  File "/usr/local/lib/python3.8/dist-packages/elitech/__init__.py", line 68, in _talk
    response.read(self._ser)
  File "/usr/local/lib/python3.8/dist-packages/elitech/msg.py", line 194, in read
    alarm, temp_unit, temp_calib, humi_upper_limit, humi_lower_limit, _, humi_calib, _) = unpack(
struct.error: unpack requires a buffer of 160 bytes

No huge changes that I can think of to have created this issue. I've popped the battery on the logger (RC-5), tried a simple-set etc with same error message, but the error persists.

Any ideas would be greatly appreciated, thanks!

[BjornFJohansson]

@PhilipPlant, you can try the windows software from the website.
http://www.elitechlog.com/softwares
I would love to have this working again on linux, but I do not know how to even begin.

[skgrange]

Hello,
I too would like to flag that my Ubuntu 20.04 system is now raising a struct.error when I try and get the data from the sensor. The error is the same as above, a buffer issue. A dump is below:

# Get the observations from the sensor
elitech-datareader --command get /dev/ttyUSB0

Traceback (most recent call last):
  File "/home/stuart/.local/bin/elitech-datareader", line 8, in <module>
    sys.exit(main())
  File "/home/stuart/.local/lib/python3.8/site-packages/scripts/elitech_device.py", line 23, in main
    command_get(args)
  File "/home/stuart/.local/lib/python3.8/site-packages/scripts/elitech_device.py", line 68, in command_get
    device.get_data(callback=output)
  File "/home/stuart/.local/lib/python3.8/site-packages/elitech/__init__.py", line 120, in get_data
    devinfo = self.get_devinfo()
  File "/home/stuart/.local/lib/python3.8/site-packages/elitech/__init__.py", line 94, in get_devinfo
    res = self._talk(req, DevInfoResponse(self.encode))
  File "/home/stuart/.local/lib/python3.8/site-packages/elitech/__init__.py", line 68, in _talk
    response.read(self._ser)
  File "/home/stuart/.local/lib/python3.8/site-packages/elitech/msg.py", line 194, in read
    alarm, temp_unit, temp_calib, humi_upper_limit, humi_lower_limit, _, humi_calib, _) = unpack(
struct.error: unpack requires a buffer of 160 bytes

Any ideas what has changed to cause this issue? Many thanks,
Stuart.

[tictactux]

I think it's an "incompatibility" with the pyserial package - the interface name was not properly called:
in .../dist-packages/elitech/__init__py, lines 40 ff read:

class Device:
def init(self, serial_port, baudrate=115200, timeout=5):
if serial_port is not None:
self._ser = serial.Serial(serial_port, baudrate=baudrate, timeout=timeout) <---- this one!
self._ser.close()
self.debug = False
self.wait_time = 0.5
self.encode = 'utf8'

Replace "serial.Serial(serial_port, ....)" with "serial.Serial(port=serial_port, ....)" and everything will be good.

EDIT: False Alarm. It's still shaky. I wonder if accessing the port via PHP might yield different results (is it the port, or is it the implementation...) Sigh.

[skgrange]

Hello tictactux,
I was just looking at this and made the change, purged the old version, and installed the updated package version. Like you have added in your edit, the same issue remains. I might have to do some digging!

[tictactux]

Hi Stuart, I tried the same under some Debian where it worked, and on FreeBSD (on the very same PC) and I got no result. Same via cutecom, so I start to think it's the usb-serial kernel module for that specific uart that is acting up... Best, Ben Stuart Grange ***@***.***> schrieb am Fr., 5. Nov. 2021, 15:55:

…

Hello tictactux, I was just looking at this and made the change, purged the old version, and installed the updated package version. Like you have added in your edit, the same issue remains. I might have to do some digging! — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWLMNMG6JV7634273L5GNGLUKPV4LANCNFSM4GRHSZNQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[civic]

I checked RC-4 on ubuntu 20.04. It works well. What device did you all use? RC-4/5? (NOTICE RC-5+ *Plus* doesn't work)

$ lsb_release -a
No LSB modules are available.
Distributor ID:	Ubuntu
Description:	Ubuntu 20.04.2 LTS
Release:	20.04
Codename:	focal

$ elitech-datareader -c devinfo /dev/ttyUSB0 
alarm=AlarmSetting.NONE
current=2021-11-09 18:58:26
delay=0.0
dev_num=123456789
humi_calibration=0.0
humi_lower_limit=0.0
humi_upper_limit=0.0
last_online=2021-11-09 18:53:38
lower_limit=-10.0
model_no=40
rec_count=0
rec_interval=00:00:10
start_time=2021-11-09 16:41:06
station_no=0
stop_button=StopButton.ENABLE
temp_calibration=0.0
temp_unit=TemperatureUnit.C
tone_set=ToneSet.NONE
upper_limit=80.0
user_info=info
work_sts=WorkStatus.NOT_START

@BjornFJohansson

Mine stopped working after using the windows software that you can download from the elitech site. Perhaps it updates the reader somehow. Now it only works with their software on windows.

I already have ElitechLog Win v6.1.0. After using the ElitechLog, the elitech-datareader still worked well.
ElitechLog shows the Firmware version. It shows V1.0. Could you check the Firmware vision?

[BjornFJohansson]

I have V1.3 of the firmware, Version V6.2.0 of the software

[BjornFJohansson]

[tictactux]

I have Software 6.2 and Firmware 1.3. Best, Ben Björn Johansson ***@***.***> schrieb am Mi., 10. Nov. 2021, 11:48:

…

[image: 2021-11-10] <https://user-images.githubusercontent.com/9726401/141099694-d5c973e3-dfe7-4309-8eb9-3df21a5d8f8e.jpg> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#36 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWLMNMFKZ34TB643XRWU2M3ULJEZVANCNFSM4GRHSZNQ> . Triage notifications on the go with GitHub Mobile for iOS <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675> or Android <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.

[civic]

Thank you for your information. Is the device RC-4? Mine is RC-4.
If your devices are RC-4, I will update my firmware to v1.3 and try to check whether the same problem will happen.