DIYBMS v4

Mike, was thinking along these lines, probably not change the original code, but have another variable that is NOT reset and keeps on adding.
Of course then the issue is what happens when system (for any reason!) is reset, you loose the log, hence my thinking of either writing another log file and keeping that as total Ah used by the bank from inception, or divide it by Ah of the bank and then you log a “theoretical” number of full cycles the battery has done.
As a belt and braces approach, you also send that to influxDB :grin:

You can fake it being optional, just by setting a very high tail current value, so it never resets - although do note that the SoC will always be incorrect then as well.

Yeah, I fixed my SoC the other day and noticed afterwards that it resets the Ah in/out when it hits the estimated 100% SoC.

Yeah, but then I’d need another device to capture all of that data which I’d like to avoid.

How about logging the data output with short intervals in a database, then have the database sum the values up (every 24h) in a new record and delete the summed up values? I use this already for 6 years to keep track of my PV installation.

Hi,
I’m back with my 14S 80P x 5 Installation (70 modules in series)…
As I couldn’t solve my timing-issues with old 4.1 Modules I have replaced them now by 4.4 modules. Controller has latest FW 5.1.2022 on it and is set to 9K6 speed.

Lights run through on first 32modules but then there it stops… I’ve replaced module 31, 32 and 33 but no change. I think this can be some magic code issue because of multiple 16…

Any Ideas what I can do?

thx
Karl

One thing to add, modules are flashed with 9k6 FW

Okay, we have another user with 80 modules which is now working okay.

If you “skip” the connection on the first few modules (move the controller further down the string of modules) do the LED’s on the remaining modules work as expected?

Have you configured the controller with the correct number of parallel/series settings?

Yes, 14s 5p is configured.
I’ll try skipping

Thx

@all,

anyone using BlueSea ML (bistable magnetic latching) relays?
there’s a wire to pass a signal to close, and another one to pass the signal to open. Obvs there’s a common as well. either 12 or 24V.
Thing is say you want a rule to disconnect if bank over voltage and then when it drops re connect.
How can you achieve that? the way Rules are set you open and/or close SAME relay according to the rule. Now I have to have 2 relays involved one to do the one job, one to do the other.
Anyone been there and done it, or shall I have a go myself? :slight_smile:
or am I missing something?

[about to order one tomorrow]
It is going to be the last line of defence as the canbus to the victron onboard through DVCC should take care and lower charge, or stop discharge before getting into trouble.

cheers

V.

Two relays is the way to do that problem, and probably using the pulse output/setting.

@stuart

have the same issue if one cell starts top balancing a warinig pop up on the device, cell imbalance.
this is confusing would be great if there could be a setting for imbalance warning like 20-200mv custom set.
i have this warnings all the time in the victron gx device…

Ok, as I mentioned when I released the Victron integration it wasn’t “finished” but more of a working example.

Can you open an issue on GITHUB for me [Issues · stuartpittaway/diyBMSv4ESP32 · GitHub] describing the problem and how you think it could be fixed.

yes, that’s at least the theory. haven’t looked at the code yet, but let me describe where I think this hits a wall (imho)
Example of cell level checking:

A. Individual cell over voltage (mV) say I have 3500 and reset 3480
and
B. Cell under voltage (mV) say I have 3000 and reset 3020

Set relay 1 and 2 on pulse.
on cond A triggered so cell > 3500, I set a pulse on R1
now, when said cell drops under 3480 I have to pulse R2
Cannot be done as Rule relates trigger condition to ONE relay
return to normal conditions wont pulse some other relay, am I missing something?
Exact same in Under voltage condition btw.
TBH, rule setup is organised around relays closing and opening to keep a load on a contactor on or off, or to run a fan or whatnot.
This pulsing to trigger a bistable latching contactor on and then pulsing another relay to turn it off is not possible it seems
Same in theory would apply to ALL Rules.

Seems that a solution is to have Relay2 fe, pulsing to keep the latching contactor in ON position and if ANY of the selected rules is triggered, Relay1 pulses getting contactor in OFF.
When return to normal, Relay2 pulses again.
Is that the function of Default at the bottom by any chance?
saves me looking at the code and thinking how to do it :grin:

cheers

V.

@voltmeter and @stuart

I’ve worked on this a bit, it is confusing but it is helpful in that you configure Victrons to drop charging current to a level that the (balancing) cell modules can cope.
Now, REAL imbalance situation can be both when top balancing and when you reach empty and one cell is weaker and drops first.
That is easy to pick and have an extra condition to reduce load on cells. I’ve tested that in code (not v.successfully yet as was busy with other things) Could open an issue if you like over the w/e.

However, we are severely limited with the three modes Victrons accept…
I mean once it starts top balancing you REALLY want the charge to drop, so you get into Charge Current Limit (as properly set by stuart). Once you’re at this mode Cerbo/rpi/whatever VenusOS you run, will come up with this warning, doesn’t look there’s a way out of it.

So, to wrap it up, the imbalance cell message on VenusOS is annoying (and wrong if you’re top balancing and you have a variation of 20mV!) but nothing stuart can do about it - its a Victron message.
Mind I’ve no experience how a victron BMS and battery cooperate.

cheers

V.

1 Like

20 to distribute among enthusiasts in Spain

1 Like

thank you for the explanation, if there is no way to fix this… well…

but for me now i havent activated DVCC and this warning coms anyway everytime it starts top balance.
well then i have to ignore it, but then i can miss other warnings.

lets hope it will work fine and there are no other problems in my system :slight_smile:

that’s exactly the problem, you may miss more important issues.
HOWEVER, on an important issue, you won’t have a WARNING, you’ll have an error and a battery disconnect (as far as Victron will be concerned as Cerbo or rpi will disable chargers/mppts/inverters)

No idea how that is reported on VenusOS, will have a go at simulating it and see what happens.

V.

1 Like

On the relay (BMS control board) you have NO, C and NC contacts, so you can connect your “open” command to NO, “close” to NC, and common to C. In such a way it should work with one relay. Or am I missing something?

Alternately I can suggest using such relay:

It has a one wire control mode, and still works as a latching relay

As I have mentioned before, this option doesn’t work properly, at least by me. Instead of generating a pulse, it just inverts the output. Or have you fixed it in the last update?

1 Like

I’ve not tested that for a while, if its still not working correctly please raise a GITHUB issue for it.

Just published a new YouTube video, the DIYBMS now supports another style of current and voltage measurement device - the very inexpensive PZEM-17 from AliExpress/Peacefair.

Peacefair PZEM-017 AliExpress Link

4 Likes