diy solar

diy solar

Announcing wombatt -- monitoring batteries and inverters

solarhombre

New Member
Joined
May 19, 2023
Messages
116
Location
Florida
Hello,

I've just uploaded wombatt to github: https://github.com/gonzalop/wombatt

It is a new set of tools to monitor batteries and inverters, and to send commands to inverters. The initial version only supports EG4LLv2 batteries and any inverter using the PI30 protocol family. It is written in Go, and I've uploaded tarballs for windows, mac, linux (amd64, arm, arm64). Docker images are also available for those who want to try it out.

The master battery (ID=1) is special and II am waiting on EG4 electronics to release the Modbus protocol for it. I've already decoded parts of it, including the address of the cell voltages, and I'm pondering different options to be able to monitor at least the cell voltages of the master battery.

Adding support for other battery types that use Modbus RTU should be easy if the protocol is documented. EG4 Lifepower batteries use a different protocol that should not be too difficult to implement.

If anyone wants wombatt to support batteries other than EG4LLv2, and is willing to help me figuring things out and testing them, please, let me know either through an issue in the github project or via private message.
 
Cool software. I might contribute in the future. I'd be interested in adding JK-BMS
What are you using to run it? Since it's Go in docker you're on an actual OS so PC or raspberry pi?
RS232 or RS485 connections,
I assume this would be my method to access JK BMS and others, looks like all devices need a RS485 etc to USB converter yea?
Does it have built in reading of the data that a BMS would be sending you... raw? And you're translating that to your nice list? nvm I see modbus read

I can I take your nice list into a web interface and color code based on voltage difference so it's easier to see.. Is that beyond the scope of the project or would you allow a web one with your CLI one?
We could add a flag for --cli-only or something too
 
Last edited:
Cool software. I might contribute in the future. I'd be interested in adding JK-BMS

Great! If that speaks modbus, and you have the register map, it is super easy to add support for it. The ASCII versions are a bit trickier but straightforward. If you send me the doc and are willing to test, I can write the code too.
What are you using to run it? Since it's Go in docker you're on an actual OS so PC or raspberry pi?

I run it in the same miniPC that runs HA. I just use tmux and run two instances from the terminal, one for the inverters, one for the batteries. I don't run them using docker, but will likely start using systemd to automatically start on reboot and handle logging output. Both connect via TCP to ESP32 running a modbus or serial bridge (tasmota, see pic in https://diysolarforum.com/threads/solar-assistant-power-backfeed-from-eg4.69755/post-934782)
I assume this would be my method to access JK BMS and others, looks like all devices need a RS485 etc to USB converter yea?
If run from a device directly connected to the ports, yes. That's how I started running it before moving to ESP32s+TCP

Does it have built in reading of the data that a BMS would be sending you... raw? And you're translating that to your nice list? nvm I see modbus read

Just last night I was adding something so the output from modbus-read is not just a hex dump and looks a lot like the output from battery-info or inverter-query. I'll polish it a bit, document it, and commit the changes tonight. It will be helpful to show the data when debugging and figuring out what the registers are.
I can I take your nice list into a web interface and color code based on voltage difference so it's easier to see.. Is that beyond the scope of the project or would you allow a web one with your CLI one?
We could add a flag for --cli-only or something too

There's already an argument to have a web "page" in text or JSON (the -w option enables it). The code is in internal/web/server.go. modifying that to output a proper HTML page with all the goodies would be a great addition.

Thanks!
 
Last edited:
Great! If that speaks modbus, and you have the register map, it is super easy to add support for it. The ASCII versions are a bit trickier but straightforward. If you send me the doc and are willing to test, I can write the code too.


I run it in the same miniPC that runs HA. I just use tmux and run two instances from the terminal, one for the inverters, one for the batteries. I don't run them using docker, but will likely start using systemd to automatically start on reboot and handle logging output. Both connect via TCP to ESP32 running a modbus or serial bridge (tasmota, see pic in https://diysolarforum.com/threads/solar-assistant-power-backfeed-from-eg4.69755/post-934782)

If run from a device directly connected to the ports, yes. That's how I started running it before moving to ESP32s+TCP



Just last night I was adding something so the output from modbus-read is not just a hex dump and looks a lot like the output from battery-info or inverter-query. I'll polish it a bit, document it, and commit the changes tonight. It will be helpful to show the data when debugging and figuring out what the registers are.


There's already an argument to have a web "page" in text or JSON (the -w option enables it). The code is in internal/web/server.go. modifying that to output a proper HTML page with all the goodies would be a great addition.

Thanks!
"If you send me the doc" what do you mean by that? & yea I can test, or plug it into a virtual environment and give you access too. I'm pretty flexible
I've never done programming on hardware devices that were already made like this, only stuff I've made. I've of course wiped stuff entirely and put my own software on it but then I already know how to read the output lol. So I'm inexperienced with this type of development


I see, I moved away from HA a bit because it was getting annoying every update something broke or whatever. It has gotten better past few years might start it again especially for the frigate camera software
I was using something like
Bash:
[Unit]
Description=wombatt
After=network.target

[Service]
WorkingDirectory=/bin/
Type=simple
User=wombatt
ExecStart=/bin/wombatt monitor-inverters -w :9000 --mqtt-broker tcp://127.0.0.1:1883 --mqtt-user youruser --mqtt-password yourpassword /dev/ttyS0,Q1:QPIGS:QPIRI:QPGS2,eg4_1 /dev/ttyS1,Q1:QPIGS:QPIRI:QPGS1,eg4_2
Restart=on-failure

[Install]
WantedBy=multi-user.target
yea I avoid docker as much as possible, one of the big reasons I use Go in a lot of stuff and embed everything in the 1 file lol
ESP32 + TCP seems kinda cool. Does it require an ESP32 or is the esp8266 powerful enough?


yea not having HEX output would be a very nice update
I'll pretty up the web output for sure, guess I can work on that first.... I got an issue though I don't use github since it now requires a phone number and not giving mine to microsoft lmao

I just got my first JK BMS today and I have some DALYBMS too not sure if you want to just add everything but if that is a goal of yours I'd at least have these 2 to add. I plan on replacing the daly with the jk fully.
 
"If you send me the doc" what do you mean by that? & yea I can test, or plug it into a virtual environment and give you access too. [...]

I meant I just need a document describing the register map, if modbus, or the protocol of it's something else. I've uploaded the ones I've used so far to doc/refs in the GitHub repo.
I see, I moved away from HA a bit because it was getting annoying every update something broke or whatever. It has gotten better past few years might start it again especially for the frigate camera software
I was using something like

I started using HA almost 2 years ago. So far so good.

Bash:
[Unit]
Description=wombatt
After=network.target

[Service]
WorkingDirectory=/bin/
Type=simple
User=wombatt
ExecStart=/bin/wombatt monitor-inverters -w :9000 --mqtt-broker tcp://127.0.0.1:1883 --mqtt-user youruser --mqtt-password yourpassword /dev/ttyS0,Q1:QPIGS:QPIRI:QPGS2,eg4_1 /dev/ttyS1,Q1:QPIGS:QPIRI:QPGS1,eg4_2
Restart=on-failure

[Install]
WantedBy=multi-user.target

?
yea I avoid docker as much as possible, one of the big reasons I use Go in a lot of stuff and embed everything in the 1 file lol
ESP32 + TCP seems kinda cool. Does it require an ESP32 or is the esp8266 powerful enough?
Esp8266 should be enough. The devices just read bytes from slow connections and forward them via TCP. With esp32s you could connect 2 serial devices; esp8266 only 1.

yea not having HEX output would be a very nice update
I'll pretty up the web output for sure, guess I can work on that first.... I

I haven't written JavaScript or any frontend thing lately, but a bit of JS and CSS on top of the existing minimalistic web server could do wonders without having to touch much of the Go code.
got an issue though I don't use github since it now requires a phone number and not giving mine to microsoft lmao

I just got my first JK BMS today and I have some DALYBMS too not sure if you want to just add everything but if that is a goal of yours I'd at least have these 2 to add. I plan on replacing the daly with the jk fully.
Anything that can be useful to other people is a welcome addition.
 
Thank you for making this! Just got Wombatt up and running and sending data via MQTT to Home Assistant. Now Solar Assistant, a Victron shunt, Growatt inverter and 6 Lifepower4's are all living happily under one roof. It's so nice to be able to see all that battery data in its own dashboard.
 
tl;dr
Any thoughts on how to run closed loop and logging simultaneously for a Powerpro/EG4LLv2 battery?

Longer version

Thanks to @solarhombre for the great battery monitoring utility! Adding my experience using Wombatt with the EG4 PowerPro . Running Wombatt on an RPI 4 and WiFi (thanks @AmateurSolarBuild for the install video).

The good

In order for Wombatt to communicate with the BMS, the battery address physically needs to be set for 64 (all dip switches off). Baud rate 9600. Battery type EG4LLv2. USB dongle to RJ485 plug (pins 1 and 2). RJ485 plugged into RS485/CAN port.

./wombatt battery-info -p /dev/ttyUSB0 -i 64 -B 9600 --bms-type="EG4LLv2"

Output:

Battery #64
===========
battery voltage: 54.05V
current: 0A
cell 1 voltage: 3.373V
cell 2 voltage: 3.383V
.
.
.
model: LFP-51.2V280Ah-V1.0
firmware version: Z02T01
serial: 2023-06-13

The bad
Setting the battery to any other address than 64 results in Wombatt timing out and returning no data. (This is an issue because in order to run closed loop the battery needs to be set for address 1.)

Trying to communicate with address 64 via either one of the other RS485 busses/Parallel Battery Communication Port times out.

Screen Shot 2024-02-12 at 17.12.09 PM.png

The ugly
My goal is to log the battery data in order troubleshoot some glitches I'm having with my inverter/battery combo. If I was running my system open loop then I can connect via the RS485/CAN port. Unfortunately I am running closed loop. And the inverter communicates via the CAN using the RS485/CAN port.

I see that @AmateurSolarBuild is running closed loop and logging with Wombatt. But I'm not sure which physical port he is using for the Wombatt connection. Also he has Lifepower4 batteries which appear to have a different physical port configuration.
 
Looking a little closer at @solarhombre setup. Am I correct that you are reading the data from pins 7 and 8 on the EG4LL RS485 port? And not pins 1 and 2 used by the stock EG4 USB dongle/RJ485 adapter.

And that with the master battery set to address 1 and CAN connected to the inverter, the BMS data is available on pins 7 and 8?
 
Looking a little closer at @solarhombre setup. Am I correct that you are reading the data from pins 7 and 8 on the EG4LL RS485 port? And not pins 1 and 2 used by the stock EG4 USB dongle/RJ485 adapter.

And that with the master battery set to address 1 and CAN connected to the inverter, the BMS data is available on pins 7 and 8?
Both 1,2 or 7,8 worked for me to read data from the RS485 port whether the battery is master or not. The master speaks a different protocol though.

The master is set to address 1 and connected to one of the inverters using RS485. That means I don't get any information from the master battery into HA.

There is a way to read info from the master while connected to the inverter, but it's tricky since the command to read the individual cells data and it's reply has to happen within the ~500ms between inverter queries on the same wires. I am happy seeing the data from the other 5 batteries and haven't written any code to read the master battery info using that trick.
 
Yeah, they seem to want to be either/or. I have the same problem with mine. I don't want the communication with my inverter-battery to stop, so I don't get battery data directly :(
 
Both 1,2 or 7,8 worked for me to read data from the RS485 port whether the battery is master or not. The master speaks a different protocol though.

The master is set to address 1 and connected to one of the inverters using RS485. That means I don't get any information from the master battery into HA.

There is a way to read info from the master while connected to the inverter, but it's tricky since the command to read the individual cells data and it's reply has to happen within the ~500ms between inverter queries on the same wires. I am happy seeing the data from the other 5 batteries and haven't written any code to read the master battery info using that trick.
So if I'm understanding you correctly for EG4LL, when the battery is set to any address except 1:
The batteries are communicating to each other over on either pair 1/2 or 7/8
Using the Modbus protocol

When the battery is set to address 1:
The inverter is communicating to the battery over the RS485 port on either pair 1/2 or 7/8
And the protocol is different

And since you are using RJ485 to connect to your inverter, you would need to use the same bus to communicate with the battery without interfering with the inverter communications.

I'm actually connected to my SMA inverters using the CAN bus (pins 4/5). So I'm thinking that reading from the RS485 bus on pins 1/2 or 7/8 shouldn't interfere with the inverter communication. But that I would need to read the bus using the second protocol.

Do you happen to have the reference for that protocol? If so it should be easy enough to test out using a serial comfrom a terminal shell.
 
So if I'm understanding you correctly for EG4LL, when the battery is set to any address except 1:
The batteries are communicating to each other over on either pair 1/2 or 7/8
Using the Modbus protocol

The batteries talk to each other over the battery comms wires that interconnect them. The protocol they use for that is super chatty and I've never tried to decide it.
When the battery is set to address 1:
The inverter is communicating to the battery over the RS485 port on either pair 1/2 or 7/8
And the protocol is different

And since you are using RJ485 to connect to your inverter, you would need to use the same bus to communicate with the battery without interfering with the inverter communications.

Exactly.
I'm actually connected to my SMA inverters using the CAN bus (pins 4/5). So I'm thinking that reading from the RS485 bus on pins 1/2 or 7/8 shouldn't interfere with the inverter communication. But that I would need to read the bus using the second protocol.

Do you happen to have the reference for that protocol? If so it should be easy enough to test out using a serial comfrom a terminal shell.

What I was able to guess is at https://diysolarforum.com/threads/eg4-6500-modbus.54210/page-2#post-837069 and someone's else was also onto it https://diysolarforum.com/threads/eg4-ll-v2-id1-modbus-registers.67247/#post-968678

You can use wombatt modbus-read , decode and format the output data if you want to play with it.
 
Isn't one of the SA solutions to put an ethernet splitter in the line and then you can listen to the traffic as it passes through. Might be a way to get the data.
 
Isn't one of the SA solutions to put an ethernet splitter in the line and then you can listen to the traffic as it passes through. Might be a way to get the data.
Yes, adding a bus connecting what you need works. I used wombatt forward and connected the master battery to a computer which forwarded the RS485 data between the inverter and the battery while I looked at it.

The problem is that in modbus there can only be a master and the data request by and sent to the inverter does not contain the information about the individual cell voltages or most of the other info that the other batteries provide. To read the individual cell voltages we need to read 16 other registers by sending a request to the master battery. Since the EG4 6500 gets upset if it gets a garbled reply or the reply takes longer that 500ms a few times, we would need to use that window to send and receive the request for those 16 registers. It takes about 120ms to do that. I didn't want to risk the inverters disconnecting from the batteries if there was any hiccup.
 
Last edited:
Back
Top