diyBMSv4ESP32
diyBMSv4ESP32 copied to clipboard
stuartpittaway
CANbus networking of controllers
I've been thinking about the idea of connecting multiple controllers via CAN with the goal of providing aggregated data to Victron (or Pylontech, etc.) as one large battery. I figured I would open a Git Issue in case someone has already put more thought into this. This functionality has probably been viewed as a bit of an edge case to date. Pylontech and Victron do offer the ability to daisy chain batteries. Besides the ability for further expansion, it also provides redundancy. For instance, in my case a 4s4p battery will be arranged so that there are 2x controllers configured as 4s2p which are themselves connected in parallel -each with their own battery disconnect. This way a fault with any cell only takes half the battery offline and maintains uninterrupted power.
Thoughts so far… • Each controller has a configuration page option “Controller X of Y”. Where X is the sequential number the user assigns each controller and Y is the total number of controllers that will be networked. • The controller # ‘X’ determines the hierarchy of the ‘master’ succession list. Controller 1 is default ‘master’ and is responsible for communicating to Victron. If Controller 1 fails to update then Controller 2 assumes the ‘master’ role and begins communicating with Victron. • Some form of a heartbeat might need established to ensure all controllers are updating vitals regularly so that the ‘master’ can report out within Victron’s heartbeat window • The controller # ‘X’ also determines the predetermined identifier or “address” range where each controller will be broadcasting its data. Whoever is elected ‘master’ is responsible for aggregating the data from these ‘locations’ to send to Victron • I haven’t really gone into the rules used for aggregating each piece of data. Many are simple like grabbing the lowest module voltage. There may be some that require more careful thought...
Are you running batteries in an environment where they cannot ever be powered off or taken offline?
The idea you listed is fine, but we are venturing into a high availability style of design, potentially even safety critical system?
No, it's not that type of environment. I do recognize your concern about relying on this type of control for safety critical applications. That is not my intention. My particular installation will be on a boat where you take any redundancy you can get. But I don’t go offshore so it’s more of a convenience than safety critical (i.e. I don’t want the A/C to turn off in the middle of the night). I would still keep a manual battery isolator/selector to use the lead starting battery as a DC backup source for critical systems.
I guess some of the features of CAN protocol are already in the spirit of high availability design. CAN, just by nature of using it, would mean that every controller is simultaneously being exposed to all of the required data-it's there to grab. It seems like the logical continuation to seamlessly re-assign a 'master'.
Does Victron have no capability for multiple battery systems?
The trouble with CAN is that each controller would broadcast the same message Id's - so unless you can separate the physical CAN data lines, those messages would be mixed up and Victron would get confused.
Aggregation of those messages is possible - but things like state of charge are difficult to merge.
Victron does not support more than 1 (main) battery and likely never will. There are ways to setup aux batteries through VE.Direct (RS282) and it just shows up as another 'device' in the menu but it's completely separate from the main (not included in any SOC calcs, not part of DVCC, and doesn't display on the main page). The BMS-Can connection is a dedicated network just for handling BMS communciation so all critical information must go through there. As you say its only listening for a few identifiers (comprising one battery) so the data must be aggregated first.
SOC does require some post processing maths..
As you are looking at a 4s4P setup, a single controller would operate that size of battery without an issue.
Perhaps a different way to look at this, would to have a second controller sitting in a "standby" state waiting to take over?
It would need to electrically share the connections to the modules TX/RX and the CAN bus - not sure that would currently work without changes to the code and/or PCB.
I did consider setting up 4s4p on one controller but of course that doesn’t allow putting half the battery on separate contactors for redundancy.
I don’t think making a controller sit in standby is the way – unless you just mean the part of the code that would TX the Victron range of message identifiers. Any controller ought to still be actively TX’ing it’s data (with different identifiers) so that whoever will be reporting to Victron can speak on it’s behalf for full functionality.
Not sure a change in hardware is needed. If you daisy CAN H and CAN L off the terminals of one module to the next you would just solder blob JP1 on the last controller. Code changes of course…
From my view linking controllers in parallel affords: easier expandability, ability to isolate from hardware failures (cell/wiring), ability to isolate from controller (PCB) failure, the ability to parallel batteries with differing capacities, and support for more modules. Depending on the application- support for more modules could mean more balancing power, an option to improve comm speeds for those running really large systems regardless of any recent or future improvements to the hardware design, and may encourage those considering really high voltages to come down to safer levels.
Have you considered moving the fuse/contactor onto each bank of cells? So you have 4 battery banks with a contactor on each before they are paralleled?
You also need to consider the maximum current through those cells, can half the battery cope with the full load?
Have you considered moving the fuse/contactor onto each bank of cells? So you have 4 battery banks with a contactor on each before they are paralleled?
This does provide more granularity and was my first choice. There is an increase in the cost of the contactors, fuses, cabling/connectors (probably equivalent cost of another controller) but still don’t have the ability to isolate the problem automatically. As the code exists now you would see an alarm, then go manually isolate the problematic bank, login and reconfigure the controller down to 3x banks and startup again.
You also need to consider the maximum current through those cells, can half the battery cope with the full load?
Yes, half the battery is sized to comfortably run the maximum load.
I will remain here to see if it gets any update. My case could be similar. I will have 8 packs 16s lifepo4 in parallel. Without a deep knowledge about the internals of the diybms. My thoughts are similar than menningd.
In my mind, each pack will have a contactor (another problem, for my case with 8 packs, is that there are only 4 relays, but it is another question) and will be a master contactor (on the busbar with all parallel packs).
The packs are listed from 1 to 8, the number 0 is the virtual pack (aggregation of all packs). So the pack 0 (virtual) is that communicates with the victron via CAN to regulate the voltage charge and current discharge.
The rules must be open to the user, for my case could be something like "accept all charge if at least 2 pack are >90% or less than XX voltage pack. If only 1 pack are >90% reduce charge (via voltage CAN) at XX volts (as in the last update)"
Seplos BMS is doing something like this with the last version of this BMS.
I think there are a lot of interest on multibank batteries (as can be shown in the victron community and in the [github project](https://github.com/Louisvdw/dbus-serialbattery/issues/8 . He also had an [open issue regarding the Master BMS or virtual battery aggregation](https://github.com/Louisvdw/dbus-serialbattery/issues/266 Also here we've an aggregation driver for dbus serialbattery, while isn't implemented officially)
I have been working on this and i think im very close to having something useful. Still doing a lot of cleanup.
The packs are listed from 1 to 8, the number 0 is the virtual pack (aggregation of all packs). So the pack 0 (virtual) is that communicates with the victron via CAN to regulate the voltage charge and current discharge.
I don't see any reason to explicitly define a virtual pack. The way i have it now, each controller is ready to be master ( aggregate and report to the inverter). They all constantly monitor traffic and the lowest addressed controller is elected master automatically if the current master controller goes offline.
The rules must be open to the user, for my case could be something like "accept all charge if at least 2 pack are >90% or less than XX voltage pack. If only 1 pack are >90% reduce charge (via voltage CAN) at XX volts (as in the last update)"
This is probably worth further discussion. Ive been thinking about this in terms of my setup which has a fairly small charge source relative to my pack size. So i was just going to use the minimum Max DVCC charge current value reported from any single controller to report to the inverter. Of course then that max current supplied by the charger will be shared by any parallel controllers so it would only ever see a fraction of that amount of current. Its not an accurate method but its the absolute safest. If we want to do something more accurate it will further complicate things. I have been trying to leave the CAN communciation completely separate from the other parts of the code especially when it comes to calculating DVCC parameters, etc. I suppose the next safest thing would be to take the minimum Max-charge-current and multiply it by the number of online controllers. Doing anything more accurate would require more integration into the existing DVCC code. Im not as knowledgeable at the actualy battery charge/discharge characteristics. Maybe somebody more knowledgeable can chime in and explain how it should be done .
Thanks for the update!
I see your point about the virtual pack, from my point of view, it seems safe having a single virtual pack being the master than letting any of each of the batteries became the master depending on his state. Also, I think is going to be easy for the victron (or another inverter via CAN) to have contact with one single virtual BMS instead of switching BMS.
In your scenario, how do you connect all BMS to the unique CAN port? Victron (at least) assign 1 ID to each battery. It is possible to add more batteries, but only one could be the master (as can be seen in the dbus serial battery project).
Cheers
Also, I think is going to be easy for the victron (or another inverter via CAN) to have contact with one single virtual BMS instead of switching BMS.
There's really no communication between Victron and the BMS. CAN protocol is multimaster which means there is no direct communication between any nodes. Any node can broadcast a message and every node hears it. So basically the BMS broadcasts data values over the network and Victron hears them. It couldn't care less who sent the message. The only issue would be caused by multiple nodes broadcasting the same message ID at the same time - we avoid this by making sure there is only 1 master at any time. Victron does broadcast 2 status messages but we don't do anything with those.../
In your scenario, how do you connect all BMS to the unique CAN port?
You can daisy chain the CAN Hi/Low connections from Inverter to controller to controller, to controller, etc. The last controller will need the 120ohm resistor activated with a solder jumper.
Victron (at least) assign 1 ID to each battery. It is possible to add more batteries, but only one could be the master (as can be seen in the dbus serial battery project).
I haven't looked at that project in depth. Can you point to exactly which section you are referring to? Assigning more than 1 battery to Victron is not particularly useful from my point of view- really just to see stats of a starter battery or something? As you say they only allow one "main" (let's not confuse the terminology you used here of "master"). And that is the one which allows you to control via the BMS-CAN port (thus the reason we need to aggregate).
Sorry for my last answer, I've been out!
There's really no communication between Victron and the BMS. CAN protocol is multimaster which means there is no direct communication between any nodes. Any node can broadcast a message and every node hears it. So basically the BMS broadcasts data values over the network and Victron hears them. It couldn't care less who sent the message. The only issue would be caused by multiple nodes broadcasting the same message ID at the same time - we avoid this by making sure there is only 1 master at any time. Victron does broadcast 2 status messages but we don't do anything with those.../
I got it, Thanks
You can daisy chain the CAN Hi/Low connections from Inverter to controller to controller, to controller, etc. The last controller will need the 120ohm resistor activated with a solder jumper.
Sure, I understand it now.
I haven't looked at that project in depth. Can you point to exactly which section you are referring to? Assigning more than 1 battery to Victron is not particularly useful from my point of view- really just to see stats of a starter battery or something? As you say they only allow one "main" (let's not confuse the terminology you used here of "master"). And that is the one which allows you to control via the BMS-CAN port (thus the reason we need to aggregate).
It is here on the issue "handle multiple battery" at some point, they say that with the driver, the venus os is able to get all battery data, but only one is been used as the battery, the others only appear there to show values.
https://github.com/Louisvdw/dbus-serialbattery/issues/8
Cheers
Any news about this. I have 13 banks , 13 modules , 182 cell modules. I would love to have data aggregation. I can test the code on my solar array or on a bench setup with 7 controllers and a spare growatt inverter.
I have many hours into getting something together for this. Unfortunately i've been wrapped up in some other things and not sure when i would be able to direct my full attention to it again. I would say it's 90-95% there. I really need someone with more programming skills to help dot the i's and cross the t's. My version as it exists handles most of your wish list in #213 . Perhaps there is a way to merge these 2 git issues into an enhancement label?
we can test the code if you want. i have no issues into that. Maybe Stuart can help us a bit.
I am happy to test once I get my other controllers up and running. My system is on a boat - 3 distinct batteries: bowthruster (12v), storage/house (48v), start/working (12v). Multiple BMS makes sense to me from a redundancy perspective. I will test with my benchtop 18650 setup rather than my working system. Cerbo GX on the boat, rpi w/ Venus OS at the bench.
I am happy to test once I get my other controllers up and running
Please let me know when you are ready.
Hey - I am ready. I have two new controllers up and I my latest batch should be done by tomorrow, to give me 5 total.
Hey - I am ready. I have two new controllers up and I my latest batch should be done by tomorrow, to give me 5 total.
If meningd didn`t respond to you I can give you the latest version. it works but has to be tested for bugs. Unfortunately I fried my inverter because I'm an idiot. if you have a WhatsApp number sent it to my email [email protected] so we can make a WhatsApp group .
Reverse positive and negative on the DC side of a Victron inverter? Been there, done that. Expensive lesson for me. I hope it sticks.
On Thu, Dec 21, 2023, 3:20 AM Toader Ionut Laurentiu < @.***> wrote:
Hey - I am ready. I have two new controllers up and I my latest batch should be done by tomorrow, to give me 5 total.
If meningd didn`t respond to you I can give you the latest version. it works but has to be tested for bugs. Unfortunately I fried my inverter because I'm an idiot. if you have a WhatsApp number sent it to my email @.*** so we can make a WhatsApp group .
— Reply to this email directly, view it on GitHub https://github.com/stuartpittaway/diyBMSv4ESP32/issues/184#issuecomment-1865843777, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG5ERR3QAYENA7M34HO4BSLYKPWNBAVCNFSM6AAAAAAV2XE2P6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRVHA2DGNZXG4 . You are receiving this because you commented.Message ID: @.***>
I see that meningd doesn't have any public repos. Does the binary you sent me come from your fork, Toader? Before I dig in, I would like to get an idea of how to test. Do I need to update VenusOS? Meningd said he got 95% there. Do you happen to know what is missing?
I think the best way forward is for me to diff the fork with the multi-master code and Stuart's main to see what has changed and get an idea of how the change is supposed to work. Unless there is some documentation floating around that I haven't seen.
Is supposed to work with any inverter over can bus. just flash it put the controllers in parallel then straight to inverter. Meningd can give you more info about it.
There are a few new options on the config page for the intra controller can traffic. Set the total # of controllers, a unique controller id, and whether the network should operate under high availability mode. Every piece of data normally communicated to the inverter is aggregated so all that needs confirmed working. Especially victron and pylon are 2 completely different protocols so there are a lot of diff alarms etc that need tested. For HA mode, if a controller goes offline the master will still transmit DVCC so only use that if each controller has its own disconnect relay.
Awesome, thanks for the info!
On Fri, Dec 22, 2023, 6:17 AM menningd @.***> wrote:
There are a few new options on the config page for the intra controller can traffic. Set the total # of controllers, a unique controller id, and whether the network should operate under high availability mode. Every piece of data normally communicated to the inverter is aggregated so all that needs confirmed working. Especially victron and pylon are 2 completely different protocols so there are a lot of diff alarms etc that need tested. For HA mode, if a controller goes offline the master will still transmit DVCC so only use that if each controller has its own disconnect relay.
— Reply to this email directly, view it on GitHub https://github.com/stuartpittaway/diyBMSv4ESP32/issues/184#issuecomment-1867565566, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG5ERRYOXCOGZHXI46VGO63YKVT5RAVCNFSM6AAAAAAV2XE2P6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRXGU3DKNJWGY . You are receiving this because you commented.Message ID: @.***>
Thank you very much for the firmware, Toader.
Here is my test setup:
- (1) Controller: Rev.be885e1 w/ the firmware you sent (1) Module: v4.9 w/ module_fw_V490_AUTOBAUD_VREF4096_genericSTM32F030K6T6 (1) Battery: 16s1p 18650, charged to a max of 3.65/cell
- (1) Controller: Rev.be885e1 w/ the firmware you sent (1) Module: v4.9 w/ module_fw_V490_AUTOBAUD_VREF4096_genericSTM32F030K6T6 (1) Battery: 16s1p 18650, charged to a max of 3.65/cell
- (1) Controller: Rev.be885e1 w/ the firmware you sent (4) Module: v4.5 w/ module_fw_V450_10K_ATtiny1624_450_e0_h0_l0 (1) Battery: 4s1p 18650, charged to a max of 3.65/cell
Next step is to connect them via can to my rpi3b running VenusOS. I hope to get them talking this weekend, but I have a 6 y.o. and an 8 y.o., so that is possibly optimistic didn't happen. I am probably going to start by logging the can messages of just one of the batteries with JP1 soldered and then iteratively add the additional batteries (controllers.) The first attempt will be daisy-chaining them with just the last of the controllers terminated (with the JP1 resistor) and see if that works.
Is the source on a branch from Stuart's repo or can I get it somewhere else? I would like to get an idea what to test for by looking at the changes between versions. If you have any suggestions, please let me know.
Tim
On Thu, Dec 21, 2023 at 4:43 AM Stuart Pittaway @.***> wrote:
Really interested to see how this goes - good luck to all involved.
— Reply to this email directly, view it on GitHub https://github.com/stuartpittaway/diyBMSv4ESP32/issues/184#issuecomment-1865952116, or unsubscribe https://github.com/notifications/unsubscribe-auth/AG5ERR5MZV2VSTZSMCFZUUTYKQADTAVCNFSM6AAAAAAV2XE2P6VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNRVHE2TEMJRGY . You are receiving this because you commented.Message ID: @.***>
There is one more person testing on Victron but we need all the help we can get.
Based on what i heard works well on Victron.
I personally have 2x growatt SPF500ES and works very well. 8 days uptime without hiccups.
You can test alarm outputs , simulate various failures , etc.
So far we had some issues with losing coms with cell monitoring boards , the controller that had the fault would simply send a stop charge request and the inverter stopped charging. In High availability we do not want that because defeats the purpose of high availability . so far we implemented a fail safe , when a internal BMS fault occurs the controller is disconnected from can bus and would not reconnect until user intervention.
We still have to look at the rules and maybe with @stuartpittaway help we can manage do that.
Rules improvement will be in principle , when an internal fault is present , the controller should enter in a failsafe mode , disconnecting the master relay and interrupting the can bus communication.
The version you have is no longer the latest , please ask @menningd for latest bin.