Hi,
I have already had the opportunity to thank Stuart Pittaway for the excellent work that I can witness. I recently finished the 5th and 6th li-ion cell modules and added them in parallel to my service battery. In total there are now 6 modules of 14 cells in series, connected in parallel. That is, there are 84 cells in a 14S6P configuration. The usable capacity is approximately 11kWh. The controller is esp32 and each cell has its diyBMS module 4.40. The controller and modules version is from last November with the communication set to 9K6. It’s communicating by MQTT with my Home Assistant with a refresh rate of about 60s, identical to what I had before changing the communication speed. It has a very low number of errors, the roundtrip is 4444ms.
I checked the following situations that I would like to post here:
the voltage values ​​of the last 4 modules (80, 81, 82 and 83) are only updated initially after powering esp32. Afterwards the values ​​are never updated again. This is reflected in the Range 5 values ​​on the WEB page and also in the values ​​sent via MQTT. Also, the sequence of blinks in these modules is much rarer than in the others.
Despite the low number of OOS errors (less than 1 per day!), there is a very big difference between sent and received (eg 44079 VS 31104). This is normal?
Since communication between modules is much faster, would it be possible to also increase the sending rate via MQTT?
I apologize for my english and if I am not supposed to ask these questions here.
Well, electronics is a science of electric contacts, choose simplest way and try to swap communication wires between modules. Then try simple way and reduce length communication wires between controller and modules.
Okay, here’s what I’ve done these past few hours:
I exchanged the last 5 modules (79, 80, 81, 82 and 83) with 56, 57, 58, 59, 60 and 61 (no changes)
I changed all the communication cables of these last 5 modules (no changes)
I changed the controller board (esp32 + pcb) for another one, placing it close to the modules and thus shortening the communication cables to as little as possible (no changes)
set to 84s1p instead of 14s6p (no changes)
I walked the communication cables 4 modules to the front (ignoring the first 4) and set it to 80s - the last 4 modules are read regularly now!
I could be wrong but it seems that there is no hardware error!
Stuart, here are the screenshots that indicate that in 30 minutes the difference between sent and received packets is already quite large and on the “Modules” page the received packets are very identical, with only a difference of 1 between groups of 16 modules. Coincidence or not, in the sequence of reading (winks), the last 4 modules are the beginning of a new group of 16 modules…
To conclude the reasoning, let me say that in these 30 / 40 minutes the last 4 modules only read / updated voltage values once when I powered the system. They never updated values again, neither on the web page nor via MQTT.
This won’t be a coincidence - the modules are read in groups of 16, although at the moment I can’t see why the code would ignore them. The controller code at least seems to be doing what I would expect of it.
Ok Stuart,
It might be helpful to add that the current behavior (last 4 out of 84 modules not communicating) was like that even before I updated the controller and modules software. Before there was a September version with standard communication, the problem was already noticeable.
If you need me to do some testing / experience with the hardware I have please say so.
Theres a new “Send Q Length” info display which reports how many items are queued up (maximum of 30). This isn’t a problem if it gets to this level, its just for info.
