Renogy Rover Monitor

Once we had installed the Renogy Rover charge controller on the property, I got one for our camper trailer and one for the shed at home so I had spares I could put on the bench during the development of the monitoring project.

The Renogy Rover has a RS232 port It uses Modbus and the register documentation was available on the internet. It also provides some power which is convenient.

I'd been using a lot of Particle Photon's on some paid projects, so it was the easy choice for the job. Between wifi with an external antenna option, remote update and the particle cloud platform it's actually a pretty good choice for off-gird IoT projects. I also already had code and services for receiving and storing data.

Hardware

Initially, I cobbled together a system with an DFRobot Arduino rs232 shield and then later designed a PCB board for the project.

Alt text

The board is a pretty simple affair it's got headers for both the Particle Photon and Feather format. The feather pattern hasn't been tested but should work.

The Rover provides rs232 and power on RJ12 6P6C connector so I put the same on my PCB. Had a couple of cable issues with bad crips but overall works well.

There is a circuit for hooking up to a pulse output from an energy meter. It worked well at home in the shed but never worked properly on the property. It is all running below spec as the DIN energy meeter specs are something like 5-30 VDC, and I'm using 3.3 from a micro.

Alt text

Boron Fail

The PCB is designed to use a 3.3 regulator and it powers the mico and the max232 transceiver ic at 3.3v. I wanted to use a Particle Boron board that needs 5v for its cellular modem and battery charging. I modified a board to use a 5v regulator and it powers the mico and the max232 transceiver ic at 5v. It just wouldn't talk to the Rover. From my read of the max232 datasheet it should work, just haven't had the time to debug this one and it's pretty far below the event horizon at this point.

I was getting some odd audio noise from the Rover when testing, so something was obviously not right.

Software

Always the poor child in hardware projects, the firmware is pretty basic. I've got a simple sensor aggregation library/object. So read a bunch of parameters over Modbus update the aggregation and then every 5 minutes send the data to the cloud using particle.publish and reset the aggregation. Add an interrupt to count the pulses from the energy monitor and thats about it.

The charge controller does its own aggregation/counting but I'm not reading them at the moment as they are a bit more complex I would need to keep values to de-aggregate the data and they would reset as they are daily values. The "live" readings where useful enough.

Data

The data is sent to the Particle cloud, I have some code that subscribes to these messages and stores the data in an InfluxDB time series database. Consequently, there are gaps in the data when the site is offline for one reason or another.

Alt text