Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RenogyWanderer.py - Possible address change in new versions #4

Open
friedpope opened this issue Jun 12, 2021 · 3 comments
Open

RenogyWanderer.py - Possible address change in new versions #4

friedpope opened this issue Jun 12, 2021 · 3 comments

Comments

@friedpope
Copy link

friedpope commented Jun 12, 2021

I was initially unsuccessful in getting a Wanderer 10A to communicate and discovered through some logic analyzing and reading of forum posts that the modbus address may have changed in newer version of the unit. First off, here are the details on what I have:

PN on Box: RNG-CTRL-WND10-G1-US
PN on Unit: RNG-CTRL-WND10
MFG Date on PCB: 2018.11.09
Blue Logo on Unit: WANDERER TM

I have the unit connected via an RS232-USB adapter with a logic analyzer probing both the RX and TX lines to confirm that I'm getting data to and from the unit properly. Serial settings are 9600 8N1.

Using this setup I've confirmed that the unit is able to respond to serial data by asking the Renogy Firmware Update Tool to connect to the unit. The tool fails to connect, however on the logic analyzer I see the following data:
PC to Wanderer: 0xFF 0x41 0x00 0x00 0x00 0x00 0x28 0x1B
Wanderer to PC: 0xFF 0xC1 0x01 0xD1 0xA0

I'm guessing the Firmware Update Tool is querying the unit for it's model number and the tool just doesn't support this unit. I can replicate this conversation using RealTerm to send the same data to the unit and I get the same response back. When I attempted to run a Modbus RTU query to address 1 I got nothing back from the unit, it's discarding the packets since it has a different address.

Here's what I see on the logic analyzer when running an unmodified RenogyWanderer.py:
PC to Wanderer: 0x01 0x03 0x01 0x01 0x00 0x00 0x01 0x85 0xF6
Wanderer to PC: (NO RESPONSE!)

Modifying line 27 to use address 255 corrects the problem and the expected data is received by RenogyWanderer.py:
-27:renogy = minimalmodbus.Instrument(devName, 1)
+27:renogy = minimalmodbus.Instrument(devName, 255)

It might be a nice feature to scan both of these addresses, if "1" fails, attempt "255" next and lock onto that address for future reads if it works.

PC to Wanderer: 0xFF 0x03 0x01 0x01 0x00 0x00 0x01 0x90 0x28
Wanderer to PC: 0xFF 0x03 0x02 0x00 0x64 0x90 0x7B

It's possible that Renogy has adopted a mechanism to change the address of the unit similar to this product, however I've been unsuccessful in getting the same steps to do anything on the Wanderer 10A:
(http://site.jjstech.com/pdf/Agrowtek/IM_MODBUS.pdf) See Page 6

@lzhengchun
Copy link

is the RJ12 rs232 or rs485? I always got an echo of whatever I sent

@BarkinSpider
Copy link
Owner

It's RS232, use a quality cable.

@lzhengchun
Copy link

ValueError: The slaveaddress is too large: 255, but maximum value is 247.

I got this error when make the change to line 27

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants