Monitoring Renogy Charge Controller over Serial Port Broken!

scottnichol

New Member
Hello!

I recently set up a system with 4x100W panels into a Renogy Rover 40A charge controller. Coupled with a 200Ah battery and 1000W inverter. The whole system works great. The kit I purchased included the Renogy BT-1 bluetooth module for monitoring through their apps. But I wasn't happy with what was being reported and wanted something more robust.

Enter SolarShed, a simple python script to read from the RJ-11 serial port. I got a Raspberry Pi, built an RJ-11 to DB-9 to USB cable and was able to read data from the port. I could see volts, amps and watts coming off the panels, battery charge percentage and a host of other parameters. There was some additional configuration using Prometheus for data aggregation and Grafana to visualize all of the data over time. It was all working 24/7 and I could monitor all of it from any web browser.

Then I did two boneheaded things:
  • I wanted to see if it was possible to have both my Raspberry Pi and the BT-1 module plugged into the RJ-11 port at the same time, but of course this didn't work because the male end of the phone line splitter only has 4 pins and who knows what cross talk is going on there
  • Next, I'd heard about the Renogy DC Home app for monitoring with their BT-1 module and wanted to see what it could offer, unplug the Raspberry Pi, plug in the BT-1 and check out the app
    • I added my charge controller, checked out the app and it was pretty much inferior to what I had running on my Raspberry Pi
At this point, I unplugged the BT-1 module and plug my Raspberry Pi back in and suddenly I can't read from the serial port any longer. The SolarShed python script is throwing errors:
Traceback (most recent call last):
File "/home/pi/.local/lib/python3.9/site-packages/solarshed/server.py", line 37, in <module> battery_percentage_gauge.set(controller.battery_percentage())
File "/home/pi/.local/lib/python3.9/site-packages/solarshed/controllers/renogy_rover.py", line 80, in battery_percentage return self.read_register(256) & 0x00ff
File "/home/pi/.local/lib/python3.9/site-packages/minimalmodbus.py", line 258, in read_register return self._genericCommand(functioncode, registeraddress, numberOfDecimals=numberOfDecimals, signed=signed)
File "/home/pi/.local/lib/python3.9/site-packages/minimalmodbus.py", line 697, in _genericCommand payloadFromSlave = self._performCommand(functioncode, payloadToSlave)
File "/home/pi/.local/lib/python3.9/site-packages/minimalmodbus.py", line 795, in _performCommand response = self._communicate(request, number_of_bytes_to_read)
File "/home/pi/.local/lib/python3.9/site-packages/minimalmodbus.py", line 930, in _communicate raise IOError('No communication with the instrument (no answer)')
I've tried just about everything I can think of from rewiring the cable, connecting the serial port directly to the GPIO, and completely reinstalling the RaspberryPi and all software from scratch and still no dice.

I'm wondering if any of the following may have happened:
  • Trying to connect both devices simultaneously caused the controller to flip its TX/RX wires?
  • Using the newer DC Home app from Renogy updated something within the charge controller firmware to prevent rogue agents from talking to the controller, maybe as a security feature?
If anyone has any experience with suddenly being unable to talk to a serial port like this, I'd appreciate your advice on how to restore access.


thanks
scott nichol
 

Symbioquine

Solar Enthusiast
I doubt anything "caused the controller to flip its TX/RX wires" or that Renogy is trying to prevent arbitrary communications with its products.

It's possible that there was a short or something that caused some sort of electrical damage. First I'd want to rule that out...

Some troubleshooting ideas;

1. Try plugging the BT module back in directly and see if that still works. If so, then it is likely other hardware can also still be used to talk to the Rover.
2. Look for bent/dirty pins in the RJ-11 socket on the Rover.
3. Try fully powering off and back on all devices involved. Maybe something in the system is stateful and just got into a bad state.
4. Try testing the pin continuity/resistance in the splitter you used (without connecting it to anything else) with your multimeter. Maybe there's a short in there. It looks like there are power pins in the Rover's RJ-11 jack so a short could potentially cause damage (to the Rover or the Pi).
5. Test whether the serial port on the Raspberry Pi got damaged by talking to some other (known good) serial device.
 

scottnichol

New Member
I doubt anything "caused the controller to flip its TX/RX wires" or that Renogy is trying to prevent arbitrary communications with its products.

It's possible that there was a short or something that caused some sort of electrical damage. First I'd want to rule that out...

Some troubleshooting ideas;

1. Try plugging the BT module back in directly and see if that still works. If so, then it is likely other hardware can also still be used to talk to the Rover.
2. Look for bent/dirty pins in the RJ-11 socket on the Rover.
3. Try fully powering off and back on all devices involved. Maybe something in the system is stateful and just got into a bad state.
4. Try testing the pin continuity/resistance in the splitter you used (without connecting it to anything else) with your multimeter. Maybe there's a short in there. It looks like there are power pins in the Rover's RJ-11 jack so a short could potentially cause damage (to the Rover or the Pi).
5. Test whether the serial port on the Raspberry Pi got damaged by talking to some other (known good) serial device.
Thanks for replying. These are all really good suggestions. I have reconnected the bluetooth module and it communicates with the Rover without problems, so I'm fairly certain the serial port on the Rover is fine.

It just has to be something in the chain of cables/adapters. I'm going to try making a more direct cable with tx/rx/grnd directly into the USB-> Serial cable or right into the GPIO at this point.
 

scottnichol

New Member
Checked and double checked everything. 5.6V from TX->RX and TX->GRND. But still seeing a different error now:

MinimalModbus debug mode. Writing to instrument (expecting 7 bytes back): '\x01\x03\x01\x00\x00\x01\x85ö' (01 03 01 00 00 01 85 F6)
MinimalModbus debug mode. No sleep required before write. Time since previous read: 1636754332459.6 ms, minimum silent period: 4.01 ms.
MinimalModbus debug mode. Response from instrument: '\x00\x00\x00\x00\x00\x00\x00' (00 00 00 00 00 00 00) (7 bytes), roundtrip time: 7.3 ms. Timeout setting: 500.0 ms.
Traceback (most recent call last):
File "/home/pi/.local/lib/python3.9/site-packages/solarshed/server.py", line 37, in <module> battery_percentage_gauge.set(controller.battery_percentage())
File "/home/pi/.local/lib/python3.9/site-packages/solarshed/controllers/renogy_rover.py", line 81, in battery_percentage return self.read_register(256) & 0x00ff
File "/home/pi/.local/lib/python3.9/site-packages/minimalmodbus.py", line 258, in read_register return self._genericCommand(functioncode, registeraddress, numberOfDecimals=numberOfDecimals, signed=signed)
File "/home/pi/.local/lib/python3.9/site-packages/minimalmodbus.py", line 697, in _genericCommand payloadFromSlave = self._performCommand(functioncode, payloadToSlave)
File "/home/pi/.local/lib/python3.9/site-packages/minimalmodbus.py", line 798, in _performCommand payloadFromSlave = _extractPayload(response, self.address, self.mode, functioncode)
File "/home/pi/.local/lib/python3.9/site-packages/minimalmodbus.py", line 1075, in _extractPayload raise ValueError(text)
ValueError: Checksum error in rtu mode: '\x00\x00' instead of '$\x00' . The response is: '\x00\x00\x00\x00\x00\x00\x00' (plain response: '\x00\x00\x00\x00\x00\x00\x00')
At this point the RJ-11 cable is plugged directly into the GPIO. Not sure what I'm doing wrong.
 
Top