diy solar

diy solar

Off-grid Solar / Battery monitoring and control freeware

Hope this helps somebody, but I've got it to working by setting the baud rate to 9600 in my code.
 
Another issue that somebody might run into and spend half a day not being able to solve.

Grafana will not run on the latest Raspberry. It is built for ArmV4, and the r-Pi is built with an ArmV6 processor.
 
Another issue that somebody might run into and spend half a day not being able to solve.

Grafana will not run on the latest Raspberry. It is built for ArmV4, and the r-Pi is built with an ArmV6 processor.
It works on Pi4. Broadcom armv8. This is from the Grafana community:

If anyone is looking for how I did it, here are the commands:
–Update your apt source
wget https://dl.grafana.com/oss/release/grafana_6.3.3_armhf.deb 39
sudo dpkg -i grafana_6.3.3_armhf.deb
–Update available packages and Install Grafana
sudo apt-get update
sudo apt --fix-broken install
–Start the server
sudo /bin/systemctl daemon-reload
sudo /bin/systemctl enable grafana-server
sudo /bin/systemctl start grafana-server
sudo update-rc.d grafana-server defaults
 
You can get it here:

Or just:

wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add -
echo "deb https://packages.grafana.com/oss/deb stable main" | sudo tee /etc/apt/sources.list.d/grafana.list

and then use apt.
Exactly what I did. Doesn't work on the latest Zero. Influxdb 2.0 doesn't work on the latest Zero, either, though some people have tried to make unofficial builds.
 
Exactly what I did. Doesn't work on the latest Zero. Influxdb 2.0 doesn't work on the latest Zero, either, though some people have tried to make unofficial builds. I used the latest version of the lite OS. But, was not able to get that to communicate with any USB hub I have, and you need that to works the NOOBs interface. So I resorted to pre-installing the lastest OS onto the SD card and enabling the WiFi for a CLI interface.
 

I'm having this same problem... I'm sure my pinout is correct, but am not getting any data from the device. I modified Renogy_Wanderer.py to be device 255, and apparently minimalmodbus.py has been updated:


pi@bounder:/usr/local/lib/python3.7/dist-packages $ grep SLAVEADDRESS minimalmodbus.py
_BYTEPOSITION_FOR_SLAVEADDRESS = 0 # Relative to (stripped) response
responseaddress = ord(response[_BYTEPOSITION_FOR_SLAVEADDRESS])
SLAVEADDRESS_MAX = 255 # Allows usage also of reserved addresses
 
Last edited:
I now have three Wanderers. One I bought last year and two that I both this month. On the two that I recently purchased I am not getting any data back from the controller. The issue definitely follows the controller. I've swapped out the RPi and the RS232 cable and both components work as expected on one controller but not the other two. Thinking I had a faulty unit I purchased the second new unit and started testing yesterday. Exact same result. For what its worth, the BT-1 adapter seems to work correctly.

Code:
root@p-zero:/opt/SolarShed# ./RenogyWanderer.py -d
sys.argv[0]: Debug: enabled

## Diagnostic output from minimalmodbus ##

Minimalmodbus version: 1.0.2
Minimalmodbus status: Production
File name (with relative path): /usr/local/lib/python3.7/dist-packages/minimalmodbus.py
Full file path: /usr/local/lib/python3.7/dist-packages/minimalmodbus.py

pySerial version: 3.5
pySerial full file path: /usr/local/lib/python3.7/dist-packages/serial/__init__.py

Platform: linux
Filesystem encoding: 'utf-8'
Byteorder: little
Python version: 3.7.3 (default, Jan 22 2021, 20:04:44)
[GCC 8.3.0]
Python version info: sys.version_info(major=3, minor=7, micro=3, releaselevel='final', serial=0)
Python flags: sys.flags(debug=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=0, verbose=0, bytes_warning=0, quiet=0, hash_randomization=1, isolated=0, dev_mode=False, utf8_mode=0)
Python argv: ['./RenogyWanderer.py', '-d']
Python prefix: '/usr'
Python exec prefix: '/usr'
Python executable: '/usr/bin/python3'
Long info: (none)
Float repr style: 'short'

Variable __name__: minimalmodbus
Current directory: /opt/SolarShed

Python path:
/opt/SolarShed
/usr/lib/python37.zip
/usr/lib/python3.7
/usr/lib/python3.7/lib-dynload
/usr/local/lib/python3.7/dist-packages
/usr/lib/python3/dist-packages

## End of diagnostic output ##

Details of the serial connection:
Renogy: minimalmodbus.Instrument<id=0xb66d1ad0, address=1, mode=rtu, close_port_after_each_call=False, precalculate_read_size=True, clear_buffers_before_each_transaction=True, handle_local_echo=False, debug=True, serial=Serial<id=0xb66d1b30, open=True>(port='/dev/ttyUSB0', baudrate=9600, bytesize=8, parity='N', stopbits=1, timeout=2, xonxoff=False, rtscts=False, dsrdtr=False)>
Opened new tmp file /ramdisk/Renogy.prom.tmp

Reading Renogy Wanderer data...
MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): '\x01\x03\x00\n\x00\x01¤\x08' (01 03 00 0A 00 01 A4 08)
MinimalModbus debug mode. Clearing serial buffers for port /dev/ttyUSB0
MinimalModbus debug mode. No sleep required before write. Time since previous read: 617335.48 ms, minimum silent period: 4.01 ms.
MinimalModbus debug mode. Response from instrument: '' () (0 bytes), roundtrip time: 2003.3 ms. Timeout for reading: 2000.0 ms.

Failed to read from instrument
 
Last edited:
Plug in the device and run the command 'dmesg' - see what /dev/ttyUSBx it presents. Could be /dev/ttyUSB0 or whatever. Change that port name in the code.

First of all, I appreciate your response.

You're too quick! I changed the port to ttyUSB1 to check and see if I was simply not communicating with the port. I did get very different output, as I expected to see. I trimmed that part out of my post, obviously before you read it! :)

In the correctly edited output you'll see that I'm working off ttyUSB0 and sending traffic to the port but getting nothing in return.


Code:
Reading Renogy Wanderer data...
MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): '\x01\x03\x00\n\x00\x01¤\x08' (01 03 00 0A 00 01 A4 08)
MinimalModbus debug mode. Clearing serial buffers for port /dev/ttyUSB0
MinimalModbus debug mode. No sleep required before write. Time since previous read: 617335.48 ms, minimum silent period: 4.01 ms.
MinimalModbus debug mode. Response from instrument: '' () (0 bytes), roundtrip time: 2003.3 ms. Timeout for reading: 2000.0 ms.

Failed to read from instrument
 
I'm having this same problem... I'm sure my pinout is correct, but am not getting any data from the device. I modified Renogy_Wanderer.py to be device 255, and apparently minimalmodbus.py has been updated:


pi@bounder:/usr/local/lib/python3.7/dist-packages $ grep SLAVEADDRESS minimalmodbus.py
_BYTEPOSITION_FOR_SLAVEADDRESS = 0 # Relative to (stripped) response
responseaddress = ord(response[_BYTEPOSITION_FOR_SLAVEADDRESS])
SLAVEADDRESS_MAX = 255 # Allows usage also of reserved addresses
Is the problem solved?

I suspect it's a hardware issue. Try using the proven RS232C-USB conversion adapter.
 
First of all, I appreciate your response.

You're too quick! I changed the port to ttyUSB1 to check and see if I was simply not communicating with the port. I did get very different output, as I expected to see. I trimmed that part out of my post, obviously before you read it! :)

In the correctly edited output you'll see that I'm working off ttyUSB0 and sending traffic to the port but getting nothing in return.


Code:
Reading Renogy Wanderer data...
MinimalModbus debug mode. Will write to instrument (expecting 7 bytes back): '\x01\x03\x00\n\x00\x01¤\x08' (01 03 00 0A 00 01 A4 08)
MinimalModbus debug mode. Clearing serial buffers for port /dev/ttyUSB0
MinimalModbus debug mode. No sleep required before write. Time since previous read: 617335.48 ms, minimum silent period: 4.01 ms.
MinimalModbus debug mode. Response from instrument: '' () (0 bytes), roundtrip time: 2003.3 ms. Timeout for reading: 2000.0 ms.

Failed to read from instrument
If you have a Bluetooth adapter, check the ID part below in the Renogy BT app. What kind of ID do you have? Is there a difference between a Rover that works correctly and a Rover that doesn't respond?Renogy_bt.jpg
 
The measurement is not stable. Do you have a similar situation?
I'm using the Python library with a 10A WANDERER and a Raspberry Pi Zero W.

Grafana_solar.jpg
 
You folks might be interested in the undocumented Epever modbus command 0x43 that I've described my reverse-engineering of here: https://gist.github.com/symbioquine/95ba2abaf046c8e034b41e4cf3c334a9

That's how the MT50 remote displays get most of their data with fewer read/response exchanges than would be possible using the publicly documented modbus commands.
 
Last edited:
Has anyone connected / monitored / displayed in Grafana by connecting to serial comms port on the JBD ( Overkill
Solar) BMS ? Any info will be greatly appreciated.
 
Hello Joe,
great job! Love your work!

I do had some struggle to get it up an running. Still not working as intened. I got some errors during installation...

I installed the latest version of Grafana / Prometheus / Node exporter

My Setup is a Pi 2 / MPPSolar PIP / Chargery 16T BMS

I have serveral questions:

1.
But i cound intall the grafana Plugins:

grafana-cli plugins install grafana-clock-panel
grafana-cli plugins install briangann-gauge-panel
grafana-cli plugins install dalvany-image-panel
grafana-cli plugins install innius-video-panel

Il'l get an error msg:

Inconsistency detected by ld.so: dl-lookup.c: 948: _dl_setup_hash: Assertion `(bitmask_nwords & (bitmask_nwords - 1)) == 0' failed!

2.
The getChargeryData.py is for 8 Cell, my setup have 16.
is the the only line i have tu adjust:

for cell in range(dataStart, dataStart + 32, 4): # Change 32 to 96 to support the BMS16

3.
An then I have a really dump question:

To get the data with my setup I just have tu run these script?

getChargeryData.py

Where can I get a mpp Solar phyton?

Thx for the moment
 
Hi, this is a really cool project, and I hope to contribute to it.
I've got most of it working, but am stuck on how to get prometheus to automatically launch on boot.
The cheatsheet says: "Add prometheus to systemctl so they start automatically at boottime"
How do I do that?

TIA
 
Hi, this is a really cool project, and I hope to contribute to it.
I've got most of it working, but am stuck on how to get prometheus to automatically launch on boot.
The cheatsheet says: "Add prometheus to systemctl so they start automatically at boottime"
How do I do that?

TIA

Easiest to get going is probably to add it to rc.local. Check the "Additional notes - for debug only" section for some hints. In principle, all you need to do is a) make sure rc.local runs at startup (systemctl enable rc-local) and b) add your script to /etc/rc.local before exit 0.
 
Back
Top