Another design consideration: for larger DIY packs (4p16s, for example) with a single BMS it is difficult to troubleshoot a problematic cell. Ignoring additional cost, the preferred approach would be to assemble four 16s packs in parallel (16s4p), each with their own BMS. In this situation, each BMS would need its own IP address, ideally with peer-to-peer data sharing between each BMS. Thoughts?
Yes, of course, you can have as many BMS as there is available IPs on your network. My solar install will be exactly what you described in your example: 4 packs in // of 16 cells in series each
For the data sharing directly between BMS however I've not planned to do that but you can have a central device acting as a gateway between the BMS if you want.
Or you can change the code (will be released under the GPL license) if you want to implement direct com between BMSs (but again the flash/RAM space available to add that will be very low as I'll probably use pretty much every byte available... you can always remove other things you don't need for use case if you need more space though).
I'm curious to know what would be the main purpose of direct com between BMSs? I don't want to miss something important (it's hard to think about everything on your own...)
I'm working a similar project and I'm using a ESP32 (it has BT and WIFI). ESP also has nice device with wired connection.
The ESP32 is nice but a bit overkill for what I'm trying to do I think. The power requirement is also a problem, it would probably eat more power on its own than the whole arduino based BMS, and you need to add ethernet com power on top... I also prefer a MCU to a SoC as it's more reliable and doesn't depends on an OS.
All of these reasons are why I chose the Arduino over the Raspberry Pi too.