OpenEnergyMonitor Community

84 diybms modules - not working as expected

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.

Thanks again!

Please take a screenshot in browser of “Modules”. There is counter “Bad packet count” for each module it would be informative.

Yes, do this please. You are losing packets somewhere

Okay thanks, here it is the “Modules” page:

And the “Home” page:

Maybe it doesn’t have anything to do with it, but the display only shows the first 4 battery banks…:

The Range 5 and Voltage 5 are wrong and in the graph too. I dont see Bad packet count.

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.

The packet counters on the modules should all read the same value.

Can you click the reset counters/clear error button and give it a few hours to see what the count then look like?

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…

1 Like

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.

Ok, looks like a software issue.

Can you confirm which version you are using (on the about page)

Of course, thanks Stuart. Is this ?

Platform & Version

Host name:DIYBMS-00637F1C

Processor: ESP32

Version: abd57a2bfd7856d65d89f3789872c32bcb52b748

Compiled: 2021-11-29T14:36:21.246Z

Language: language

SDK Version:v3.3.5-1-g85c43024c

Min free Heap:71904

Free heap:90016

Heap size:295728

Thanks. Now just to find out why it’s not reading the last few modules correctly

Thank you Stuart for your time. I wish I had the knowledge to help you in this task…

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.

I’ve moved this conversation to its own thread on the forum, and also created an issue for the problem.

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.


Thanks for reporting the issue - there are not many people running such a large installation, so it may take a bit of time to investigate.

1 Like

Made some progress, looks like the controller code has a problem.

With so many cells, there is an internal queue of messages which becomes full - therefore the last few cells are never read correctly.


I think this is good news, the problem is identified! Excellent work!

Hi @SergioF

Can I ask you to try updating your controller firmware to this test version?

You should be able to update as you would do normally (following instructions on GITHUB).

The file on this page [Merge branch 'master' into bug-fix-70 · stuartpittaway/[email protected] · GitHub]

and named " DIYBMS-Release-Artifact-2021-12-14-16-37"

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.