Can't connect to EPsolar Tracer 3210an charge controller from Windows 10 via Serial / Modbus

Question

Summary

I'm using this USB-to-RJ45 cable to connect my Windows 10 developer workstation to the EPEver Tracer 3210an solar charge controller.

I'm using Python 3.8.6 with the minimalmodbus module to attempt to connect to the device, retrieve data, and control the device parameters.

Expected Result

The charge controller returns the input voltage of the photovoltaic (PV) panels.

Actual Result

MinimalModbus debug mode. Create serial port COM4
MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): '\x01\x041\x00\x00\x01?6' (01 04 31 00 00 01 3F 36)
MinimalModbus debug mode. Clearing serial buffers for port COM4
MinimalModbus debug mode. No sleep required before write. Time since previous read: 105406.00 ms, minimum silent period: 1.75 ms.
MinimalModbus debug mode. Response from instrument: '' () (0 bytes), roundtrip time: 1015.0 ms. Timeout for reading: 1000.0 ms.

Traceback (most recent call last):
  File "tempCodeRunnerFile.python", line 17, in <module>
    pv_voltage = ins.read_register(PV_VOLTAGE, 2, 4, False) 
  File "C:\Users\TrevorSullivan\scoop\apps\python\current\lib\site-packages\minimalmodbus.py", line 441, in read_register
    return self._generic_command(
  File "C:\Users\TrevorSullivan\scoop\apps\python\current\lib\site-packages\minimalmodbus.py", line 1170, in _generic_command
    payload_from_slave = self._perform_command(functioncode, payload_to_slave)
  File "C:\Users\TrevorSullivan\scoop\apps\python\current\lib\site-packages\minimalmodbus.py", line 1240, in _perform_command
    response = self._communicate(request, number_of_bytes_to_read)
  File "C:\Users\TrevorSullivan\scoop\apps\python\current\lib\site-packages\minimalmodbus.py", line 1406, in _communicate
    raise NoResponseError("No communication with the instrument (no answer)")
minimalmodbus.NoResponseError: No communication with the instrument (no answer)

Code

import minimalmodbus
import serial

ins = minimalmodbus.Instrument('COM4', 1, debug=True)

ins.serial.baudrate = 115200
ins.serial.bytesize = 8
ins.serial.stopbits = 1
ins.serial.parity = serial.PARITY_NONE
ins.serial.timeout = 1

ins.mode = minimalmodbus.MODE_RTU
ins.clear_buffers_before_each_transaction = True

PV_VOLTAGE = 0x3100

pv_voltage = ins.read_register(PV_VOLTAGE, 2, 4, False) 
print(pv_voltage)

What I've Tried

• Use pymodbus module instead
• Tried the easymodbus module
• Changed the baud rate to 9600
• Tried using ASCII mode instead of RTU (99% confident it needs RTU mode though)
• Changed the COM port on the serial device from COM3 to COM4
• Rebooted computer
• Connected the MT-50 display to the charge controller (works perfectly)
• Changed parity setting to other values (even, odd, space, etc.)

Question

1. How can I successfully connect my developer workstation to the charge controller?
2. Is it possible that this cable is just dead?
3. What else can I do to test the cable to ensure it's functional?
4. What else can I do to test the charge controller, to ensure it's responding?

Answer 1

Communication with these controllers (manual) is via RS485 (delivered through an RJ45 connector). This is only mentioned briefly in the manual ("RS485 interface" in the technical specifications section).

The cable you are using appears to be a router console cable which, I believe, uses the RS232 protocol (see document from Cisco as an example). RS232 and RS485 are different, and incompatible, so this cable will not work.

The manual for this controller does not go into much detail and I could not see a modbus manual on the EPEVER website. I use Tracer-BN series units and epever support emailed me a manual detailing the modbus setup; as your unit also supports the MT50 remote meter I'm assuming its registers are the same. You can probably find the manual by searching for "common software or MT50 LCD unit" (with the quotes) - I believe version 2.5 is the latest (note: I'm not posting the link because it does not seem to be available on the official website so click at your own risk!)

The RJ45 wiring (from the above manual) is:

Pin  | Define 
-----|-------------------------------------
1    | Power supply output +5V or +7.5V 
2    | Power supply output +5V or +7.5V 
3    | RS-485-B 
4    | RS-485-B 
5    | RS-485-A 
6    | RS-485-A 
7    | Ground 
8    | Ground

Note: These devices can be connected in series; if you are just connecting to one use pins 3, 5 & 7. I have found that a ground connection is needed for reliable comms.

Note2: Epever does have an 'official' USB to RJ45 cable (CC-USB-RS485-150U); I have three of these and could not get any to work (a local distributor mentioned having similar issues). These cables are available from Amazon (picked them due to your console cable link).

A good way to check if your cable is wired correctly is to use it with the charge controller software (I believe this uses modus to communicate with the units but it is possible they support another protocol).

For testing I use a cheap USB->RS485 adapter wired as above (115200, n, 8, 1) and it this works pretty well (have about 10 of these out in the field connected to devices with built in RS485). The USB->485 adapter I use was from Aliexpress (got 10 and have had no issues) but you can get something similar from Amazon (but as mentioned I think you need the ground connector which not all adapters have - I could not get these working reliably with a two wire connection). I cut a standard network lead in half and connected it up to this adapter (saved digging out crimping tools etc); I have not seen this wiring setup used elsewhere so don't think you will be able to buy one off-the-shelf (other then from Epever).

Answer 2

Afaict, the correct term to use above would be 8P8C rather than RJ45. 8P8C is used for a wide variety of RJ registered jack types. Maybe one of the types listed there corresponds to what the Tracer is using?

Answer 3

Found a complete solution to this problem in the article on how to Capture and Analyze Solar Power Generation Metrics with Python and InfluxDB.