Modbus interface flaky? (SOLVED!)

[wrybread]

Is anyone else finding the modbus interface unreliable? It will suddenly stop working for me, and to get it back I have to do some combination of turning it off and on (disconnecting from battery) and factory reset. Unfortunately its not even a reliable series of steps to make it respond again.

Oddly the MT50 remote monitor box continues to work when the modbus isn't responding, which makes me think the MT50 is using some different protocol? Or maybe its some other issue?

When it fails I get this error:

Traceback (most recent call last): File "/home/pi/pancho_brain/test_solar.py", line 27, in result = client.read_input_registers(0x3000, 9, unit=1) File "/usr/local/lib/python2.7/dist-packages/pymodbus/client/common.py", line 120, in read_input_registers return self.execute(request) File "/usr/local/lib/python2.7/dist-packages/pymodbus/client/sync.py", line 82, in execute raise ConnectionException("Failed to connect[%s]" % (self.str())) pymodbus.exceptions.ConnectionException: Modbus Error: [Connection] Failed to connect[rtu baud[115200]]

The device is still there at /dev/ttyUSB0, it just refuses connection. When it's not responding, the Solar Monitor program on Windows doesn't connect either. and tried the other pins too (since there's two choices for each A and B).

I'm using a cable built using this connector:

https://www.amazon.com/gp/product/B00NKAJGZM/ref=oh_aui_detailpage_o00_s00?ie=UTF8&psc=1

I have the stock cable too, but it has never worked for me.

Can anyone think of anything to try? This is from a Raspberry Pi, if it matters. I've quadruple checks the wiring of the cable, The issue happens on two different Tracer 4210a charge controllers.

All I can think of is that it might be an issue with my adaptor (the connector linked above), since the MT50 box always works. I ordered another one, hopefully it fixes it. But I'm curious if anyone else has had any issues.

[kasbert]

Is there any kernel messages (dmesg) or any processes using the device (fuser /dev/ttyUSB0) ?

What is the stock cable ? Have you tried it with the exar driver in this repository.

[wrybread]

At the moment my controller won't respond to connection attempts again. It ran all night in a test script, responding for about 11.5 hours (4253 responses, one every 9.7 seconds). And now it will communicate with the MT50 remote monitor box, but not my script (and it fails with the error in my first post).

By the way, my script is, in stripped down form:

from pymodbus.client.sync import ModbusSerialClient as ModbusClient

client = ModbusClient(method = 'rtu', port = '/dev/ttyUSB0', baudrate = 115200) client.connect()

result = client.read_input_registers(0x3100,6,unit=1) pvVolts = float(result.registers[0] / 100.0) pvAmps = float(result.registers[1] / 100.0) batteryVolts = float(result.registers[4] / 100.0) batteryAmps = float(result.registers[5] / 100.0)

print pvVolts print pvAmps print batteryVolts print batteryAmps

client.close()

I've tried both leaving the client open and closing the client after each request, with the same issue of it stopping responding after awhile.

The cable I'm using was build using this adaptor:

https://www.amazon.com/gp/product/B00NKAJGZM/ref=oh_aui_detailpage_o06_s00?ie=UTF8&psc=1

The cable that I purchased with the controller (that has never worked for me) is this one:

https://www.amazon.com/SolarEpic-Battery-Temperature-Monitoring-adapter/dp/B016RU8JUY

When my cable (using the adaptor) is connected I get this message in dmesg:

[ 1114.012812] ch341 1-1.5:1.0: device disconnected [ 1116.041617] usb 1-1.5: new full-speed USB device number 6 using dwc_otg [ 1116.145377] usb 1-1.5: New USB device found, idVendor=1a86, idProduct=7523 [ 1116.145418] usb 1-1.5: New USB device strings: Mfr=0, Product=2, SerialNumber=0 [ 1116.145438] usb 1-1.5: Product: USB2.0-Serial [ 1116.146901] ch341 1-1.5:1.0: ch341-uart converter detected [ 1116.154668] usb 1-1.5: ch341-uart converter now attached to ttyUSB0

When I try to compile the driver for the other cable (and I'm not sure if that cable is compatible), it fails with the following:

make make -C /lib/modules/4.1.13+/build M=/home/pi/pancho/driver make[1]: /lib/modules/4.1.13+/build: No such file or directory. Stop. Makefile:9: recipe for target 'all' failed make: [all] Error 2

I'm using kernel version 4.1.13+.

When it fails it won't connectWindows either (to Epsolar's Solar Monitor program). And what's very confusing is that the MT50 remote monitoring box continues to work when it fails. Is that using a different protocol?

I'm also wondering if there's a step missing in my script that's reading the data. It takes about 10 seconds to get the reading, which I gather isn't normal, so maybe I'm missing a step? And the controller eventually starts timing out?

Anyway, this is very frustrating, any and all theories are very invited.

[ReindeerFan]

Hi guys... I got this great software to work, but how about the voltages on 3210A? All default values are set on the controller for Sealed battery, but still this library tells boost (which should be 14.4V) voltage is while charging 14.8V. In addition, float is defined at 13.8V but shows 14.05V. Is this data reliable or am I missing something?

[wrybread]

Ugh, after running smoothly for a week, the charge controller just stopped responding again, and now it won't respond.

Am I the only one having this problem? Can someone confirm that theirs doesn't have this issue?

[wrybread]

Just a quick note, I solved the issue. I needed to ground my Pi to the charge controller. I did that by connecting the ground pin from the modbus cable (pin 7 or 8) to one of the ground GPIO pins on the Pi. Works perfectly ever since.

I still got occasional disconnects until I also grounded my inverter. Now smooth sailing.

[ygator]

Am I the only one having this problem? Can someone confirm that theirs doesn't have this issue?

This has happened to me as well running my own software, I have a pizero reading the data. Sometimes the controller stops responding and I have to disconnect/reconnect the power to it to get it working again. I am using the official cable. I have also used a cable I made myself like you and I believe I had the same issue. When it failed I even tried rebooting the pi and plugged it into a PC. It was dead until I cycled power on the controller.

[kasbert]

Closing as stale