Project: Solar/Wind PIC controlled battery array

guardrad

Joined May 12, 2020
8
I'll likely use something like this to eliminate the converter and half-duplex jumper cable for a operational setup on a small controller with USB.
www.sparkfun.com/products/9822

Thanks for looking into this and sharing what you have found. Very helpful information. I am trying to read info from the same charge controller and having a heck of a time. If you were going to use this adapter from Sparkfun would you just hook up the orange, red, and black wires that you mapped out or is the 5v required for this application? I didn't see 5v being supplied by this adapter which is why I ask. The plan is to use pymodbus on a raspberry pi to talk to the controller and make the information available through json to grafana and my home automation system. Any help with getting the interface to work would be appreciated.
 

Thread Starter

nsaspook

Joined Aug 27, 2009
9,101
Thanks for looking into this and sharing what you have found. Very helpful information. I am trying to read info from the same charge controller and having a heck of a time. If you were going to use this adapter from Sparkfun would you just hook up the orange, red, and black wires that you mapped out or is the 5v required for this application? I didn't see 5v being supplied by this adapter which is why I ask. The plan is to use pymodbus on a raspberry pi to talk to the controller and make the information available through json to grafana and my home automation system. Any help with getting the interface to work would be appreciated.
The adapter has its own 5vdc from the USB cable, so the GND, RS485 A B signals should be all you need from the charge controller.
 

Thread Starter

nsaspook

Joined Aug 27, 2009
9,101
Alright, I wasn't sure if I needed to supply it to the controller to get it to communicate. Thanks
That part should be just fine. The actual data on the controller is of questionable quality. I've found it to be both inaccurate and low resolution for long term battery monitoring. As a general overview of system operation it's fine.

I'm finishing up the enclosure for the monitor system and MODBUS interface.
 

guardrad

Joined May 12, 2020
8
Sounds good! I picked up the 9822 and created a cable that connects GND, A, and B using your pinout but I am not able to communicate. I receive 0 bits when I try to read the registers using the following code:
Python:
from pymodbus.client.sync import ModbusSerialClient as ModbusClient
client = ModbusClient(method = 'rtu', port = '/dev/ttyUSB0', baudrate = 9600, stopbits = 1, bytesize = 8, parity = 'N')
client.connect()
rr = client.read_input_registers(address=10, count=1, unit=1)
I verified that /dev/ttyUSB0 is valid on my Raspberry Pi.

Debug returns the following:
Code:
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x1 0x4 0x0 0xa 0x0 0x1 0x11 0xc8
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Transaction failed. (Modbus Error: [Invalid Message] Incomplete message received, expected at least 2 bytes (0 received))
DEBUG:pymodbus.framer.rtu_framer:Frame - [] not ready
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
The cable I made maps pins 5,7,8 from the RJ45 connector on the 9822 (Schematic) to pins 5,6,7 on the controller. 5-5, 7-7, 8-6. I believe I am reading both the pin out you provided and the provided schematic correctly. I am pretty green when it comes to this so any hand holding you could offer would be appreciated.
 

Thread Starter

nsaspook

Joined Aug 27, 2009
9,101
The first thing to check is if you are sending data from the 9822. Do you have a o-scope or logic probe to monitor the A B signals from the converter?

Command sent and response from the charge controller.

Swapping the A B pins on the 9822 might solve the problem if the cable is correct but give me a bit to check.
 
Last edited:

Thread Starter

nsaspook

Joined Aug 27, 2009
9,101
The pin to pin connections look correct on paper but you can never tell if A/B on one device (no pinout diagram on the charge controller) is really A/B on another with RS485.
https://www.janitza.us/communication-via-the-rs485-interface.html

This is my cable to the MODBUS board. It looks like I might have an A/B swap in the cable meaning my initial A/B designation on the charge controller socket is reversed.

Update A/B pins.
 
Last edited:

guardrad

Joined May 12, 2020
8
I don't have any probes but I took your advice and made another cable with A/B switched. I was able to get some information.
Code:
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x1 0x4 0x0 0x14 0x0 0x4 0xb1 0xcd
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x1 0x84 0x1 0x82 0xc0
DEBUG:pymodbus.framer.rtu_framer:Getting Frame - 0x84 0x1
DEBUG:pymodbus.factory:Factory Response[132]
DEBUG:pymodbus.framer.rtu_framer:Frame advanced, resetting header!!
DEBUG:pymodbus.transaction:Adding transaction 1
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
Now I am trying to follow your versioning example using pymodbus.

As I was typing this the code stopped working and now I am getting the 0 bytes received.
 

Thread Starter

nsaspook

Joined Aug 27, 2009
9,101
I don't have any probes but I took your advice and made another cable with A/B switched. I was able to get some information.
Code:
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x1 0x4 0x0 0x14 0x0 0x4 0xb1 0xcd
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x1 0x84 0x1 0x82 0xc0
DEBUG:pymodbus.framer.rtu_framer:Getting Frame - 0x84 0x1
DEBUG:pymodbus.factory:Factory Response[132]
DEBUG:pymodbus.framer.rtu_framer:Frame advanced, resetting header!!
DEBUG:pymodbus.transaction:Adding transaction 1
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
Now I am trying to follow your versioning example using pymodbus.

As I was typing this the code stopped working and now I am getting the 0 bytes received.
Good work! I need to revise the charge controller socket A/B pins on my built documents. The Rover_MODBUS documentation starting from page 16 has example commands and responses for common system parameters.

I've never used Python so I can't help with that.
 

guardrad

Joined May 12, 2020
8
I found an issue with the 9822. Something caused it to be powered but when a command was passed to it, it would die and come back. A hard reset of the device fixed the issue. Hopefully that is not a bug I will run into with it. Next step is to figure out how to pass the right request to the charge controller. If I understand correctly the first 04 should be 03 to read the register.
 

Thread Starter

nsaspook

Joined Aug 27, 2009
9,101
Do you have a copy of the ROVER_MODBUS documentation?
https://github.com/nsaspook/vtouch_v2/blob/mbmc/ROVER_MODBUS.pdf


Device address
Function code
Start address
No. of read words

Device address BYTE 01H to F7H
Read a Single or Multiple Word register(s) 2 bytes 03H

3.3 To read the controller's software version and hardware version, and the PDU addresses are known to be 0014H, 0015H, 0016H and 0017H in sequence
To send: 01 03 0014 0004 040D
To receive: 01 03 08 0003 0201 0001 0203 8A54
Parsing: (the highest byte OOH is not used) 030201H indicates the controller's software version is V03.02.01
(the highest byte OOH is not used) 010203H indicates the controller's hardware version is V01.02.03
 

guardrad

Joined May 12, 2020
8
I figured out the issue with the wrong function code being sent. I uploaded the work to github if interested. https://github.com/CyberRad/CoopSolar

By any chance did you see anything odd with the temps that are pulled from your controller? The example provided in the pdf shows querying 102 for the temp but the table shows 103. 102 seems to be valid per the table for charging current. Are you reading any input for the 2 values for 103? Below is my sent and received.

Code:
DEBUG:pymodbus.transaction:Current transaction state - IDLE
DEBUG:pymodbus.transaction:Running transaction 1
DEBUG:pymodbus.transaction:SEND: 0x1 0x3 0x1 0x3 0x0 0x2 0x35 0xf7
DEBUG:pymodbus.client.sync:New Transaction state 'SENDING'
DEBUG:pymodbus.transaction:Changing transaction state from 'SENDING' to 'WAITING FOR REPLY'
DEBUG:pymodbus.transaction:Changing transaction state from 'WAITING FOR REPLY' to 'PROCESSING REPLY'
DEBUG:pymodbus.transaction:RECV: 0x1 0x3 0x4 0x16 0x10 0x0 0x0 0xff 0xbe
DEBUG:pymodbus.framer.rtu_framer:Getting Frame - 0x3 0x4 0x16 0x10 0x0 0x0
DEBUG:pymodbus.factory:Factory Response[ReadHoldingRegistersResponse: 3]
DEBUG:pymodbus.framer.rtu_framer:Frame advanced, resetting header!!
DEBUG:pymodbus.transaction:Adding transaction 1
DEBUG:pymodbus.transaction:Getting transaction 1
DEBUG:pymodbus.transaction:Changing transaction state from 'PROCESSING REPLY' to 'TRANSACTION_COMPLETE'
Maybe 0x16 and 0x10 are actually separate measurements?
 

Thread Starter

nsaspook

Joined Aug 27, 2009
9,101
I use very little data from the controller. My only interest was tracking the charger mode state and error codes so I didn't do much to validate values other that looking at a few voltage/current readings that were imprecise in comparison to my own monitoring system. Nice job with your software.hardware setup.
 

Thread Starter

nsaspook

Joined Aug 27, 2009
9,101
The new AGM batteries on the old 12vdc system are impressive under load. Running the 5000 BTU AC in the shop without a glitch for hours and hours.
IMG_20200731_172831.jpgIMG_20200731_172611.jpg
 
Top