This project is almost not working

[Tamila-2017]

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?

[Tamila-2017]

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

[fatyogi]

The read_registers operation fails. This usually happens because the device has not been connected.

You are either using a wrong driver for your USB serial adapter or the device name is incorrect in the InfluxConf.py

What is your USB adapter? Please run the following command;

ls -la /dev/tty*

And send me the output.

Thanks Olaf

// Laconic style, sent from my phone

On Sun, 28 Jul 2024 at 05:43, Tamila-2017 @.***> wrote:

Hi,

Unfortunately, this project almost does not work, because such an error constantly occurs:

` $ ./logtracer.py 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 "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 computer, but it didn't help. I do not know what caused it. Can someone tell me?

— Reply to this email directly, view it on GitHub https://github.com/fatyogi/epever-upower-tracer/issues/11, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4YYO4P6SAJMNMZBOJYOCLZOUGS3AVCNFSM6AAAAABLS43W4OVHI2DSMVQWIX3LMV43ASLTON2WKOZSGQZTGOJZHA4TCMQ . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[Tamila-2017]

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 :-(

[fatyogi]

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.

[Tamila-2017]

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?

[fatyogi]

Each adapter works differently. The byte order in the controller remains the same, of course, but the way the adapter interprets it and feeds it back into MODBUS protocol - might be different.

Honestly, I don't know anything about QinHeng - you'd be better off asking @bkuschak if you insist on using your adapter. I believe he also speaks Ukrainian or Russian, so the communication should flow a bit easier between you guys.

Alternatively, if you buy the original Epever adapter from AliExpress - the driver provided here should work out of the box.

Cheers Olaf

On Sun, 28 Jul 2024 at 11:04, Tamila-2017 @.***> wrote:

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?

— Reply to this email directly, view it on GitHub https://github.com/fatyogi/epever-upower-tracer/issues/11#issuecomment-2254644125, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4YYO5F5RX6AY2TWOJ6373ZOVMGXAVCNFSM6AAAAABLS43W4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJUGY2DIMJSGU . You are receiving this because you commented.Message ID: @.***>

[Tamila-2017]

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.

[fatyogi]

Ok, let me know how it goes. I don't think you can buy a fake one - who wants to fake a Serial adapter after all? There isn't much of a business in it.

Just make sure you specify the right device in your InfluxConf.py - if you have only one controller you should see it under /dev/ttyXRUSB0 once you install the Exar driver.

On my Solar system I have two of these controllers, so the Tracer device comes up as /dev/ttyXRUSB1

On Mon, 29 Jul 2024 at 10:09, Tamila-2017 @.***> wrote:

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.

— Reply to this email directly, view it on GitHub https://github.com/fatyogi/epever-upower-tracer/issues/11#issuecomment-2254665751, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE4YYO3GPA6KTO7KAR4BYFLZOVT3LAVCNFSM6AAAAABLS43W4OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJUGY3DKNZVGE . You are receiving this because you commented.Message ID: @.***>

[Tamila-2017]

Okay, thank you fatyogi

[bkuschak]

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 ;-)

[fatyogi]

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.

[bkuschak]

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/

[Tamila-2017]

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:

1. It is more compact, without bulky long cable:
2. Its cost is only $1 :-)
3. 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.

[Tamila-2017]

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.