diy solar

diy solar

This is how you can use any LiFePo4 / Lithium battery single/multiple BMS(es) with any Inverter

TolSol

New Member
Joined
Sep 4, 2022
Messages
38
Hi all too all DIY solar Fans,
I'm new to the forum, but I've used it a lot and it has been a great help in setting up my DIY solar system with 8 banks of LiFePo4 batteries with Daly BMS's and SMA Sunny Boy and SMA Sunny Island inverters.
So I've been running into the same problems as many here because the inverter manufacturers only support the usage of a handful of battery manufacturers.

As a professional expat software engineer, this led me to program my own communication between the BMS's and the inverter aggregating and controlling what the inverter gets as the BMS's reported SOC's and protocol implementations are not really always reliable.

I've read lots of posts where people have made a similar effort, but none were an all-rounder or simply just reading out values.

So the idea was born to support any type of BMS and any type of inverter which communicate via CAN, RS485, Modbus or UART.
Optionally it also sends the data to a MQTT queue; it sends email notifications on warnings and alarms and has a simple webserver to monitor all your BMS's and battery cells including alarms/warnings, etc. The whole application is build in modules and you can configure which BMS's, inverters and optional services you use.

The application now has a state where I can say its ready to use. I've been running my 8 Daly BMS's on my SMA Sunny Island for 3 months now.

So if anyone is having problems getting their BMS's running with their inverter you're welcome to have a look at the application. It's running on a Raspberry PI 3B upwards with a 2CH CAN hat or RS485 CAN hat. For detailed information you can check out the Wiki on the GitHub page https://github.com/ai-republic/bms-to-inverter. If you have any questions or need support for a different BMS or inverter just start a discussion or open an issue. A binding for any other BMS or inverter will only take a few days. I'm glad to help!

And thanks again for this great forum which helped me such a lot!
 
Last edited:
Can you dumb it down a little more?

It appears to only support DALY BMS and SMA or Growatt inverters.

IMHO, from what I've seen on this forum, DALY leads the way with being the least reliable. I'm glad you haven't experienced any failures. JBD and JK seem to be far more popular and reliable.

Hi sunshine_eggo,
nice that you are interested in the application.

I guess you're right about Daly being less reliable, that's what brought me to implement this ;)
But the price is very competitive and with the need for 8 BMS it makes a difference. They work pretty reliable under my control now.

Daly and SMA was the reference implementation. At the moment I just finished the Growatt inverter binding which I got a request for and is under test.
Next will be the binding for JK BMS which will be ready soon and after that the Deye binding is on the roadmap :)
 
Last edited:
IMHO, from what I've seen on this forum, DALY leads the way with being the least reliable. I'm glad you haven't experienced any failures. JBD and JK seem to be far more popular and reliable.

JK BMS CAN binding is now added. Would be glad if somebody could test it if they have a spare Raspberry PI with CAN hat and a JK BMS with CAN.
 
SEPLOS BMS CAN binding is now added. I'm looking for testers who have a spare SEPLOS BMS to test if the readings are correct!
 
DEYE inverters CAN binding is now added. I'd be really grateful if somebody could test the application with a DEYE inverter and a supported BMS!
 
@TolSol

i have a Sunsynk inverter (DEYE) and a 14,3kw Seplos 280L - but ive got no idea how i could help although more than happy to! from what i have read on here, there seems to be an issue with communicating between the Sunsynk inverter and more than one battery?
 
@TolSol

i have a Sunsynk inverter (DEYE) and a 14,3kw Seplos 280L - but ive got no idea how i could help although more than happy to! from what i have read on here, there seems to be an issue with communicating between the Sunsynk inverter and more than one battery?
If the Sunsynk follows the PylonTech CAN protocol - like the Deye - it only wants aggregated battery information. It is necessary to read out each BMS by itself, then aggregate the corresponding values like system voltage, current, alarms and warnings.

I don't understand why many inverter manufacturers use the PylonTech CAN protocol. There are a lot better CAN protocols out there that include a lot more data and give you data on multiple packs. I guess because its so minimalistic that they can copy it easily.... :(

If you are willing to test the application on the Sunsync inverter and have a Raspberry and a CAN hat I can guide you with the setup. That would also help me straighten out my Wiki documentation ;)
 
SolArk inverter and PylonTech BMS support bindings are now also added. Grateful to anyone who would like to help me test them!
 
from what i have read on here, there seems to be an issue with communicating between the Sunsynk inverter and more than one battery?
Yes, now that I have a implemented a wide range of bindings for the BMSes and inverters, I will also add an aggregator to address this issue for the BMSes that use the PylonTech CAN protocol. I will also aggregate the values for the PylonTech inverters. That should be ready today...
 
I will also aggregate the values for the PylonTech inverters. That should be ready today...
This is now implemented.

So if for example multiple Daly BMSes are used (they have a CAN protocol to address each pack) the data is now aggregated for inverters that speak the PylonTech CAN protocol.

For BMSes that do not support a CAN protocol which can address multiple battery packs, I will implement the support to configure multiple BMSes communicating each on a different CAN port. The data will then automatically be aggregated for inverters with PylonTech CAN protocol.
 
  • Like
Reactions: Rho
If the Sunsynk follows the PylonTech CAN protocol - like the Deye - it only wants aggregated battery information. It is necessary to read out each BMS by itself, then aggregate the corresponding values like system voltage, current, alarms and warnings.

I don't understand why many inverter manufacturers use the PylonTech CAN protocol. There are a lot better CAN protocols out there that include a lot more data and give you data on multiple packs. I guess because its so minimalistic that they can copy it easily.... :(

If you are willing to test the application on the Sunsync inverter and have a Raspberry and a CAN hat I can guide you with the setup. That would also help me straighten out my Wiki documentation ;)
I do have a pi somewhere but I've got no idea how to use it or what a CAN hst is, but if you guide me through then I'm happy to have a go?
 
I do have a pi somewhere but I've got no idea how to use it or what a CAN hst is, but if you guide me through then I'm happy to have a go?
Ah, but you would need a CAN hat for your PI otherwise there's no way to communicate via CAN to the BMS or inverter
 
im not averse to putting my hand in my pocket for a good cause !!! let me find the Pi and see if its suitable and then i can look at getting a CAN hat - is it a 'simple' task to programme and connect up? i dont know a thing about code, programming etc but can press buttons !!!!

i only have one battery at present though, so might that be an issue?
 
That would be great! I will support you setting up the Pi. The CAN hat I prefer is the Waveshare 2-Channel CAN FD HAT which has 2 channels - one to communicate to the BMS and one to the inverter. That keeps the messages clean. One battery is not a problem.
 
  • Like
Reactions: Rho
Also implemented multiple battery support for the Pylon, Seplos and JK BMS. Each BMS must have its own CAN port mapping.
 
Something that might be helpful...

I've done a little research on this with connecting an RPi with CAN hat to Victron systems.

The order of the CAN bus channels are not consistent with the Venus OS, i.e., with each reboot, channel 1 and 2 may swap at the hardware level based on the timing of detection.

In the Victron case, the VE.CAN channel may be used for multiple devices like the Lynx shunt or daisy chained VE.CAN MPPT while a BMS is on a second CAN channel. Having these swap with a reboot is very disruptive.

If only one CAN channel is needed, I would stick with the single CAN hat.
 
The order of the CAN bus channels are not consistent with the Venus OS, i.e., with each reboot, channel 1 and 2 may swap at the hardware level based on the timing of detection.
Was that on the side of your Pi or Victron? If it was on the Victron side I'd be very surprised. On the Pi I don't have these issues with the Waveshare 2CH CAN FD hat.
 
Back
Top