• Have you tried out dark mode?! Scroll to the bottom of any page to find a sun or moon icon to turn dark mode on or off!

diy solar

diy solar

Developing a new BMS, feedback wanted...

Anx2k

Solar Enthusiast
Joined
Nov 11, 2023
Messages
78
Location
Phoenix, AZ
At my company we've got a product that uses an off-the-shelf BMS, but we've decided to roll our own for a variety of reasons. I'm hoping that once we finish it, we might make it available to end users as well, so I thought I'd just see what kinds of features people might be interested in, that we either aren't doing or haven't considered. Since we're just in the initial hardware sourcing and schematic stage, it's a good time to get feedback as it's impact will be the smallest. I would expect if we make it available, it would be towards the end of the year, depending on scheduling and availability of parts, etc.

In terms of current features, here's kind of the main ones - and keep in mind most of these are requirements for our internal project, so unlikely we'd change them in any meaningful way. This will also use a software stack we've developed on other devices, so a big chunk of the software side of things is already done.

On the communication side, we're primarily ethernet-based, so it will have both an CAT5 port as well as a single switch port (as we sometimes daisy chain devices). We have a full web RESTful API for all the control of the device which covers 100% of the devices operation, so easy to integrate. We'll also probably add a single CAN and single RS485 ports (both isolated) to allow integration with other systems (although we currently don't use those). We'll also have WiFi on board, but it can be disabled so it's 100% wired.

For basic specs, it will be rated for 300A, and will handle from 3 to 24 cells, and will support both passive (0.1A) and active balancing (2.0A, due to the wire gauge for the current sense cables). It will have all the usual things such as hardware over current/voltage/temp, under voltage/temp (via TI components, I believe) - and we'll have 4 external NTC hookups, as well as several onboard temperature sensors, to monitor the board/environment. In terms of current sense we should comfortably be in the 0.01v range, and will support calibration as well. We actually have a NIST power and temperature calibration lab on-side, although I don't think we'll be using it to calibrate the devices directly, we will be using it to calibrate the components we use in the calibration process, so it should be pretty spot-on.

It will have an onboard RTC, as well as storage for logging of any events that take place, as well as an onboard color LED and piezo buzzer (both with external connectors) to indicate an issue. We already have a SOC tracker that's advanced and fully configurable (uses Peukert exponent, DoD, rules based full charge indication, estimated runtime, load over period, etc). There will also be 2x 12v 4-pin PWM fan headers, to add temperature controlled (or manual) fans for cooling.

On the software side, it's all configured via a web interface - no apps or anything else, so any browser on any device should be fine. We're big believers of this, as it can all happen locally and doesn't require an app store or any other 3rd party components. It has full MQTT support and auto-discovery with Home Assistant, and it can export controls (such as enabled/disabling charge or discharge), but device configuration has to happen all in the web UI. There's also logging functionality built-in, so if you don't have access to something like HA, we can log into a csv on-device and you can just download it and work with it in Excel or whatever you'd like. And firmware updating can be done both locally and via the Internet.

Finally, on the I/O side there will be 4x wet relays - we're still sourcing these, but they should be AC or DC, and should handle around 3A. They won't be dedicated to a particular function, but configurable to use with heating elements, contactors, alarm circuits, etc. There will be 3x isolated inputs and 3x isolated outputs, once again configurable for buttons or whatever. We also have one reset button and one general purpose button that we use for our control, and are already defined.

As you can see from the featureset, it's not going to be a cheap replacement, but we're also hoping that it won't be crazy expensive either - and will have the plus that it was developed in the US (primary) and Europe. That's it! Thanks for taking the time to read everything and look forward to hearing any feedback anyone has! :)
 
Nice, especially like the Ethernet, web interface, MQTT, and other "Dragged Kicking And Screaming Into The Nineties" features. I might have missed it, but will there be some kind of REST or other web API? The only other thing I can think of would be SNMP, but I don't really use that any more myself, so it's not a particular wish, and is getting a little long in the tooth (unless you do V3, which is a whole other nightmare).
Multiple UI users would be nice, so you can have viewers separate from controllers.
 
heheh, I totally agree - to me it's crazy that ethernet isn't the preferred protocol, especially now that you can get switch IC's for a couple bucks to allow daisy chaining like we do. Granted, it's 10/100, but that's more than enough for these kinds of applications.

In terms of API, it's a RESTful web API - the actual web app itself is written in React so it just uses the exact same API for all of it's calls. We also have full swagger documentation, so that would be available as well, so no mystery as to what endpoint does what.

As far as SNMP, we've thought about it off and on since we are very much network-forward, but like you said, we actually don't use it internally either, and while people have mentioned it with our other products, no one has really wanted it. Ironically we do support Syslog (it's not on by default), but really it's more for debugging and nothing else - just one of those classic legacy protocols. ;)
 
so ive noticed in my battery, cell voltage surge causes the active balancer to actually unbalance the cells during bulk charge, but then as current drops during absorption phase, the surge settles down and the balancer actually starts to work correctly. i could set absorption to very long, but it would basically be overcharging the battery to be able to balance it. it would be nice if the balancer could be disabled if charge current was over a setting, that way its not affected by cell voltage surge, and no unbalancing would occur
 
ive noticed in my battery, cell voltage surge causes the active balancer to actually unbalance the cells during bulk charge, but then as current drops during absorption phase, the surge settles down and the balancer actually starts to work correctly
Maybe one cell has a higher resistance than the others? Or the terminations have a high resistance (might be worth checking the torque specs)?

So on the wish-list: Determine battery health using as many parameters as you can log, detect the above, etc.
 
Multiple dry contact with programable parameters.

Example, if pack voltage over 55.2v or any cell over 3.45v, activate the dry contact, useful for adding external Heltec 5A capacitive active balancer to assist the BMS 2A supercapacitors balancing? Reason, that 2A balancing probable one to one cell......meanwhile Heltec 5A balance all cells simultaneously. Release dry contact after xxxxx etc.
 
I don't think adding ethernet makes any sense, you are not transferring enough data to justify ethernet speeds not even 10 base. RS485 and Canbus would be sufficient.

Instead of adding all the web api and stuff on the BMS itself you would be better off using a device like a raspberry pi and have it monitor/control bms. These features will require a powerful microcontroller that would be draining the batteries when not in use.

I personally prefer the capacitator style approach to balancing vs the JK approach of charging up a capacitor and sending 4-5v onto a cell to get it to balance.

relying entirely on a webserver to do the configuration will again require a strong micro controller, which means more idle draw and you'll need to have wifi running the entire time, I'd recon you would be using about 30-50 watt/hr day just idling doing nothing.

So overall I think your design is not very practical, I think it should be a split design where smaller units attach to a single large base unit like a raspberry pi and that handles all of your ethernet, webserver, and other needs.
 
Ethernet is a requirement of our internal project (all of our comms are done with ethernet), and the Web API, etc are all already done, they don't take any work for us as they're part of our existing platform. We're solving our own use case first and foremost, but I think that some people might also like some of the things we're designing into it and the overall featureset. And if people don't want this kind of functionality, they can literally buy any other BMS as none that I'm aware of are designed around ethernet. :)

Processor-wise we're using the ESP32-S3R8N16 (it's the standard processor we use these days) - and while I don't know the consumption of this board yet, we have a PoE board we use to monitor the current system, and it's power consumption is right around 5v/200ma, so you're looking at about 24wh/day, and that's full duty cycle - we already have a mode where you can put it in energy efficiency mode, and it will light sleep for whatever the shortest service interval is. This doesn't reduce that 200ma to nothing, as there are other components consuming that current, but it does cut it typically by about 100ma, so you'd be at 12wh/day. We also can go into a deep sleep mode and shut off virtually all of the peripherals - in which case the board probably is under 0.5ma, which we normally use for transportation mode, etc - but keep in mind that when you put it in this mode, it's basically doing nothing. WiFi (using modem sleep) adds about another 20ma or so when not in use and up to about 100ma when fully hammering it (by this I mean hitting it's RPS max, which is about 40/s or so) - but using wired ethernet there's no appreciable power consumption difference when used or not used. And under normal usage the system isn't just sitting there pondering it's own existence - it's actively monitoring the cells, performing logging, doing the rules evaluation, servicing can/rs/ethernet, etc.

In terms of the active balance, to some degree that's out of our hands, as I believe it's choreographed by the TI part, and we're using a 2A supercap to balance as AshleyL mentioned. I think they do it this way is so they can actively monitor all the cell voltages even during the active balancing, as opposed to the bank of caps like the Heltec uses - but just like with any other BMS, nothing precludes you from hooking one up at the same time as the BMS, it just will effect some of the voltage readings.

This isn't to say you shouldn't still use a Raspberry Pi or similar for monitoring - as our platform is more for simplified configuration, viewing live data/logging, and troubleshooting issues. It's just with a web API it makes it pretty trivial to integrate into whatever monitoring package you want - like I use Home Assistant, and I love that when any of our devices are added to the network, HA automatically detects them and adds all of the data points we export via MQTT.
 
Multiple dry contact with programable parameters.
I think the ratings on the relays should be fine for dry contact, and you also have the isolated outputs as well (although you'd need to be at the same voltage, or somewhat voltage agnostic), so you should be covered there.

In terms of triggering them, we haven't really actively discussed it but more than likely we'll use a little scripting systems we have - it's very simple, think of it kind of like regex, where you can enter in variables from the system (such as pack voltage, a particular cell voltage, etc), and perform some test against them - and it it's zero it will ignore, or not zero it will trigger. You should be can test them in the UI as well as see how they expand, and I imagine it will let you do most anything you'd want - and if something isn't covered, we can extend it pretty easily.
 
For context, here's what the web UI looks like now for the BMS monitoring we currently do - this is just from a normal JBD BMS and Voltronic hybrid inverter:Batmon.png
 
At my company we've got a product that uses an off-the-shelf BMS, but we've decided to roll our own for a variety of reasons.

Nice description of BMS with many features been looking for... Any prototypes yet? Any guesstimate on when it may be available for the public to purchase?

Please keep us informed on the progress.
 
If you can, when one cell hits peak: throttle the charge current (and carry on balancing) rather than tripping out.
That would cut down on the noise from people worried about cell mismatches.
 
Setting to allow for or to bypass the BMS for initial inverter capacitor fill surge.
 
Just thinking out loud
Master/slave BMS settings. Can log into the master and see/control all other linked BMS, see their cell voltages, etc
 
1) Allow cell voltages of 3, 6, 12, & 24v. Then it can be used to put 4 12v (8 6v, 2 24v) batteries in series.
2) "Start Parallel function" where it:
a) Starts with Discharge Off, Charge Off​
b) If connection voltage > battery voltage, then enable discharge. Enable charge when battery starts discharging​
c) If connection voltage < battery voltage, then enable charge. Enable discharge when battery start charging​
3) Precharge resistor circuit when battery first starts discharging
4) Master/Slave setting where battery # doesn't matter. Master polls slaves at startup, and displays # of connected batteries. Benefit: I can take Battery #4 off-line, and master adjusts.
5) Master can request lower charge voltage when a BMS has out of balanced cells and needs time to balance. This prevents Cell Overvoltage Cutoff.
6) Store history for period of time, say 1 day. Pack Voltage, Pack Amps, Individual Cell Voltages.
 
Nice description of BMS with many features been looking for... Any prototypes yet? Any guesstimate on when it may be available for the public to purchase?

Please keep us informed on the progress.

We've done the bulk of the part selection and are doing basic schematics and board layout - that's why now is the right time to talk about features we might be missing, as the impact is at it's least. We've internally talked about all sorts of things, and there's a couple features I think will be pretty cool that I haven't mentioned, just because we're not 100% sure if we'll be able to do them or not. Assuming no gotcha's come up, we're probably looking at about 60-90 days until we have functional prototypes we'll start testing with - and when I get the first boards I'll make sure to post some updated. ;) Assuming the prototypes are running well, we might allow some people to beta test the boards - but really that would be for someone who really actively plays around with batteries a bunch, not someone who wants to set-it-and-forget-it, and if so I'll certainly post on here. In terms of general purchasing, I would say Q4 is probably realistic.

Setting to allow for or to bypass the BMS for initial inverter capacitor fill surge.

heheh, this is actually one of those things I just mentioned above - we think we'll be able to integrate a precharge mechanism on the BMS, and on paper it seems like it will work, but we'll see.
If you can, when one cell hits peak: throttle the charge current (and carry on balancing) rather than tripping out.
That would cut down on the noise from people worried about cell mismatches.

That would certainly be cool, and I'll add it to the list. :)

Just thinking out loud
Master/slave BMS settings. Can log into the master and see/control all other linked BMS, see their cell voltages, etc

In the screenshot above, you can actually see our 'pairing' option, and that allows you to do something along these lines. You can link up different devices, and their data is pushed to the master. While you can import/export all the settings, and I wouldn't have any issue with allowing you to push general UI settings, the advanced ones (such as related to cell voltages, pack voltages, temps, etc) - I'd probably still leave as manual configuration, just as it could be particularly bad if they were sync'd by mistake when packs were slightly different, etc. I will say that the pairing in it now is meant more for when devices are designed to work together (like maybe you have 3 BMS's and you want them to act as one, so they would disable charging and discharging together). For visualization, usually we recommend using some other platform - in my case I use Home Assistant, but it would probably integrate into most common dashboards without much efforts.

1) Allow cell voltages of 3, 6, 12, & 24v. Then it can be used to put 4 12v (8 6v, 2 24v) batteries in series.
2) "Start Parallel function" where it:
a) Starts with Discharge Off, Charge Off​
b) If connection voltage > battery voltage, then enable discharge. Enable charge when battery starts discharging​
c) If connection voltage < battery voltage, then enable charge. Enable discharge when battery start charging​
3) Precharge resistor circuit when battery first starts discharging
4) Master/Slave setting where battery # doesn't matter. Master polls slaves at startup, and displays # of connected batteries. Benefit: I can take Battery #4 off-line, and master adjusts.
5) Master can request lower charge voltage when a BMS has out of balanced cells and needs time to balance. This prevents Cell Overvoltage Cutoff.
6) Store history for period of time, say 1 day. Pack Voltage, Pack Amps, Individual Cell Voltages.

1) The TI part, their cell voltage range is between 0.3v and 5.5v, so we're pretty much locked into that range - but on the plus side, that should work for most types of chemistries. The big advantage of using an IC like this is that all the safety aspects are handled by custom silicon and well understood.
2) Interesting, I'll have to think about how best to handle this - it might be worth it to just make it possible to use the scripting system to define the logic for charge/discharge - then you could tweak it however you liked.
3) Refer to above. :)
4) So we support pairing up devices, but usually it's more meant for them to share data and act collectively. So for instance we have one device that measures ambient air quality, and other devices pair with it to then control ERV's, etc. Generally speaking it's fairly fault-tolerant, but it doesn't really roll things up - so in your example (as our system currently works) if 4 batteries were paired, the master wouldn't really look like a single bigger battery, it's more that it would push logic to the other 3 units, such as disabling charge/discharge, etc. That being said, I'm just describing how it currently works, we don't have anything like the BMS where it makes sense to combine them into one larger thing, so that might be worth looking into doing.
5) Yeah, this would be more along the lines of what our pairing stuff would normally do - the master gets info from the slave devices, and then performs a particular action.
6) There's two kinds of logging we do - normal logging, which is like the information you see on the live view from the screenshot, which is basically every little bit of data we get (and I do mean everything). You can specify whatever interval you want (in seconds, minimum 1), what kind of file resolution you want (Hour, Day, Week, Month), and whether you want the files compressed or not (it zips them). Our defaults are normally 1s interval with Day file resolution and compressed, so each file is for a particular date and zipped up - and you just download it via the web interface. It will automatically rotate through the files, so the oldest file gets deleted to make room for the new file, once it runs out of space. Onboard we reserve about 1 megabyte of space for logging, so normally that's more than enough space especially when the files are compressed. The second type of logging is for 'Messages', which we keep the life of the device (although you can delete them if you want), and those are basically exceptions, so when something happens that is considered an edge case, or if you've configured some sort of notification action, they get logged into here.

Awesome feedback! :)
 
Like the list... web (phone not needed), ethernet, local, etc but would like to suggest easy query for data by HTTP instead of MQTT alone.

One feature I really like about IotaWatt is their Query API - https://docs.iotawatt.com/en/master/query.html It's not the syntax but the HTTP query functionality - easy to pull data, test in web browser, write custom code and integrate with my own custom web page / dashboard. For example, this is my PHP function (any language can do this) to retrieve current stats every few seconds - easy as it gets.
1717433154286.png
 
Last edited:
Looks to have the potential to be a fantastic product. CAN and RS485 communications to various inverters would be super useful.
 
Not really sure what is and what is not possible. So my only advice is that the fail state of the BMS is no current flow allowed. As I understand it now most BMS fail such that all protection is gone. At the very least an alarm should be initiated to warn of failure.
 
For context, here's what the web UI looks like now for the BMS monitoring we currently do - this is just from a normal JBD BMS and Voltronic hybrid inverter:View attachment 219252

Sorry but no way you are running this web interface on an esp32, if you want to see what type of things you can do a search on you tube. The above interface will require a raspberry pi minimum.
 
Like the list... web (phone not needed), ethernet, local, etc but would like to suggest easy query for data by HTTP instead of MQTT alone.

One feature I really like about IotaWatt is their Query API - https://docs.iotawatt.com/en/master/query.html It's not the syntax but the HTTP query functionality - easy to pull data, test in web browser, write custom code and integrate with my own custom web page / dashboard. For example, this is my PHP function (any language can do this) to retrieve current stats every few seconds - easy as it gets.
View attachment 219368
As I mentioned above, everything is done via the web API, and it's all RESTful and virtually all responses are JSON and very much human readable. We do all the documentation in swagger for it as well, so there's no guesswork as to what anything is anyway. It's just we also support MQTT so it's pushing data instead of polling, so faster updates and less load on the system overall.
 
Sorry but no way you are running this web interface on an esp32, if you want to see what type of things you can do a search on you tube. The above interface will require a raspberry pi minimum.
haha, I'll take that as a compliment. ;) I can assure you that it's not only running on an ESP32, but already on commercially deployed products - just in the medical space, not consumer. If you refer to my earlier posts I go into some detail, but the actual UI is all done in React, or more specifically Preact, which is has a much smaller footprint. The entire bundle (including artwork) is compiled into a single bundle.js that's about 408kb, we then gzip compress that to about 116k, convert it into a .h file and it's compiled into the our base code. As mentioned before, we're not using the bare bones S3, we use the R8N16, and instead of 1MB firmware images (the typical for dual partition versions), we configured it as 2MB - and the beyond the initial download of the react, the rest of the time it's only making REST/JSON calls to the ESP32.

I think most people just see what projects like Tasmota or ESPHome do for a web UI and assume that represents at least a decent implementation, but honestly they're not really focused on the WebUI so they don't spend much time on it. For us it's a key factor, so we spent a fair bit of time working on it and making it as polished as we could.
 
Not really sure what is and what is not possible. So my only advice is that the fail state of the BMS is no current flow allowed. As I understand it now most BMS fail such that all protection is gone. At the very least an alarm should be initiated to warn of failure.
Hmm, so I suspect this is a tricky one - but we'll certainly keep it in mind. My guess is that with hardware, your failure state is many times whatever the board comes up as when receiving power (assuming the MCU fails for some reason), and many times when you reboot the board also quickly cycles to this initial state (depending on the type of reboot). So if you have to reboot your MCU for some reason, it's probably not very desirable to have the system basically blip off then back on again - so they instead have it on by default and then the MCU has to instruct it off. Now if the battery voltage goes low enough, and they can't handle the lower voltage correctly, I could see the MCU suffering from brownouts and not working correctly, which in turn could leave it in a kind of limbo where it's leaving the BMS operating when it should have shut it down.
 

diy solar

diy solar
Back
Top