flakiness, ""cleanup recv buffer before send

[joeyh]

I'm seeing fairly flaky behavior; info.py gets some info but then fails:

ReadDeviceInformationResponse(1)
Manufacturer: 'EPsolar Tech co., Ltd'
Model: 'Tracer4215BN'
Version: 'V02.14+V07.24'
Charging equipment rated input voltage = 150.0V
WARNING:pymodbus.client.sync:cleanup recv buffer before send: 0x3 0x0 0x15 0x45 0x50 0x73 0x6f 0x6c 0x61 0x72 0x20 0x54 0x65 0x63 0x68 0x20 0x63 0x6f 0x2e 0x2c 0x20 0x4c 0x74 0x64 0x1
Traceback (most recent call last):
  File "info.py", line 30, in <module>
    value = client.read_input(reg.name)
  File "/home/joey/tmp/epsolar-tracer/pyepsolartracer/client.py", line 52, in read_input
    response = self.client.read_input_registers(register.address, register.size, unit = self.unit)
  File "/usr/lib/python2.7/dist-packages/pymodbus/client/common.py", line 120, in read_input_registers
    return self.execute(request)
  File "/usr/lib/python2.7/dist-packages/pymodbus/client/sync.py", line 85, in execute
    return self.transaction.execute(request)
  File "/usr/lib/python2.7/dist-packages/pymodbus/transaction.py", line 140, in execute
    self.client.framer.processIncomingPacket(result, self.addTransaction)
  File "/usr/lib/python2.7/dist-packages/pymodbus/transaction.py", line 654, in processIncomingPacket
    self._process(callback, error=True)
  File "/usr/lib/python2.7/dist-packages/pymodbus/transaction.py", line 679, in _process
    result = self.decoder.decode(data)
  File "/usr/lib/python2.7/dist-packages/pymodbus/factory.py", line 223, in decode
    return self._helper(message)
  File "/usr/lib/python2.7/dist-packages/pymodbus/factory.py", line 245, in _helper
    response.decode(data[1:])
  File "/usr/lib/python2.7/dist-packages/pymodbus/other_message.py", line 319, in decode
    self.message_count = struct.unpack('>H', data[5:7])[0]
struct.error: unpack requires a string argument of length 2

Looking at line 319 there, data contained "Tracer", so seems was not as long as expected, or possibly not the expected value at all.

So, I tried commenting out parts of info.py, and it seems some queries work reliably. Only running the loop to display the coils works every time without errors.

The "cleanup recv buffer before send" occurs as shown above, but also often when running the loop to display the registers. An example of the error there:

Charging equipment rated input voltage = 150.0V
WARNING:pymodbus.client.sync:cleanup recv buffer before send: 0x16 0x18
Charging equipment rated input current = 40.0A
<hang>

What seems to work fairly reliably is requesting only a few values:

response = client.read_input("Charging equipment input voltage")
print str(response)
response = client.read_input("Charging equipment input current")
print str(response)

But even then, same warning message sometimes:

Charging equipment input voltage = 57.82V
WARNING:pymodbus.client.sync:cleanup recv buffer before send: 0xa2 0x1d
Charging equipment input current = 1.97A

And if I request a third value, it often hangs.

I'm using a JBtek USB to RS485 adaptor. Have the same problems with both my laptop and a cubietruck board.

[wrybread]

I had some flaky behavior before grounding the charge controller to my Pi, as described here:

https://github.com/kasbert/epsolar-tracer/issues/14

[joeyh]

Could certainly be an electrical issue; my charge controller is grounded but the cubietruck does not have a ground wire. But, my problem does not seem entirely the same as the problem you described. Our error messages are different. And, I've never needed to reboot the charge controller; when it fails like this a retry after a few seconds from a new process will always succeed.

I do occasionally get some stalls even with a 1.5 second delay in between each query. But I've been getting good data for 15 days, you can see it here: http://homepower.joeyh.name/

[wrybread]

Cool project. Nice graphs too. How many watts of panels, and which charge controller?

I seem to get my issue when the charge controller goes into float. I think that creates some interence. It's largely fixed since I grounded the pi to the controller but maddeningly enough it still happens sometimes. Oddly it snaps right back to working when I plug in the mt50 even for a moment, which makes me think it's still a grounding issue, but I'm not sure how to fix it further.

I'm using 600 watts of panels with the tracer 4210 with 4 Trojan t105 batteries (about 480 amp hours). Before I added the second 300 watt panel I never had the issue, but it's possible I was just never reaching float.

Also I'm not sure that your error is different. The trace is different since you're using the package here and I'm querying it directly, but it looks like the same result when I try to query the charge controller when it's non responsive.

[joeyh]

That's 1.2 kw on a EPsolar Tracer-BN. (And some pretty roached batteries.)

The code that I'm currently wrapping around epsolar-tracer to deal with this issue is https://git.joeyh.name/index.cgi/joey/homepower.git/

-- see shy jo

[wrybread]

That's 1.2 kw on a EPsolar Tracer-BN. (And some pretty roached batteries.)

Sorry I guess I wasn't clear. I have two 300 watt panels, which is 600 watts..

600 watts = .6 kw.

40 amps (the maximum output of the charge controller) into a 480 amp hour battery bank = C12 charging rate, which is under powered. Like most lead acid batteries they want a C10 charging rate (which would be 48 amps).

Also, having 600 watts of panels doesn't mean I get 600 watts ever, sadly. I've never gotten more than 500 (35 amps @ 14 volts).

Also, like most MPPT charge controllers, you can feed more panels into them than their rating and they'll retard the output to their rated output. Not that I'm doing that.

[dmdelorme]

I am having similar issues. ever second time i do a read from a tracer A. it gives me the following...

DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:send: 0x1 0x4 0x31 0x0 0x0 0xa 0x7e 0xf1
DEBUG:pymodbus.client.sync:will sleep to wait for 3.5 char
DEBUG:pymodbus.transaction:recv: 0x1 0x4 0x14 0x3 0x58 0x0 0x0
DEBUG:pymodbus.factory:Factory Response[1]
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] ReadBitResponse(40)) 
DEBUG:pymodbus.transaction:send: 0x1 0x4 0x31 0x0 0x0 0xa 0x7e 0xf1
DEBUG:pymodbus.client.sync:will sleep to wait for 3.5 char
DEBUG:pymodbus.transaction:recv: 0x1 0x4 0x14 0x3 0x59 0x0 0x0 0x0 0x0 0x0 0x0 0x4 0xe8 0x0 0x0 0x0 0x0 0x0 0x0 0x4 0xe8 0x0 0x17 0x92 0x45
DEBUG:pymodbus.factory:Factory Response[1]
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] ReadBitResponse(240)) 
DEBUG:pymodbus.transaction:send: 0x1 0x4 0x31 0x0 0x0 0xa 0x7e 0xf1
DEBUG:pymodbus.client.sync:will sleep to wait for 3.5 char
DEBUG:pymodbus.transaction:recv: 0x1 0x4 0x14 0x3 0x57 0x0 0x0 0x0 0x0 0x0 0x0 0x4 0xe8 0x0 0x0 0x0 0x0 0x0 0x0 0x4 0xe8 0x0 0x18 0xb8 0xa8
DEBUG:pymodbus.factory:Factory Response[1]
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] ReadBitResponse(440)) 
DEBUG:pymodbus.transaction:getting transaction 1
Traceback (most recent call last):
  File "sktest.py", line 16, in <module>
    pvVolts = float(result.registers[0] / 100.0)

there are some out standing issues with pymodbus or is my code bad. do i need to do more cleanup besidesclient.close()

`

[Ryanf55]

Did anyone find any solutions for this? I have grounded the Pi and receive flaky behavior even when no panel is connected and the load is off.

[pconroy328]

Not sure this helps, but I've gone after the interface using C and libmodbus. Most of the time (90%) I can read all of the registers without error. Every now and then, registers that were reading start tossing errors.

And I'm reading them as fast as the code runs, no delays between them.

I'm using Raspberry Pis and the recommended Exar cable. I'm adding more debugging code in an attempt to figure this out.