Edit 2022-11-28: I made an index of the various parts of this thread to save you from scrolling too much: https://diysolarforum.com/threads/diy-bms-design-and-reflection.4065/page-31#post-650424
I did not want to start this thread until I would be far enough in the development but a post in another thread sparkled an interesting conversation so here we are
So I'll continue the conversation here to avoid polluting the other thread and I'll explain my current design just after (so if you don't care about the initial conversation you can jump directly to this part), be warned it'll be an in-depth technical description.
@Dzl
Yes, I saw this BMS and his other projects, they are very interesting but they doesn't really do what I need/want (for example I need a 16s BMS, this one is 8s max). When I was talking about ethernet I should have been more clear: I want TCP/IP communication, not just using the ethernet hardware layer with another software protocol like UART, SPI, I2C, ... The main reasons are that I can easily use a switch to connect everything together without some central "brain" as if I was using a more usual MCU protocol, it is really well immunised to a lot of RFI, EMI, etc., it's galvanically isolated, it can go up to 100 m of cable without problems, it's fast, it has errors detection/correction built in, ...
When I said isolation I meant isolation in the functions, not isolation in the communication. It's not the job of a BMS to stop the SCC from charging, but it's the one of the SCC to interrogate the BMS and stop the charging. Another example would be the heat pump: it's not the BMS who tell the heat pump what to do, it's the heat pump who decide what to do after getting data from the BMS. Because otherwise you mix the BMS logic with a lot of other things' logics and you have a mess.
The distinction between ignorant and independent is really important: yes I want the devices to be independent (main reason after not having a big messy ball of things is failsafe: everything must still be working (even if in a degraded mode) if all communication is lost) but I certainly don't want them to be ignorant, that's why they communicate after all
@Steve_S
As I said to Dzl I want TCP/IP, not just converting another protocol to ethernet. I also don't want to adapt everything to everything with arduino/RPi because it'll be a mess (I'll not have the choice for some things like the SCC, however I'll do the conversion once to TCP/IP instead of converting for every other protocols, but the less I have to do that the better of course).
So apparently I'm over the 10 kchars/post limit, oops... well, I'll split into 2 posts then.
Edit 2021-01-20: This thread is a very detailed record of the design process, the choices I made, etc... so I made this other thread if you just want to see the features list, the specs, the schematics, etc...
I did not want to start this thread until I would be far enough in the development but a post in another thread sparkled an interesting conversation so here we are
So I'll continue the conversation here to avoid polluting the other thread and I'll explain my current design just after (so if you don't care about the initial conversation you can jump directly to this part), be warned it'll be an in-depth technical description.
@Dzl
Not sure if its exactly what you are talking about but the maker of the SBMS0 (I highly suggest you learn about his projects, I suspect you will connect with his design style), recommends using Cat5 or Cat6 cable for external connections, I think this is not the same thing as what you are talking about, just the same cable. Here is a link to the manual.
Yes, I saw this BMS and his other projects, they are very interesting but they doesn't really do what I need/want (for example I need a 16s BMS, this one is 8s max). When I was talking about ethernet I should have been more clear: I want TCP/IP communication, not just using the ethernet hardware layer with another software protocol like UART, SPI, I2C, ... The main reasons are that I can easily use a switch to connect everything together without some central "brain" as if I was using a more usual MCU protocol, it is really well immunised to a lot of RFI, EMI, etc., it's galvanically isolated, it can go up to 100 m of cable without problems, it's fast, it has errors detection/correction built in, ...
I can understand wanting to maintain isolation and see the benefit of that approach. But I feel like how you define the BMS's 'job' is unnecessarily limited and absolutist. A BMS is a system of managing and protecting the battery. That means preventing overcharge, overdischarge, etc. Communicating with chargers and load side appliances (inverters, battery protects, etc), and telling them when its acceptable to charge/discharge the battery is within a BMS's scope of responsibility. Whether it communicates directly, or whether it opens/closes a relay, or handles the (dis)connection of charge sources and loads internally is a design decision. But all are methods of managing charging and discharging. Keeping each device ignorant and independent of the others as you advocate has its merits as you correctly noted, but being able to communicate with external devices has its own merits, and is in some ways might be a more elegant solution. I also want to clarify that I mentioned communicating with external devices, not controlling, which are somewhat different things.
When I said isolation I meant isolation in the functions, not isolation in the communication. It's not the job of a BMS to stop the SCC from charging, but it's the one of the SCC to interrogate the BMS and stop the charging. Another example would be the heat pump: it's not the BMS who tell the heat pump what to do, it's the heat pump who decide what to do after getting data from the BMS. Because otherwise you mix the BMS logic with a lot of other things' logics and you have a mess.
The distinction between ignorant and independent is really important: yes I want the devices to be independent (main reason after not having a big messy ball of things is failsafe: everything must still be working (even if in a degraded mode) if all communication is lost) but I certainly don't want them to be ignorant, that's why they communicate after all
@Steve_S
@BiduleOhm Many BMS' (all the smart ones in any case) can be communicated with. Most have a UART option if not already enabled. "Dumb" BMS' which have no comms at all (BT or otherwise) are moot on this point. Not all Inverters or SCC's can communicate with a BMS, it's only now starting to really come into play but really, many also do not even directly support Lithium Based batteries either yet. In a perfect world hat would be different but it is far from a perfect world. Are you aware that a RaspberryPi,, Arduino and similar can be used as an intermediary, a manager, a Modbus controller... various ones can accept RS232/485 directly with a "hat" add-on or various BMS' & other devices could also route through a USRIOT device (there are others as well but USR is top notch) https://shop.usriot.com/serial-to-ethernet/serial-ethernet-converter but these can also do Serial to WIFI, CanBus and more....
BTW: I run a Midnite Classic SCC, great controller but dumb as horse manure when it comes to BMS, Lithium Based Batteries but it can be programmed around to work (kludge IMO) but it works. My Samlex Inverter on the other hand CAN talk to a BMS and has some Lithium intelligence in it's programming.
As I said to Dzl I want TCP/IP, not just converting another protocol to ethernet. I also don't want to adapt everything to everything with arduino/RPi because it'll be a mess (I'll not have the choice for some things like the SCC, however I'll do the conversion once to TCP/IP instead of converting for every other protocols, but the less I have to do that the better of course).
So apparently I'm over the 10 kchars/post limit, oops... well, I'll split into 2 posts then.
Edit 2021-01-20: This thread is a very detailed record of the design process, the choices I made, etc... so I made this other thread if you just want to see the features list, the specs, the schematics, etc...
Last edited: