This project is almost not working
Opened this issue · 14 comments
Hi,
Unfortunately, this project almost does not work, because such an error constantly occurs:
Traceback (most recent call last):
File "/home/pi/epever-upower-tracer/SolarTracer.py", line 219, in readCurrent
regs = self.instrument.read_registers(blk, numreg, 4)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/minimalmodbus.py", line 927, in read_registers
returnvalue = self._generic_command(
^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/minimalmodbus.py", line 1276, in _generic_command
payload_from_slave = self._perform_command(functioncode, payload_to_slave)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/minimalmodbus.py", line 1359, in _perform_command
payload_from_slave = _extract_payload(
^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/minimalmodbus.py", line 1904, in _extract_payload
raise InvalidResponseError(text)
minimalmodbus.InvalidResponseError: Checksum error in rtu mode: b'~\x00' instead of b'\xea\x99' . The response is: b'~\x00\x00\x19\x87\x00\x00-\xcf\x00\x00\xb1\xd7~\x00\x00\x19\x87\x00\x00-\xcf\x00\x00\xb1\xd7~\x00\x00\x19\x87\x00\x00-\xcf\x00\x00\xb1\xd7~\x00' (plain response: b'~\x00\x00\x19\x87\x00\x00-\xcf\x00\x00\xb1\xd7~\x00\x00\x19\x87\x00\x00-\xcf\x00\x00\xb1\xd7~\x00\x00\x19\x87\x00\x00-\xcf\x00\x00\xb1\xd7~\x00')
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/pi/epever-upower-tracer/./logtracer.py", line 16, in <module>
"fields": tracer.readCurrent()
^^^^^^^^^^^^^^^^^^^^
File "/home/pi/epever-upower-tracer/SolarTracer.py", line 222, in readCurrent
print("Failed to read %d registers at 0xX from %s" % (numreg, blk1, self.device), file=sys.stderr)
^^^^
NameError: name 'blk1' is not defined. Did you mean: 'blk'?
I tried to install this project on another Raspberry, but it didn't help.
But sometimes there is no mistake, she occurs chaotically:
./logtracer.py
ERROR: Failed to read from 0x331B
[{'measurement': 'solar', 'time': datetime.datetime(2024, 7, 28, 16, 4, 14, 866115), 'fields': {'PVvolt': 14.65, 'PVamps': 0.69, 'PVwatt': 10.13, 'BAvolt': 13.16, 'BAamps': 0.77, 'BAwatt': 10.13, 'DCvolt': 13.16, 'DCamps': 3.53, 'DCwatt': 46.45, 'BAtemp': 32.33, 'CTtemp': 39.7, 'BAperc': 82.0}}]
I do not know what caused it. Can someone tell me?
I have additionally enabled debugging mode in the file /logtracer.py:
./logtracer.py
DEBUG: successfully connected to /dev/ttyUSB0
DEBUG: Local time 21:50:01 , UTC timestamp 2024-07-28 18:50:01.599058
DEBUG reading 18 registers starting at 0x3100 from /dev/ttyUSB0
Traceback (most recent call last):
File "/home/pi/epever-upower-tracer/SolarTracer.py", line 219, in readCurrent
regs = self.instrument.read_registers(blk, numreg, 4)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/minimalmodbus.py", line 927, in read_registers
returnvalue = self._generic_command(
^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/minimalmodbus.py", line 1276, in _generic_command
payload_from_slave = self._perform_command(functioncode, payload_to_slave)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/minimalmodbus.py", line 1353, in _perform_command
response_bytes = self._communicate(request_bytes, number_of_bytes_to_read)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/pi/.local/lib/python3.11/site-packages/minimalmodbus.py", line 1521, in _communicate
raise NoResponseError("No communication with the instrument (no answer)")
minimalmodbus.NoResponseError: No communication with the instrument (no answer)
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/home/pi/epever-upower-tracer/./logtracer.py", line 17, in <module>
"fields": tracer.readCurrent()
^^^^^^^^^^^^^^^^^^^^
File "/home/pi/epever-upower-tracer/SolarTracer.py", line 222, in readCurrent
print("Failed to read %d registers at 0xX from %s" % (numreg, blk1, self.device), file=sys.stderr)
^^^^
NameError: name 'blk1' is not defined. Did you mean: 'blk'?
DEBUG: successfully disconnected /dev/ttyUSB0
Please:
pi@solar:~ $ lsusb
Bus 001 Device 002: ID 1a86:7523 QinHeng Electronics CH340 serial converter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
I'm using ttyUSB0:
crw-rw-rw- 1 root tty 5, 0 Jul 28 22:58 /dev/tty
crw--w---- 1 root tty 4, 0 Jul 28 22:58 /dev/tty0
crw--w---- 1 root tty 4, 1 Jul 28 22:58 /dev/tty1
crw--w---- 1 root tty 4, 10 Jul 28 22:58 /dev/tty10
crw--w---- 1 root tty 4, 11 Jul 28 22:58 /dev/tty11
crw--w---- 1 root tty 4, 12 Jul 28 22:58 /dev/tty12
crw--w---- 1 root tty 4, 13 Jul 28 22:58 /dev/tty13
crw--w---- 1 root tty 4, 14 Jul 28 22:58 /dev/tty14
crw--w---- 1 root tty 4, 15 Jul 28 22:58 /dev/tty15
crw--w---- 1 root tty 4, 16 Jul 28 22:58 /dev/tty16
crw--w---- 1 root tty 4, 17 Jul 28 22:58 /dev/tty17
crw--w---- 1 root tty 4, 18 Jul 28 22:58 /dev/tty18
crw--w---- 1 root tty 4, 19 Jul 28 22:58 /dev/tty19
crw--w---- 1 root tty 4, 2 Jul 28 22:58 /dev/tty2
crw--w---- 1 root tty 4, 20 Jul 28 22:58 /dev/tty20
crw--w---- 1 root tty 4, 21 Jul 28 22:58 /dev/tty21
crw--w---- 1 root tty 4, 22 Jul 28 22:58 /dev/tty22
crw--w---- 1 root tty 4, 23 Jul 28 22:58 /dev/tty23
crw--w---- 1 root tty 4, 24 Jul 28 22:58 /dev/tty24
crw--w---- 1 root tty 4, 25 Jul 28 22:58 /dev/tty25
crw--w---- 1 root tty 4, 26 Jul 28 22:58 /dev/tty26
crw--w---- 1 root tty 4, 27 Jul 28 22:58 /dev/tty27
crw--w---- 1 root tty 4, 28 Jul 28 22:58 /dev/tty28
crw--w---- 1 root tty 4, 29 Jul 28 22:58 /dev/tty29
crw--w---- 1 root tty 4, 3 Jul 28 22:58 /dev/tty3
crw--w---- 1 root tty 4, 30 Jul 28 22:58 /dev/tty30
crw--w---- 1 root tty 4, 31 Jul 28 22:58 /dev/tty31
crw--w---- 1 root tty 4, 32 Jul 28 22:58 /dev/tty32
crw--w---- 1 root tty 4, 33 Jul 28 22:58 /dev/tty33
crw--w---- 1 root tty 4, 34 Jul 28 22:58 /dev/tty34
crw--w---- 1 root tty 4, 35 Jul 28 22:58 /dev/tty35
crw--w---- 1 root tty 4, 36 Jul 28 22:58 /dev/tty36
crw--w---- 1 root tty 4, 37 Jul 28 22:58 /dev/tty37
crw--w---- 1 root tty 4, 38 Jul 28 22:58 /dev/tty38
crw--w---- 1 root tty 4, 39 Jul 28 22:58 /dev/tty39
crw--w---- 1 root tty 4, 4 Jul 28 22:58 /dev/tty4
crw--w---- 1 root tty 4, 40 Jul 28 22:58 /dev/tty40
crw--w---- 1 root tty 4, 41 Jul 28 22:58 /dev/tty41
crw--w---- 1 root tty 4, 42 Jul 28 22:58 /dev/tty42
crw--w---- 1 root tty 4, 43 Jul 28 22:58 /dev/tty43
crw--w---- 1 root tty 4, 44 Jul 28 22:58 /dev/tty44
crw--w---- 1 root tty 4, 45 Jul 28 22:58 /dev/tty45
crw--w---- 1 root tty 4, 46 Jul 28 22:58 /dev/tty46
crw--w---- 1 root tty 4, 47 Jul 28 22:58 /dev/tty47
crw--w---- 1 root tty 4, 48 Jul 28 22:58 /dev/tty48
crw--w---- 1 root tty 4, 49 Jul 28 22:58 /dev/tty49
crw--w---- 1 root tty 4, 5 Jul 28 22:58 /dev/tty5
crw--w---- 1 root tty 4, 50 Jul 28 22:58 /dev/tty50
crw--w---- 1 root tty 4, 51 Jul 28 22:58 /dev/tty51
crw--w---- 1 root tty 4, 52 Jul 28 22:58 /dev/tty52
crw--w---- 1 root tty 4, 53 Jul 28 22:58 /dev/tty53
crw--w---- 1 root tty 4, 54 Jul 28 22:58 /dev/tty54
crw--w---- 1 root tty 4, 55 Jul 28 22:58 /dev/tty55
crw--w---- 1 root tty 4, 56 Jul 28 22:58 /dev/tty56
crw--w---- 1 root tty 4, 57 Jul 28 22:58 /dev/tty57
crw--w---- 1 root tty 4, 58 Jul 28 22:58 /dev/tty58
crw--w---- 1 root tty 4, 59 Jul 28 22:58 /dev/tty59
crw--w---- 1 root tty 4, 6 Jul 28 22:58 /dev/tty6
crw--w---- 1 root tty 4, 60 Jul 28 22:58 /dev/tty60
crw--w---- 1 root tty 4, 61 Jul 28 22:58 /dev/tty61
crw--w---- 1 root tty 4, 62 Jul 28 22:58 /dev/tty62
crw--w---- 1 root tty 4, 63 Jul 28 22:58 /dev/tty63
crw--w---- 1 root tty 4, 7 Jul 28 22:58 /dev/tty7
crw--w---- 1 root tty 4, 8 Jul 28 22:58 /dev/tty8
crw--w---- 1 root tty 4, 9 Jul 28 22:58 /dev/tty9
crw------- 1 root root 5, 3 Jul 28 22:58 /dev/ttyprintk
crw-rw---- 1 root dialout 188, 0 Jul 28 23:16 /dev/ttyUSB0
Or this:
./logtracer.py
DEBUG: successfully connected to /dev/ttyUSB0
DEBUG: Local time 23:52:01 , UTC timestamp 2024-07-28 20:52:01.399680 |
DEBUG reading 18 registers starting at 0x3100 from /dev/ttyUSB0
DEBUG Registers: [4, 0, 0, 0, 1345, 0, 0, 0, 1345, 422, 5675, 0, 1345, 422, 5675, 0, 2990, 3089]
ERROR: Failed to read from 0x311A
ERROR: Failed to read from 0x331B
[{'measurement': 'solar', 'time': datetime.datetime(2024, 7, 28, 20, 52, 1, 399680), 'fields': {'PVvolt': 0.04, 'PV
amps': 0.0, 'PVwatt': 0.0, 'BAvolt': 13.45, 'BAamps': 0.0, 'BAwatt': 0.0, 'DCvolt': 13.45, 'DCamps': 4.22, 'DCwatt'
: 56.75, 'BAtemp': 29.9, 'CTtemp': 30.89}}]
DEBUG: successfully disconnected /dev/ttyUSB0
The work is unstable :-(
I see, you are using the QinHeng USB adapter, not the EPEVER (Exar) USB adapter this project is designed for:
https://www.epever.com/product/150u-accessories-communication-cable/
Please talk to @bkuschak who managed to get QinHeng adaptor to work by altering the code of the Exar driver provided in this project - apparently the QinHeng uses another byte order. He should be able to give you the code for the driver suitable for QinHeng.
Alternatively, you can buy the Epever Exar adapter from the link above, or just search for "CC-USB-RS485-150U" on AliExpress.
apparently the QinHeng uses another byte order.
Thank you, but I'm extremely surprised - can the adapter change the byte order???
It's just a voltage levels converter, isn't it?
It turns out that our local stores sell a lot of "CC-USB-RS485-150U PC Communication Cable" at different prices.
Unfortunately, it is not known whether they are original or fakes.
First, I'll try to buy one of these and test it.
Okay, thank you fatyogi
I did not see any issues with byte order when using the QinHeng USB adapter. I'd be surprised if your controller is swapping bytes, since a UART is byte-oriented. I did not have to swap bytes to get it working. My addition for QinHeng support was only one line - just to recognize its VID:PID.
However, I did see occasional problems with read errors. IIRC, when I inspected it with an oscilloscope, there were two back-to-back transfers that occurred with very little delay in between, and the EpEver didn't respond to the second one. This was many months ago and I don't recall any more about the details, sorry. You might try modifying your code to retry failures or add a delay after each transaction.
I've switched away from USB and I'm using the SoC hardware UART on my platform at this point. It has been working stably for me. My fork is 23 commits behind the upstream master, JFYI. https://github.com/bkuschak/epever-upower-tracer/blob/master/logtracer_csv.py
And sorry, no I do not speak Ukrainian or Russian ;-)
Hey, I'm sorry @bkuschak if I misrepresented you :) I don't know why, but I'm getting a lot of requests about this particular QinHeng adapter you experimented with, and I remember you submitted a patch at some point that did something with the byte order - Epever uses 16-bit and 32-bit registers, so I guess the idea is not too far fetched. I did not adopt that patch btw because it felt like it would break the Exar adapter driver.
Anyway, my project recommendeds using the Exar adapter which comes natively with Epever products.
Can you please tell me how did you get one of the QinHeng adapters and why you preferred it over Epever? It looks like not all adapters are made equal.
No worries. Are you maybe thinking about someone else's PR? My PR only had two lines of code - one to recognize the VID:PID for QinHeng, and one for adding a definition for the ControllerTemperature register. https://github.com/fatyogi/epever-upower-tracer/pull/7/commits
I made various other changes in my fork but it wasn't my intention to submit those in a PR. I don't recall doing anything with byte order.
I bought the EpEver MPPT controller and this USB cable at the same time from the same vendor on Amazon. It was advertised as the official EPEVER cable. https://www.amazon.com/gp/product/B07BLQ7Q5B/
Thank you all for your discussion! :-)
Can you please tell me how did you get one of the QinHeng adapters and why you preferred it over Epever? It looks like not all adapters are made equal.
There are thtee reasons:
- It is more compact, without bulky long cable:
- Its cost is only $1 :-)
- But the most important reason is that he did not did not require this compilation: it started working right away:
After installing the headers - do make and sudo make install in the respective driver directory. The resulting xr_usb_serial_common.ko driver file will be moved to /lib/modules/YOUR_LINUX_KERNEL_VERSION/tty/serial.
You have discussed several options different solutions to this problem, thank you.
But I'm In some confusion because I don't know which one is better to choose, which will really work well and don't create problems.